Goedenavond TAG!

This is not your typical spec review, and is highly related to https://github.com/w3ctag/design-reviews/issues/320. But, because @torgo asked nicely, I'm opening up a review for a specific application of UA-CH as a replacement for the User-Agent string.

We've had a lot of feedback on the intent, which resulted in changes to the API we want to ship. It also resulted in many open issues. Most either have pending PRs or will have ones shortly.

The latest summary is:

• The User-Agent request header will be frozen other than its browser's significant version, and unified between different platforms and devices to reduce the amount of passive fingerprinting the browser is sending out by default.
• navigator.userAgent and friends will be similarly frozen.
• By default, the browser will send Sec-CH-UA and Sec-CH-UA-Mobile headers to enable most cases of content negotiation. As those headers are low-entropy, we can afford that trade-off, privacy-wise.
  • Sec-CH-UA is defined as a set, and likely to be GREASEd to avoid current abuse patterns of the User-Agent string.
• Servers can opt-in to request more information about the user agent using the Client Hints negotiation mechanisms: platform, architecture and model are what we currently have, but we're considering things like "input mode".
  • The opt-in mechanism to enable opt-in on the "very first view" is not yet ready. At the same time, the hints sent by default are likely to answer most HTML level content-adaptation use-cases.
• An equivalent API will enable access to that information on the client. Access to low-entropy information will be synchronous, while access to high-entropy one will be through a Promise. (to enable browsers to take their time when considering if the site should really be granted to potentially fingerprintable info)

Checkboxes:

• Explainers: for the feature, as well as its infrastructure
• Specifications: for the UA-CH feature, as well as its infrastructure.
• Tests: WPT
• Security and Privacy self-review: Security and privacy are covered for the feature as well as its infrastructure. As this is a privacy-positive feature, I don't think a separate review is necessary, but let me know if you think otherwise.
• GitHub repo URL
• Primary contacts:
  • Yoav Weiss (yoavweiss@), Google Chrome - editor/implementer
• Organization driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification: design-review#320
• External status/issue trackers for this specification: Chrome status entry for UA-CH and for User-Agent freezing.

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: hoping to start freezing in M83 (June) and unification in M85 (September)
• The group where the work on this specification is being done: WICG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google Chrome

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback