Intent to Experiment: User Agent Reduction Origin Trial

[Ali Beyad]

Contact emails aaro...@chromium.org, jadek...@chromium.org, mike...@chromium.org, abe...@chromium.org 

Explainer

None

Specification

None

Summary

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.

Design Doc

https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb 

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/640 

TAG review status

Pending (https://github.com/w3ctag/design-reviews/issues/640) 

Risks

Interoperability and Compatibility

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.

Experiment Summary

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: 

1. Reducing the information in the associated JS getters, if the Origin Trial is enabled.

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

Experiment Goals

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.

Experiment Risks

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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No (All but WebView)

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

No.

Flag name

#reduce-user-agent

Tracking bug

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

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5704553745874944

[Jason Chase]

This sounds like the trial to opt-in (and opt-out) for the Page Freezing intervention. As I recall, that trial didn't end up running at scale, so we didn't end up testing the usage limits. It seems worth considering as a precedent. That is, noting the differences in burn-in risk for opting into potentially breaking behaviour vs taking advantage of new functionality.

[Ali Beyad]

I think it makes sense to proceed with a regular origin trial and look at requesting higher usage limits if/when we get commitments and estimates for participation in the UA reduction experiment.  

[Mike West]

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? Likewise, what does B have access to via JavaScript?

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?

-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/CABJKADxFLTHtvYPzNzF%3Dy5wP4x%2BaK1cF3RRCWii7UjV54EjkSw%40mail.gmail.com.

[Ali Beyad]

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:

1. The Javascript getters for user agent data (e.g. navigator.userAgent)
2. The new Client Hint `Sec-CH-UA-Reduced` that would indicate to the origin that the HTTP header "User-Agent" contains a reduced value, not the full UA string. 

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?

The plan was for the requests sent for embedded page B to also include the reduced UA string along with the `Sec-CH-UA-Reduced` Client Hint, even if B is not opted-in to the Origin Trial.  This would be accomplished through setting "allow same-origin and cross-origin" Permission Policy for the `Sec-CH-UA-Reduced` client hint.  The feeling was that, it would be hard to know if a top-level site is truly functioning correctly in the presence of UA reduction if only it, but not its embedded subresources, are receiving the reduced UA string.

 

Likewise, what does B have access to via JavaScript?

Great question - while subresource requests sent to B would include the reduced UA and `Sec-CH-UA-Reduced` headers, the JavaScript for B would not have access to the reduced UA unless it was also registered for the OT.

 

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?

If there is a top-level navigation to A for the first time, then it will not receive the reduced UA and the new client hint (although the initial navigation request could be retried with the reduced UA if Critical-CH is set and the OT token is valid).  All subsequent navigations to A, including if A navigates to a same-origin page on A, will include the reduced UA string and `Sec-CH-UA-Reduced` header.  This would hold until the browser is restarted or session data is cleared, which would also clear the Accept-CH cache.

For the subresource requests made from A to B, while B would include the headers sent to A (including the reduced UA string), B would not save the client hint in its Accept-CH cache.  Therefore, a subsequent navigation to B would not include the reduced UA string nor the `Sec-CH-UA-Reduced` header, since it is not opted-in to the OT.  

The behavior can be summed up as "if the top-level navigation is opted-in, send the reduced UA to the top-level origin as well as all subresource requests, including to those of a different origin".  The feedback we received thus far from potential partner sites was that it would be most useful if the same UA was sent on subresource requests to realize and handle any potential breakage.  This also seems consistent with how current client hints work - the same client hints are sent for cross-origin subresource requests as long as the Permission Policy allows it.

We also considered the idea of requiring B to sign up for a third-party matching Origin Trial, but that seemed to us like it would be too much overhead for the top-level sites to have to work through.

 

4.  What's your experimentation timeline?

We were hoping to get the origin trial experiment in by the feature freeze for M94.  The goal would be to run a 6-month experiment.  Then, we would like to run a 6-month deprecation trial thereafter (a separate I2E would be sent for that) which would send the reduced UA string by default, but enable those origins opted into the deprecation trial to still receive the full UA string.

[Ali Beyad]

On Mon, Jul 12, 2021 at 10:55 AM Ali Beyad <abe...@google.com> wrote:

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:

1. The Javascript getters for user agent data (e.g. navigator.userAgent)
2. The new Client Hint `Sec-CH-UA-Reduced` that would indicate to the origin that the HTTP header "User-Agent" contains a reduced value, not the full UA string. 

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?

The plan was for the requests sent for embedded page B to also include the reduced UA string along with the `Sec-CH-UA-Reduced` Client Hint, even if B is not opted-in to the Origin Trial.  This would be accomplished through setting "allow same-origin and cross-origin" Permission Policy for the `Sec-CH-UA-Reduced` client hint.  The feeling was that, it would be hard to know if a top-level site is truly functioning correctly in the presence of UA reduction if only it, but not its embedded subresources, are receiving the reduced UA string.

 

Likewise, what does B have access to via JavaScript?

Great question - while subresource requests sent to B would include the reduced UA and `Sec-CH-UA-Reduced` headers, the JavaScript for B would not have access to the reduced UA unless it was also registered for the OT.

Upon further deliberation, we should also be able to ensure that the embedded third-party JS has the same access to the reduced UA string if the subresource request headers do.  There is precedent for this type of inheritance of OT token state in embedded JS, for example with the Page Freezing trial.  It'll add some more code complexity but will make the semantics much clearer - all subresource requests and embedded JS (1p and 3p) will get the same UA string as the top-level navigation.

[Mike West]

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.

With regard to the OT schedule, ~6 months from M94 would take us more or less through M100. In https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/dhfejxAtj84/m/vr889GowAgAJ, we agreed (but I don't think documented... I'll fix that) that we'd be taking ~4 milestones as a typical OT length as we shift into a 4-week cadence.

That said, it sounds like you want to use this experiment as a lead-in to a behavior change and deprecation trial, and holding you to 4 milestones would put you squarely in the holiday season of M98. I'm comfortable with y'all extending this out a little longer than usual, but I'd appreciate two other API owners weighing in to confirm that plan.

-mike

[Yoav Weiss]

LGTM2 for a longer-than-usual OT.

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.

[Ali Beyad]

On Thu, Jul 15, 2021 at 4:02 AM Mike West <mk...@chromium.org> wrote:

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.

I updated the design doc to make the point clear that the UA will only be reduced in the presence of the OT token, and I clarified the role of the new client hint in all this.  Thanks for the feedback!

[Rick Byers]

I agree this OT is quite different from a regular OT, there's not really a "burn-in risk" to be worried about since this isn't really about any new functionality sites want access to. So LGTM3 for a longer trial.

If necessary I'd also be supportive of expanding usage limits arbitrarily. The more usage we can get of this trial, the lower the compat risk will be of making the breaking change later. So in this case it makes no sense to worry about excessive usage of the OT. 

I'm glad to hear the inherited JS semantics will match that of the header. Like for the header, I'd otherwise be worried about masking potential compat issues if that JS APIs were unaffected.

Rick

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.

[Ali Beyad]

Thanks for the feedback and the LGTMs, everyone!

[Ali Beyad]

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.

On Wed, Aug 11, 2021 at 4:02 PM Ali Beyad <abe...@chromium.org> wrote:

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.

[Ali Beyad]

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.

On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad <abe...@chromium.org> wrote:

[Ali Beyad]

A blog post just went out for this OT: https://developer.chrome.com/blog/user-agent-reduction-origin-trial/

[Ali Beyad]

Just an FYI, the blog post has been updated to give instructions on how to participate in the User-Agent Reduction Origin Trial as a third-party embed: https://developer.chrome.com/blog/user-agent-reduction-origin-trial/#how-to-participate-in-the-origin-trial-as-a-third-party-embed

[Noah Lemen]

Are there any plans to extend this Origin Trial? We (Meta) are considering using it to test the impact of UA reduction, but just noticed that its "end date" is tomorrow, and was marked with availability ending after version 103.

[Mike Taylor]

Hi Noah,

Thanks for reaching out - we've received a request just yesterday from another partner who also expressed interest in an extension, so I will work on an Intent to Extend Experiment in the next few days and we'll see what the Blink API Owners think. :)

thanks,
Mike

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.

[Nir M]

Hi Mike, 

Nir from Meta and Noah's peer.

would it be possible to give an estimate or a guideline on the permissible magnitude of usage for the Opt-In trial (the one that forces the full reduction of the UserAgent) available? 
As we would like to conduct an experiment on that, and not deviate from the 0.5% restriction of global page loads, we need an idea of how many users will be able to be getting this experimental behavior.

would love to hear more details on that if you could provide. 

Link to the limitation reference on Origin-Trial: 

https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md#6-is-there-any-restriction-on-which-websites-can-sign-up-to-use-experimental-features

thanks, 

Nir

[Rick Byers]

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?

Rick

[Mike Taylor]

On 9/30/22 1:32 PM, Rick Byers wrote:

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

[Mike West]

I agree with Rick's analysis here. Given the purely-negative nature of this OT, there's little risk in this burning-in unless we ship it, in which case we want it to burn in.  Dropping the usage limitation for this OT LGTM2.

-mike

[Yoav Weiss]

LGTM3

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.