User agent client hints

[ygupta81]

Description

User-Agent Client Hints are a new expansion to the Client Hints API, that enables developers to access information about a user's browser in a privacy-preserving and ergonomic way.

Mozilla’s Firefox and Apple’s Safari have no support for user-agent client hints today. See this for more details - https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API#browser_compatibility

Rationale

It is recommended to start using user-agent client hints as they return the data in an easy-to-use format without creating a fingerprinting surface. These also help apps to explicitly declare their need for user agent data. Due to the incompatibilities listed above, developers are forced to continue use of user agent sniffing thereby hampering the progress of user agent reduction work by browsers.

Specification

• https://wicg.github.io/ua-client-hints/
• https://datatracker.ietf.org/doc/html/rfc8942

Tests

https://wpt.fyi/results/ua-client-hints?label=master&label=stable&aligned

[tbondwilkinson]

This would be useful to Google's server framework.

"We already provide support for User Agent Client Hints, having a consistent spec for this that all browsers follow would simplify our code"

[miketaylr]

https://wpt.fyi/results/workers?label=master&label=stable&aligned&view=subtest&q=workers%2Fworkernavigator_useragentdata is also relevant here.

[jgraham]

Am I correct in thinking that the scope here is intended to be just the JS API and not the headers? afaict that's all that's covered by the tests, but I don't understand the spec well enough to be sure there aren't interactions I'm missing.

What's the prospect of this ending up on a standards track before the Interop 2023 starts?

[hsinyi]

Am I correct in thinking that the scope here is intended to be just the JS API and not the headers? afaict that's all that's covered by the tests, but I don't understand the spec well enough to be sure there aren't interactions I'm missing.

@ygupta81 Today is the last day to adjust and clarify the scope. As James pointed out above, having clarity about the specific use cases on your side and the proposed scope would be appreciated. Thanks!

What's the prospect of this ending up on a standards track before the Interop 2023 starts?

[ygupta81]

Am I correct in thinking that the scope here is intended to be just the JS API and not the headers? afaict that's all that's covered by the tests, but I don't understand the spec well enough to be sure there aren't interactions I'm missing.

@ygupta81 Today is the last day to adjust and clarify the scope. As James pointed out above, having clarity about the specific use cases on your side and the proposed scope would be appreciated. Thanks!

What's the prospect of this ending up on a standards track before the Interop 2023 starts?

Yes, we are looking for JS API support primarily. Today we rely on user-agent heavily to detect device type, os type, os version etc. With JS API support across browsers, we will be able to plan our migration.

[hsivonen]

Today we rely on user-agent heavily to detect device type, os type, os version etc.

@ygupta81, What's your use case for detecting OS version? (Device type and OS type are extremely likely to stay available via the UA string.)

[ygupta81]

Today we rely on user-agent heavily to detect device type, os type, os version etc.

@ygupta81, What's your use case for detecting OS version? (Device type and OS type are extremely likely to stay available via the UA string.)

We promote our desktop application at various places in our web application. Before we ask user to download the desktop app, we want to make sure that device and OS version user is on is supported by our desktop application.

[hsivonen]

Today we rely on user-agent heavily to detect device type, os type, os version etc.

@ygupta81, What's your use case for detecting OS version? (Device type and OS type are extremely likely to stay available via the UA string.)

We promote our desktop application at various places in our web application. Before we ask user to download the desktop app, we want to make sure that device and OS version user is on is supported by our desktop application.

While it's a bit unfortunate to promote a desktop app to users who'd be unable to run the desktop app, this doesn't seem to me like a compelling enough a reason to expose fingerprinting surface.

Previously, we've exposed this level of information on Mac but stopped doing so. On Windows 10, checking whether a desktop app runs would likely involve exposing the major update version (not sure what the right term is), such as "22H2". This would be newly-exposed fingerprinting detail.

Suppose high-entropy values weren't available. Would you still find the User Agent Client Hints JS API useful compared to navigator.platform and navigator.userAgent?

[ygupta81]

While it's a bit unfortunate to promote a desktop app to users who'd be unable to run the desktop app, this doesn't seem to me like a compelling enough a reason to expose fingerprinting surface

@hsivonen I am not sure if above statement is fully true for our case. Our desktop app is a paid app and before we ask user to pay for the product, we really want to make sure that it could be downloaded and installed on the device user is using.

Would you still find the User Agent Client Hints JS API useful compared to navigator.platform and navigator.userAgent?

Internally, we are looking towards minimizing our use of user agent string to distinguish between browsers, their versions, device types (mobile, tablet etc) in favor of user agent client hints as it seems that's also the direction browsers like Chrome are taking. Using that API is still useful as it is a structured way to access information present in user agent string compared to parsing things out but situation would become more chaotic if some browsers support user client hints and others don't. As a website owner, I would like to remain consistent in whatever way we choose here.

[tapananand]

Suppose high-entropy values weren't available. Would you still find the User Agent Client Hints JS API useful compared to navigator.platform and navigator.userAgent?

There was a Safari Bug some time ago that broke our WebAssembly completely on Safari 13.0. It was later fixed in version 13.1.1. We had to put checks in our code on the browser minor version to get around this issue by loading an alternative library. With the lack of high entropy values like browser minor version, if such a thing happens sometime in the future, we won’t have any option here but to take the hit of first failing the application and then switching to the backup.

[gsnedders]

Suppose high-entropy values weren't available. Would you still find the User Agent Client Hints JS API useful compared to navigator.platform and navigator.userAgent?

There was a Safari Bug some time ago that broke our WebAssembly completely on Safari 13.0. It was later fixed in version 13.1.1. We had to put checks in our code on the browser minor version to get around this issue by loading an alternative library. With the lack of high entropy values like browser minor version, if such a thing happens sometime in the future, we won’t have any option here but to take the hit of first failing the application and then switching to the backup.

Note the spec doesn't require implementations to be any more truthful than they are in their User-Agent strings, so it's not guaranteed you'll get any higher entropy value from UACH.

@hsivonen's question about whether the the API is value if it only has low entropy values I think is a valuable question to ask—and merely reiterating the lack of high entropy values is problematic doesn't answer whether the API is valuable if it has the same low entropy values.

[foolip]

In the MDN short survey on APIs & JavaScript, "User agent client hints (navigator.userAgentData)" was selected by ~9% of survey takers, putting it in the bottom third of options. (There is some uncertainty as with any survey data.)

[gsnedders]

FWIW: my impression is many web developers believe that UACH will save them from UAs increasingly freezing their UA strings, by provided more accurate data, which is AIUI how the Chrome team have communicated many of their (proposed) changes.

Except, of course, this isn't actually the case: UACH merely provides structured access, some opt-in, but without any further guarantees about accuracy.

And that's not to say that structured access doesn't have its advantages (it does!), but it does mean those surveyed may believe there's larger upsides to it that are only true of Chrome's implementation.

[hsivonen]

Our desktop app is a paid app and before we ask user to pay for the product, we really want to make sure that it could be downloaded and installed on the device user is using.

@ygupta81, How does this use case work for you in Chrome today? Of the desktop platforms, Chrome exposes system version information that looks suitable for that purpose only on Mac. On Windows 10, the major version seems like a plausible compatibility discontinuity point, but, AFAICT, Chrome doesn't expose the Windows 10 major version (1507 through 22H2). Are your apps compatible all the way to Windows 10 1507?

In any case, it seems to me that it would be prudent to let at least an initial installer stage run before the user commits to paying.

[hsivonen]

(I suppose the correct term isn't "major version" but "feature update" in the Windows 10 case.)

[ygupta81]

Our desktop app is a paid app and before we ask user to pay for the product, we really want to make sure that it could be downloaded and installed on the device user is using.

@ygupta81, How does this use case work for you in Chrome today? Of the desktop platforms, Chrome exposes system version information that looks suitable for that purpose only on Mac. On Windows 10, the major version seems like a plausible compatibility discontinuity point, but, AFAICT, Chrome doesn't expose the Windows 10 major version (1507 through 22H2). Are your apps compatible all the way to Windows 10 1507?

In any case, it seems to me that it would be prudent to let at least an initial installer stage run before the user commits to paying.

I haven't tested this recently but we do have some windows versions checks for windows major versions 5 and 6. For versions > 7, we allow all versions. And here is the logic we are currently using to determine windows system major and minor version:-

      pattern = /.+Windows NT (\d+).(\d+)/;

      matchArray = navigator.userAgent.match(pattern);
      if (matchArray) {
        sysInfo = {
          majorSystemNumber: parseInt(matchArray[1], 10),
          minorSystemNumber: parseInt(matchArray[2], 10),
        };
      }

[nairnandu]

Thank you for proposing User agent client hints for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year.
As discussed in this issue, there are still concerns with the relevant specifications. We encourage you to start a conversation with the relevant working groups to get these issues resolved.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.