A blog post just went out for this OT: https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
On Thu, Aug 12, 2021 at 9:47 AM 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. > > 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. >> >> On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad <abe...@chromium.org> wrote: >> >>> Thanks for the feedback and the LGTMs, everyone! >>> >>> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers <rby...@chromium.org> wrote: >>> >>>> 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 >>>> >>>> On Thu, Jul 15, 2021 at 11:18 AM Ali Beyad <abe...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> 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 >>>>> <https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.x5gzpen7eyc> >>>>> 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! >>>>> >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> On Mon, Jul 12, 2021 at 4:55 PM 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. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -mike >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Jul 10, 2021 at 1:31 AM Ali Beyad <abe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> On Thu, Jul 8, 2021 at 2:06 PM Jason Chase <cha...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, July 8, 2021 at 1:07:59 PM UTC-4 Ali Beyad wrote: >>>>>>>>>> >>>>>>>>>>> *Contact emails *aaron...@chromium.org, jadekess...@chromium.org, >>>>>>>>>>> miketa...@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 >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=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 >>>>>>>>>>> <https://twitter.com/rmondello/status/943545865204989953?lang=en> >>>>>>>>>>> in the past, but somewhat reverted that decision >>>>>>>>>>> <https://bugs.webkit.org/show_bug.cgi?id=182629#c6>. 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. >>>>>>>>>>> >>>>>>>>>> This sounds like the trial to opt-in (and opt-out) for the Page >>>>>>>>>> Freezing intervention >>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/CWOstYR9rdc/m/knP4dVdKFAAJ>. >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please see the design document >>>>>>>>>>> <https://docs.google.com/document/d/1feIxK9S7oNgT2oGGebbxE9X0O-4wTKcsP_gRaY99tq4/edit#heading=h.2navvbygwxwb> >>>>>>>>>>> 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 >>>>>>>>>>> <https://web.dev/migrate-to-ua-ch/>. 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 >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> 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+unsubscr...@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 >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJKADxFLTHtvYPzNzF%3Dy5wP4x%2BaK1cF3RRCWii7UjV54EjkSw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>> 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+unsubscr...@chromium.org. >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BWdJ_4jkExO4p9GdCdc7BUa8GBK0eota1q8EfEi%3D5%2BBuj3jCw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BWdJ_5jd3BmzbnJxPGzJTU%2BHCJcWO1sDbKgTpjsichC%2Bzq_2A%40mail.gmail.com.
