We want to reduce the amount of information the User Agent string exposes in HTTP requests as well as in navigator.userAgent, navigator.appVersion, and navigator.platform. The browser's brand and significant version, its desktop/mobile distinction and the platform it is running on will continue to be sent.
We would like to run an Origin Trial for sites to opt into the Reduced User-Agent (and related navigator properties) to proactively test for breakage. See below for more details.
The compatibility risk is low, as we’re planning to reduce the amount of information in the UA string, rather than remove the header. Most existing UA detection code should continue to work. It is only future UA detection code that will need to move to use the UA client hints instead. In the long term, we expect this change to improve compatibility, as UA detection based on UA-CH is bound to be more reliable than the current status quo. We hope this Origin Trial will help us flesh out site compat issues we can’t predict a priori.
As for interoperability, other vendors are on board with UA information reduction, but not necessarily with the UA Client Hints mechanism that is supposed to replace it. That can create a tricky situation, where developers would need to rely on the User-Agent string for some browsers and on UA-CH for others.
Edge: Positive signals (https://twitter.com/_scottlow/status/1206831008261132289)
Firefox: Public support for reducing UA string information - “freezing the User Agent string without any client hints—seems worth-prototyping” (from https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095)
Safari: Shipped to some extent. Safari has attempted to completely freeze the UA string in the past, but somewhat reverted that decision. Nowadays, their UA string seems mostly frozen, with updates only to the browser version.
Web developers: Mixed signals. Some positive comments on Twitter, blink-dev, etc., as well as some negative sentiment.
This experiment is going to be a bit different from a normal Origin Trial; the goal is less about gathering information on the design of a new API than it is about enabling developers and administrators to test and ensure compatibility with our proposed changes. This change represents a large compat challenge with very subtle pitfalls and vast dependencies, it’s incredibly important we give developers any opportunity to test systems at every level.
As for engaging with the trial itself, there will be two components controlled by the same Origin Trial:
Reducing the information in the associated JS getters, if the Origin Trial is enabled.
A client hint that gets set when the Origin Trial is enabled, where the client hint indicates to the origin that the User-Agent request header contains the reduced value. Because of the experimental nature of this client hint, a valid Origin Trial token must be sent in the response header by the origin for the client hint to take effect or be stored (in order to prevent platform burn-in for this temporary client hint token).
During the process of conducting the Origin Trial, we may find that we need to request an exception to the per-site (and possibly global) limits imposed by Origin Trials. In practice, Origin Trials rarely exceed their quota limits, but if necessary, there is time between when the limits have been exceeded and the Origin Trial is turned off, where we can work with the users on reducing their usage and/or lifting the limits.
Please see the design document describing the experiment for more information.
The goal of this trial is to enable developers to test how reducing the User-Agent request header and the related navigator getters will affect their systems and make sure they have all of the tools they need for an effective migration to User Agent Client Hints. We hope that by providing sufficient time to test and provide feedback we can validate our current plans for UA Reduction and safely roll them out to the web at large.
We will be relying heavily on user and developer feedback to understand where breakage occurs, or where use cases are not accounted for. We will create a GitHub repository as well as a public mailing list for gathering feedback. When the OT is ready, we plan to publish developer guidance on how to enroll and provide feedback.
Despite the proposed changes being net-positive in terms of privacy, there are some compat risks, as many sites have come to rely on the shape of the User-Agent header and related JS interfaces. Site breakage can take many forms, both obvious and non-obvious. However, since sites are in control of the Origin-Trial and Accept-CH headers, a site can quickly opt out of the experiment when breakage is encountered.
No (All but WebView)
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/CABJKADxFLTHtvYPzNzF%3Dy5wP4x%2BaK1cF3RRCWii7UjV54EjkSw%40mail.gmail.com.
Hey Ali,There are a few details here that I'm not sure I understand.1. The linked design doc describes opting into UA reduction through both an origin trial, and a client hint-based opt-in. Does this intent include both mechanisms? Or is it only about the origin trial?
2. Does a top-level document's opt-in to the origin trial control the UA headers received by requests made from documents it embeds? That is, if a page at A opts-into the OT, and embeds a page from B that does not opt-in, what UA headers will requests initiated from B contain?
3. Are top-level navigations affected? That is, if A in the example above opts-into the OT, and then navigates to B at the top level, what UA header is delivered? Does the answer change if A navigates same-origin to another page on A?
4. What's your experimentation timeline?
Hey Mike,Thanks for your questions. Answers inline.On Mon, Jul 12, 2021 at 9:15 AM Mike West <mk...@chromium.org> wrote:Hey Ali,There are a few details here that I'm not sure I understand.1. The linked design doc describes opting into UA reduction through both an origin trial, and a client hint-based opt-in. Does this intent include both mechanisms? Or is it only about the origin trial?The I2E is for an origin trial that would control two behaviors:
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdSMWqp_WA1it3K_su4ga0KvHmZ90U3neNERPh_kc9jmw%40mail.gmail.com.
Thanks for the clarifications, Ali. This looks pretty reasonable to me. LGTM1 % the below:I would recommend that you adjust the design doc to remove the reference to "a client hint token that will reduce the User-Agent header", as it doesn't sound like that's what you're aiming to experiment with. My understanding of your response is that you'll only adjust the UA in the presence of the Origin Trial token.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BWdJ_4jkExO4p9GdCdc7BUa8GBK0eota1q8EfEi%3D5%2BBuj3jCw%40mail.gmail.com.
An update on this: it will be too rushed to get the User-Agent Reduction OT into the M94 branch cutoff (this Thursday), so we moved this OT for the M95 release.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a13aa138-d0de-4086-a9c8-e3973af041fcn%40chromium.org.
As I understand it, this OT is entirely about taking away functionality (grants nothing new which a site might take a dependency on). Therefore I don't think the usage limits are providing much, if any, value. At the same time, I can see the value of being able to test this upcoming behavior at a large scale.
So, with API owner hat on, I propose we just turn them off for this trial. Thoughts?
My my API owner hat off (because my name is attached to this
project), I agree. I think the larger testing benefits outweigh
any possible risks (and can't really think of any, tbqh).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdZwaXUeD4QgXtof9jcdv2iqnOTH3p3PYo0EiQN2_1YMA%40mail.gmail.com.