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.