Intent to Prototype and Ship: User-Agent Client Hints API Updates

333 views
Skip to first unread message

Mike Taylor

unread,
Apr 30, 2021, 11:32:39 AMApr 30
to blink-dev, Aaron Tagliaboschi, jadek...@chromium.org

Contact emails

mike...@chromium.org, aaro...@chromium.org, jadek...@chromium.org


Explainer


https://github.com/WICG/ua-client-hints#user-agent-client-hints


Specification

https://wicg.github.io/ua-client-hints/


API spec

Yes


Summary

Implementing 4 recent feature additions / changes from the User-Agent Client Hints API (already landed in the spec)


Blink component

Privacy>Fingerprinting


Motivation

1. Sec-CH-UA-Bitness: adds a new high-entropy hint to expose the OS bitness, which may be combined with Sec-CH-UA-Arch to provide optimized binaries for download, for example.


2. Make Sec-CH-UA-Platform a low-entropy hint: OS is passively observable at the TCP level anyways, so we plan to change this to be low-entropy and send as a default header (similar to Sec-CH-UA and Sec-CH-UA-Mobile).


3. Include low-entropy hints by default in UADataValues (returned by getHighEntropyValues()). If a hint moves from high to low-entropy, this future proofs any code relying on it.


4. Add a toJSON method to NavigatorUAData’s IDL. Technically a bugfix, but it is an API change (instead of returning {}, JSON.stringify(navigator.userAgentData)) will now be useful)


TAG review

N/A


Risks


Interoperability and Compatibility

These are small updates to the existing API, so I haven’t requested signals. 

(But happy to do so if folks think it’s useful.)


Is this feature fully tested by web-platform-tests?

The existing API is, and we will add WPTs for these proposed changes.


Flag name

chrome://flags#sec-ua-ch-platform-low-entropy (as a killswitch, enabled by default)


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1199755


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5733498725859328


Mike West

unread,
May 11, 2021, 3:54:28 AMMay 11
to Mike Taylor, blink-dev, Aaron Tagliaboschi, jadek...@chromium.org
Hey Mike, apologies for the long lag on a response here. In the owners' meeting last week, I and others raised some concerns about the level of engagement from folks outside Chrome with regard to the latest additions. I do think it would be valuable to get more review on some of these pieces.

In particular:

1.  Adding a `toJSON` method seems tiny and uncontroversial. Skipping TAG review and signals requests seems reasonable.

2.  Including low-entropy hints along with high-entropy hints in `UADataValues` seems like a reasonable thing to do, giving developers a clear way of requesting "UA Stuff", which seems like the way folks would be expected to use `getHighEntropyValues()`. There's something of a question there around API design (should we have a `getAllValues()` instead? Or a `getJustLowEntropyValues()`?) that seems like it would benefit from broader circulation. 

3.  A year ago, Maciej from WebKit seemed fine with a 32 vs 64 bit flag, but suggested they wouldn't implement it. It seems reasonable to ask again now that we're interested in shipping it.

4.  The justification to shift `platform` from high- to low-entropy looks like it was run by Yoav, and no one else: https://github.com/WICG/ua-client-hints/issues/213.

It seems pretty reasonable to me to ask other vendors what they think. I'd also note that the TAG review from 2019 was an "early review", ending with "this is the official "thumbs-up" from the TAG. Please continue developing this proposal, and we look forward to being involved in future review requests!" I'd suggest that now's a good time to request a specification review, as there's a spec and everything. :)

-mike


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15fb328f-560a-43dd-d39b-421e16e52497%40chromium.org.

Mike Taylor

unread,
May 20, 2021, 5:36:02 PMMay 20
to Mike West, blink-dev, Aaron Tagliaboschi, jadek...@chromium.org
Hi Mike,

On 5/11/21 2:54 AM, Mike West wrote:
[...snip...]
2.  Including low-entropy hints along with high-entropy hints in `UADataValues` seems like a reasonable thing to do, giving developers a clear way of requesting "UA Stuff", which seems like the way folks would be expected to use `getHighEntropyValues()`. There's something of a question there around API design (should we have a `getAllValues()` instead? Or a `getJustLowEntropyValues()`?) that seems like it would benefit from broader circulation.

Thanks, I filed https://github.com/WICG/ua-client-hints/issues/233 for discussion of possibly adding a new method there (and pinged some folks from other browsers for input). Thoughts from anyone on the list are most welcome there.

3.  A year ago, Maciej from WebKit seemed fine with a 32 vs 64 bit flag, but suggested they wouldn't implement it. It seems reasonable to ask again now that we're interested in shipping it.

Great point. I sent this off last week to provide input on all the proposed changes in this I2P: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031857.html

4.  The justification to shift `platform` from high- to low-entropy looks like it was run by Yoav, and no one else: https://github.com/WICG/ua-client-hints/issues/213.

I realize that I didn't do a great job of arguing for the change in the issue (or the linked doc). A partner site approached us on the original plan to make all non-mobile UA strings report Windows 10, and how it affected them. Their biggest concerns related to accessibility: they had a number of keyboard shortcuts and other a11y fixes (platform-specific screen reader workarounds) that posed challenges. I hadn't quite dug into the keyboard shortcuts use case, so did some spelunking on GitHub. I just added the results of that work to the (public) doc linked in Issue #213:

https://docs.google.com/document/d/122TG71j9LC_Ne_-vzoNBRFUwi_irIuyi_xYFE1o4iKU/edit#heading=h.uk9bdpiqztfv

I'll repeat one paragraph here:

With a high-entropy platform, maintained sites could of course request the hint, as we expect sites to do for platform version, architecture, etc. But for the keyboard shortcut use case, the burden on the ecosystem seems quite high: unmaintained sites will be broken for non-Windows users, and much (all?) of the JS ecosystem dealing in shortcuts will have to be re-written to use `navigator.userAgentData`. I believe the a11y and compatibility implications trump the privacy wins that might be gained by making all non-mobile UA strings as Windows 10.

Another points relates to the total amount of entropy we're giving up. In Issue #213, we had estimated to give up 1 bit of entropy. My colleague Paul Jensen did the math (based on internal data, but it could be replicated using public data on platform usage and UA strings in the wild), and adding a default platform only gives up 0.39 (rounding up) bits of entropy. We feel that this is an acceptable trade off to make.

It seems pretty reasonable to me to ask other vendors what they think. I'd also note that the TAG review from 2019 was an "early review", ending with "this is the official "thumbs-up" from the TAG. Please continue developing this proposal, and we look forward to being involved in future review requests!" I'd suggest that now's a good time to request a specification review, as there's a spec and everything. :)

Yep, thanks for the nudge there. There was also the review at https://github.com/w3ctag/design-reviews/issues/467 that was closed due to the pandemic plan pause. I'll file a new TAG issue and update this thread once it's live.

thanks,
Mike

Mike Taylor

unread,
May 26, 2021, 10:23:53 PMMay 26
to Mike West, blink-dev, Aaron Tagliaboschi, jadek...@chromium.org

OK, it took a hot minute, but https://github.com/w3ctag/design-reviews/issues/640 was just posted.

(I believe I've addressed all questions now. Looking forward to more thoughts from API owners.)

thanks,
Mike

Yoav Weiss

unread,
May 27, 2021, 3:06:16 PMMay 27
to blink-dev, Mike Taylor, blink-dev, Aaron Tagliaboschi, jadek...@chromium.org, Mike West
One more request: we're missing signals from Mozilla on this. Could you file a Mozilla position issue?

Mike Taylor

unread,
May 27, 2021, 3:46:23 PMMay 27
to Yoav Weiss, Aaron Tagliaboschi, jadek...@chromium.org, Mike West, blink-dev
On 5/27/21 2:06 PM, Yoav Weiss wrote:
> One more request: we're missing signals from Mozilla on this. Could
> you file a Mozilla position issue?

Oops. Here it is: https://github.com/mozilla/standards-positions/issues/533

(will update chromestatus as well)

Mike Taylor

unread,
Jun 2, 2021, 9:54:19 AM (11 days ago) Jun 2
to Yoav Weiss, Aaron Tagliaboschi, jadek...@chromium.org, Mike West, blink-dev
:mt replied that their existing position applies for these changes as
well ("Non-Harmful"). I've updated
https://chromestatus.com/feature/5733498725859328 to reflect that.

Reply all
Reply to author
Forward
0 new messages