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 On Fri, Sep 30, 2022 at 7:34 PM Mike Taylor <miketa...@chromium.org> wrote: > 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). > > > Rick > > On Wed, Sep 14, 2022 at 3:03 PM Nir M <getn...@gmail.com> wrote: > >> 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 >> >> >> On Tuesday, July 26, 2022 at 9:27:20 PM UTC+3 mike...@chromium.org wrote: >> >>> 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 >>> >>> On 7/26/22 1:40 PM, Noah Lemen wrote: >>> >>> 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. >>> On Thursday, October 14, 2021 at 5:29:45 PM UTC-4 abe...@chromium.org >>> wrote: >>> >>>> 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 >>>> >>>> On Tue, Sep 14, 2021 at 9:39 AM Ali Beyad <abe...@chromium.org> wrote: >>>> >>>>> 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 *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 >>>>>>>>>>>>>>>> <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+...@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+...@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+...@chromium.org. >>> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a13aa138-d0de-4086-a9c8-e3973af041fcn%40chromium.org?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/CAKXHy%3DdZwaXUeD4QgXtof9jcdv2iqnOTH3p3PYo0EiQN2_1YMA%40mail.gmail.com.