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

On Wed, Sep 14, 2022 at 3:03 PM Nir M <[email protected]> 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 [email protected] 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 [email protected]
>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the feedback and the LGTMs, everyone!
>>>>>>>
>>>>>>> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jul 15, 2021 at 4:02 AM Mike West <[email protected]>
>>>>>>>>> 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 <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Mike,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your questions.  Answers inline.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 12, 2021 at 9:15 AM Mike West <[email protected]>
>>>>>>>>>>> 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 <[email protected]>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thursday, July 8, 2021 at 1:07:59 PM UTC-4 Ali Beyad wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Contact emails *[email protected], [email protected],
>>>>>>>>>>>>>>> [email protected], [email protected]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>>>> 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 [email protected].
>>>>>>>>> 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 [email protected].
>>
>> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9tZQynw7VkJH7iDioD%3DL75QT%2BJtQbshcnLQT%2BWWo%2BnpQ%40mail.gmail.com.

Reply via email to