User-Agent Client Hints (https://wicg.github.io/ua-client-hints/) define a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable User-Agent header. This includes: - New headers starting with "Sec-CH-UA" that provide information about the user agent to the server. - A JavaScript API (navigator.userAgentData) that makes this information accessible via JavaScript. An implementation of this would be awesome as it would make browser- and OS-detection a lot simpler. In WebKit (and Gecko), you currently have to parse the User-Agent string for this, which is very impractical. (And Chromium DevTools show an issue when accessing navigator.userAgent – telling me to migrate to navigator.userAgentData – which I can't because it's only supported in Blink at the moment.)
> User-Agent Client Hints (https://wicg.github.io/ua-client-hints/) define a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable User-Agent header. UACH won't decrease passive fingerprinting surface for Safari on macOS; on macOS the WebKit-provided UA string is: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)" Safari then adds a suffix to this, "Version/16.0 Safari/605.1.15" in my current case. And only the "Version/16.0" part isn't a constant there. The iOS case does have slightly more variability giving away the device type and OS version. > - New headers starting with "Sec-CH-UA" that provide information about the user agent to the server. We've been fairly ambivalent about these, given in our case it doesn't lead to much decrease in passive fingerprinting ability, and we are unlikely to be more truthful in the "high entropy" hints (i.e., those which don't appear in the "low entropy hint table") when they are requested. > - A JavaScript API (navigator.userAgentData) that makes this information accessible via JavaScript. I don't think we've had much discussion thus far about the JS API; personally, while I see there's some level of benefit in not having to parse the UA string, it's not clear that provides much advantage is reality.
<rdar://problem/95454627>
Mozilla is skeptical about the Sec-CH-UA headers, too, which I totally understand (see https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095). Personally, I'd find the JavaScript API useful because it's just convenient – parsing the UA string can be quite annoying.
It is perhaps also worth noting that this would have repercussions on the WebKit API, given currently the embedder just gives us a string which we append onto the UA string we generate. The brands, significant versions, and full versions would need to be provided to WebKit to expose this information, which likely means it would have to be off-by-default until the embedder provides such information.
(In reply to Sam Sneddon [:gsnedders] from comment #4) > The brands, significant versions, and > full versions would need to be provided to WebKit to expose this > information, which likely means it would have to be off-by-default until the > embedder provides such information. The WebKitGTK/WPE API takes application name and version and constructs the user agent string based on that. A similar API could work for Apple ports, but frankly, I don't think we should allow applications to set client hint branding honestly. With the user agent headers, it's just a trap to encourage websites to discriminate against you, and the client hint API will be no different. If we implement client hints, the results should be hardcoded in WebKit (e.g. browser name always "WebKit", please not "Safari"!).