LGTM3 On Tue, Oct 4, 2022 at 11:13 AM Mike West <mk...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdZwaXUeD4QgXtof9jcdv2iqnOTH3p3PYo0EiQN2_1YMA%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/CAL5BFfVw%2B4dDwEFq09zS_TwJhhMwWGGuLV2rpRazYbjbj9Preg%40mail.gmail.com.
