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

[Mike Taylor]

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]

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]

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]

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]

One more request: we're missing signals from Mozilla on this. Could you file a Mozilla position issue?

[Mike Taylor]

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]

: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.

[Mike Taylor]

Hi there API owners,

I'm curious if there are any updates here (we're still missing LGTMs to
land the CLs associated with this intent).

As a reminder, we didn't get any further input from Apple, Mozilla also
considers these changes as "non-harmful", and the TAG review is in
process. Yesterday Yoav, myself, and fbeaufort@ met with the TAG to
discuss Client Hints, and our current plans around UA-CH and UA
Reduction were discussed. From my POV, the discussion was positive.
Rough minutes are at
https://cryptpad.w3ctag.org/code/#/2/code/view/VfuUjbrlE6F5EargSQvgiU8JMrJ5r3JnalDXCFd-BFM/.

thanks,
Mike

[Rick Byers]

I don't have context on the previous API owners discussion on engagement, but this looks to me like it's in a pretty reasonable state to proceed with shipping these updates. LGTM1

But Yoav, Mike and others - if you feel otherwise please say so!

--
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/8692f5e1-a82c-3122-3dcf-f68d1de8d456%40chromium.org.

[Mike West]

LGTM2.

I appreciate you looping in more folks. That assuages my fears that we were the only ones with eyes on these changes:

• Mozilla continues to consider this "non-harmful".
• WebKit hasn't responded to the request for signals in the ~month since you sent it.
• TAG's feedback from the minutes does read as positive, specifically around the platform change for which I was hoping to see more discussion. TAG noted ~2 days ago that they'd prioritize getting back to you with more concrete feedback there: https://github.com/w3ctag/design-reviews/issues/640#issuecomment-860827318.
• The internal security and privacy review signed off on considering "platform" a low-entropy course, with the caveat that we should reconsider that designation if we're able to make progress on making platform less-sniffable via other passive mechanisms. For the moment, though, the practical implications of dropping platform reasonably outweigh the philosophical win of making it high-entropy.

Please keep an eye on the TAG feedback that's hopefully forthcoming. Assuming that it doesn't raise new concerns y'all haven't already considered, I think you're good to go.

-mike

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfKHi6e-LrfKDrJjQgT5ag5-_1%2Bymykf33K1msOg5pjJw%40mail.gmail.com.

[Mike Taylor]

Thanks all! We will for sure keep an eye out for TAG feedback (as well as further comments from other vendors) and consider it thoughtfully.

[Thepphrit Thiankhao]

Thep...@gmail.com​

thept...@gmail.com​

ในวันที่ พ. 16 มิ.ย. 2021 14:08 น. Mike West <mk...@chromium.org> เขียนว่า:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfKHi6e-LrfKDrJjQgT5ag5-_1%2Bymykf33K1msOg5pjJw%40mail.gmail.com.

[Mathias Bynens]

The Intent* email template includes a “Debuggability” section, which is missing in this case. How would web developers debug this new functionality through DevTools? Do we need anything beyond existing DevTools functionality in the Network tab? See https://goo.gle/devtools-checklist for context.

--
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]

Hey Mathias,

On 6/21/21 6:46 AM, Mathias Bynens wrote:
> The Intent* email template includes a “Debuggability” section, which
> is missing in this case. How would web developers debug this new
> functionality through DevTools? Do we need anything beyond existing
> DevTools functionality in the Network tab? See
> https://goo.gle/devtools-checklist

> <https://goo.gle/devtools-checklist> for context.

The only DevTools task that needs to be taken care for these changes of
is to ensure that the the new bitness hint is exposed in editable fields
like the others, but that should be fairly mechanical. It's on our radar
to make sure it gets taken care of. The rest should come "for free".

Thanks for the question!

thanks,
Mike

[Mathias Bynens]

Brilliant, thanks!

[Mike Taylor]

PSA: In https://chromium-review.googlesource.com/c/chromium/src/+/3646649 I landed a fix to navigator.userAgentData.toJSON() which has been missing the "platform" hint since it the toJSON method was added. 

This is a purely additive bugfix, but please let me know if anyone runs into any breakage or has any concerns as a result.

thx,

Mike