Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

the code point PR is merged. Feel free to take a look again. Thanks. 

On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote:

> create a PR for the code point change on the RFC draft, will work on 
> there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 
>
> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:
>
>> Thanks, it will be helpful to make sure this is documented outside of 
>> Chromium. I will also chat with some folks on Microsoft’s end that both own 
>> server implementations and have more IETF experience to explore how we can 
>> help with moving things forward.
>>
>>  
>>
>> *From:* Victor Tan  
>> *Sent:* Wednesday, January 24, 2024 9:00 AM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; blink-dev <
>> blink-dev@chromium.org>; Erik Anderson ; 
>> Chris Harrelson ; David Benjamin <
>> david...@chromium.org>; Mike Taylor ; Victor Tan 
>> ; Rick Byers 
>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>
>>  
>>
>> You don't often get email from victor...@chromium.org. Learn why this is 
>> important <https://aka.ms/LearnAboutSenderIdentification>
>>
>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
>> document the new code point regarding the early experiment. 
>>
>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>>
>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>>
>> Oof, I agree it's not good that the only documentation for the actual 
>> code point value is in Chromium code - that's the sort of thing our blink 
>> I2S process is supposed to prevent. In addition to confusion, there's also 
>> potential IP-risk downsides to this. Our blink process is generally to 
>> block shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>>  
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>>  
>>
>> +1 to defining these codepoints somewhere. Where are such codepoints 
>> typically defined? I'd have assumed they'd go into one of the relevant 
>> I-Ds..
>>
>>   
>>
>>  
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>>  
>>
>> Rick
>>
>>  
>>
>>  
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> To be clarify,  currently David is not working on the standardizing ALPS 
>> feature.   
>>
>>  
>>
>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>
>> Hi Erik, 
>>
>> We are actively working on it, but we need to put more efforts to 
>> standardization. 
>>
>> In the last serval IETF, David is the only person is talking about the 
>> ALPS feature.  We'd glad to combine more efforts to move it forward to 
>> standardization.
>>
>>  
>>
>> Bests,
>>
>> Victor 
>>
>> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>>
>> Is the ALPS draft being actively worked on?
>>
>>  
>>
>> Various teams at Microsoft that own w

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

create a PR for the code point change on the RFC draft, will work on 
there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 

On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:

> Thanks, it will be helpful to make sure this is documented outside of 
> Chromium. I will also chat with some folks on Microsoft’s end that both own 
> server implementations and have more IETF experience to explore how we can 
> help with moving things forward.
>
>  
>
> *From:* Victor Tan  
> *Sent:* Wednesday, January 24, 2024 9:00 AM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; blink-dev <
> blink-dev@chromium.org>; Erik Anderson ; 
> Chris Harrelson ; David Benjamin <
> david...@chromium.org>; Mike Taylor ; Victor Tan <
> victor...@chromium.org>; Rick Byers 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> You don't often get email from victor...@chromium.org. Learn why this is 
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
> document the new code point regarding the early experiment. 
>
> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>
> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>
> Oof, I agree it's not good that the only documentation for the actual code 
> point value is in Chromium code - that's the sort of thing our blink I2S 
> process is supposed to prevent. In addition to confusion, there's also 
> potential IP-risk downsides to this. Our blink process is generally to 
> block shipping on the existence of some specification for everything 
> necessary for a compatible implementation in a forum that ensures IP 
> protection. While this isn't typically an adoption barrier for many 
> companies, I know it has been in the past for some (including Microsoft). 
> This doesn't mean we have to block on getting consensus in the "right" 
> standards venue, we can just do a monkey-patch spec in a venue like the 
> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
> contribution. Then we can ship it as an "incubation" while doing the 
> standards maturation work in parallel. Erik, can you comment on the extent 
> to which such incubation spec work would help with Microsoft adoption?
>
>  
>
> Victor, is there any chance you can throw something together quickly (spec 
> PR or monkey-patch) that would cover the gaps in what's necessary for 
> compatible implementations? This particular delta seems very tiny and 
> straightforward to me, so I was originally thinking I'd just approve it. 
> But in principle I don't think we should be continuing to approve changes 
> to APIs which we realize are struggling with adoption due to the standards 
> work not quite being up to our I2S bar.
>
>  
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>
>   
>
>  
>
> Erik, thank you for your offer of help on the standardization front! It 
> definitely sounds to me like we should be pushing on the full standards 
> effort in parallel to this specific intent. Having Microsoft and Google 
> work together on that would hopefully be able to accelerate it.
>
>  
>
> Rick
>
>  
>
>  
>
> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> To be clarify,  currently David is not working on the standardizing ALPS 
> feature.   
>
>  
>
> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>
> Hi Erik, 
>
> We are actively working on it, but we need to put more efforts to 
> standardization. 
>
> In the last serval IETF, David is the only person is talking about the 
> ALPS feature.  We'd glad to combine more efforts to move it forward to 
> standardization.
>
>  
>
> Bests,
>
> Victor 
>
> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>
> Is the ALPS draft being actively worked on?
>
>  
>
> Various teams at Microsoft that own web sites leveraging client hints have 
> expressed interest in using it, but the lack of a finalized standard has 
> significantly slowed conversations with the teams that own the server code 
> that would need to add support first.
>
>  
>
> Are you looking for help in moving standardization forward?
>
>  
>
> *From:* Yoav Weiss (@Shopify)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.org>; David Benjamin ; Mike Taylor 
> 
> *Subject:* Re: [blink

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
document the new code point regarding the early experiment. 

On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:

> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>
>> Oof, I agree it's not good that the only documentation for the actual 
>> code point value is in Chromium code - that's the sort of thing our blink 
>> I2S process is supposed to prevent. In addition to confusion, there's also 
>> potential IP-risk downsides to this. Our blink process is generally to 
>> block shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>   
>
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>> Rick
>>
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> To be clarify,  currently David is not working on the standardizing ALPS 
>>> feature.  
>>>
>>>
>>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>>
>>>> Hi Erik,
>>>> We are actively working on it, but we need to put more efforts to 
>>>> standardization. 
>>>> In the last serval IETF, David is the only person is talking about the 
>>>> ALPS feature.  We'd glad to combine more efforts to move it forward to 
>>>> standardization.
>>>>
>>>> Bests,
>>>> Victor 
>>>>
>>>> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>>>>
>>>>> Is the ALPS draft being actively worked on?
>>>>>
>>>>>  
>>>>>
>>>>> Various teams at Microsoft that own web sites leveraging client hints 
>>>>> have expressed interest in using it, but the lack of a finalized standard 
>>>>> has significantly slowed conversations with the teams that own the server 
>>>>> code that would need to add support first.
>>>>>
>>>>>  
>>>>>
>>>>> Are you looking for help in moving standardization forward?
>>>>>
>>>>>  
>>>>>
>>>>> *From:* Yoav Weiss (@Shopify)  
>>>>> *Sent:* Monday, January 22, 2024 7:39 AM
>>>>> *To:* Victor Tan 
>>>>> *Cc:* blink-dev ; Chris Harrelson <
>>>>> chri...@chromium.org>; David Benjamin ; Mike 
>>>>> Taylor 
>>>>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>>>>
>>>>>  
>>>>>
>>>>> Is the old code point defined somewhere? Would it be possible to add 
>>>>> such a definition to one of the I-Ds? Or is this something that's not 
>>>>> traditionally defined in IETF drafts?
>>>>>
>>>>>  
>>>>>
>>>>> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  
>>>>> wrote:
>&g

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

['Victor Tan' via blink-dev]

To be clarify,  currently David is not working on the standardizing ALPS 
feature.  


On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:

> Hi Erik,
> We are actively working on it, but we need to put more efforts to 
> standardization. 
> In the last serval IETF, David is the only person is talking about the 
> ALPS feature.  We'd glad to combine more efforts to move it forward to 
> standardization.
>
> Bests,
> Victor 
>
> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>
>> Is the ALPS draft being actively worked on?
>>
>>  
>>
>> Various teams at Microsoft that own web sites leveraging client hints 
>> have expressed interest in using it, but the lack of a finalized standard 
>> has significantly slowed conversations with the teams that own the server 
>> code that would need to add support first.
>>
>>  
>>
>> Are you looking for help in moving standardization forward?
>>
>>  
>>
>> *From:* Yoav Weiss (@Shopify)  
>> *Sent:* Monday, January 22, 2024 7:39 AM
>> *To:* Victor Tan 
>> *Cc:* blink-dev ; Chris Harrelson <
>> chri...@chromium.org>; David Benjamin ; Mike 
>> Taylor 
>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>
>>  
>>
>> Is the old code point defined somewhere? Would it be possible to add such 
>> a definition to one of the I-Ds? Or is this something that's not 
>> traditionally defined in IETF drafts?
>>
>>  
>>
>> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  wrote:
>>
>> Currently, It's on the code: 
>> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
>>
>> Once we standardize the ALPS RFC draft, we can finalize the value.  Hope 
>> this helps. 
>>
>> On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote:
>>
>> Thanks for clarifying. Last question: where in the specifications is the 
>> new 17613 code point documented?
>>
>>  
>>
>> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor  
>> wrote:
>>
>> In our OWNERS meeting this week, there was some confusion on what's being 
>> proposed here (which is understandable, this isn't quite a typical intent 
>> for web exposed feature). Here's a summary of what we're trying to 
>> accomplish:
>>
>> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, 
>> which relies on the TLS ALPS protocol extension.
>> 2) There are 2 parts to this: the client being able to understand 
>> ALPS/ACCEPT_CH (and in return do something useful), and the server being 
>> able to send it.
>> 3) Because of a (long fixed) bug present in Chromium's implementation, 
>> it's risky for a server to send too much data via ACCEPT_CH, so it's 
>> usefulness is potentially limited.
>> 4) In order to guarantee that older clients don't have this bug, we 
>> propose to rev the version (aka, code point) at the protocol layer. This 
>> way, if a server sends the new code point and the client understands it, it 
>> can send a larger payload without triggering the bug (which may result in 
>> sad things like a connection being refused).
>> 5) This is sort of web observable, but right now if servers that support 
>> the old code point continue to send the old code point - nothing will 
>> break. Chromium will support both for now, with hopes to deprecate and 
>> remove the older one in the future when we're confident it won't result in 
>> performance regressions for servers sending ACCEPT_CH (since this is a 
>> performance optimization).
>>
>> I hope that helps clear it up, and I'm sure Victor or David will chime in 
>> if I'm getting something wrong. :)
>>
>> And to be clear - this isn't a request for a deprecation or removal 
>> (yet), but for shipping the new code point.
>>
>> On 1/17/24 11:16 AM, Victor Tan wrote:
>>
>> If the server received the new code point, while it doesn't support, the 
>> ALPS extension will ignore. This also mean client might not know the 
>> server's client hints preferences before the first request. Currently, only 
>> few sites using the ALPS extension.  As TLS extension is negotiated, the 
>> server need to support both code points during the transition period, after 
>> some time, the server can drop the old one.  
>>
>>  
>>
>> On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:
>>
>> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:
>>
>> *Contact emails* 
>>
>&

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

['Victor Tan' via blink-dev]

Hi Erik,
We are actively working on it, but we need to put more efforts to 
standardization. 
In the last serval IETF, David is the only person is talking about the ALPS 
feature.  We'd glad to combine more efforts to move it forward to 
standardization.

Bests,
Victor 

On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:

> Is the ALPS draft being actively worked on?
>
>  
>
> Various teams at Microsoft that own web sites leveraging client hints have 
> expressed interest in using it, but the lack of a finalized standard has 
> significantly slowed conversations with the teams that own the server code 
> that would need to add support first.
>
>  
>
> Are you looking for help in moving standardization forward?
>
>  
>
> *From:* Yoav Weiss (@Shopify)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.org>; David Benjamin ; Mike Taylor 
> 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> Is the old code point defined somewhere? Would it be possible to add such 
> a definition to one of the I-Ds? Or is this something that's not 
> traditionally defined in IETF drafts?
>
>  
>
> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan  wrote:
>
> Currently, It's on the code: 
> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
>
> Once we standardize the ALPS RFC draft, we can finalize the value.  Hope 
> this helps. 
>
> On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote:
>
> Thanks for clarifying. Last question: where in the specifications is the 
> new 17613 code point documented?
>
>  
>
> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor  wrote:
>
> In our OWNERS meeting this week, there was some confusion on what's being 
> proposed here (which is understandable, this isn't quite a typical intent 
> for web exposed feature). Here's a summary of what we're trying to 
> accomplish:
>
> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, 
> which relies on the TLS ALPS protocol extension.
> 2) There are 2 parts to this: the client being able to understand 
> ALPS/ACCEPT_CH (and in return do something useful), and the server being 
> able to send it.
> 3) Because of a (long fixed) bug present in Chromium's implementation, 
> it's risky for a server to send too much data via ACCEPT_CH, so it's 
> usefulness is potentially limited.
> 4) In order to guarantee that older clients don't have this bug, we 
> propose to rev the version (aka, code point) at the protocol layer. This 
> way, if a server sends the new code point and the client understands it, it 
> can send a larger payload without triggering the bug (which may result in 
> sad things like a connection being refused).
> 5) This is sort of web observable, but right now if servers that support 
> the old code point continue to send the old code point - nothing will 
> break. Chromium will support both for now, with hopes to deprecate and 
> remove the older one in the future when we're confident it won't result in 
> performance regressions for servers sending ACCEPT_CH (since this is a 
> performance optimization).
>
> I hope that helps clear it up, and I'm sure Victor or David will chime in 
> if I'm getting something wrong. :)
>
> And to be clear - this isn't a request for a deprecation or removal (yet), 
> but for shipping the new code point.
>
> On 1/17/24 11:16 AM, Victor Tan wrote:
>
> If the server received the new code point, while it doesn't support, the 
> ALPS extension will ignore. This also mean client might not know the 
> server's client hints preferences before the first request. Currently, only 
> few sites using the ALPS extension.  As TLS extension is negotiated, the 
> server need to support both code points during the transition period, after 
> some time, the server can drop the old one.  
>
>  
>
> On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:
>
> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:
>
> *Contact emails* 
>
> vict...@chromium.org, mike...@chromium.org, davi...@chromium.org
>
>
> *Explainer* 
>
>
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md
>  
>
>
> *Specification* 
>
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability  
>
> https://tools.ietf.org/html/draft-vvv-httpbis-alps 
>
> https://tools.ietf.org/html/draft-vvv-tls-alps
>
>  
>
> *Summary* 
>
> Shipping a new code point (17613) for TLS ALPS extension to allow adding 
> more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame.

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

Currently, It's on the 
code: 
https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
Once we standardize the ALPS RFC draft, we can finalize the value.  Hope 
this helps. 

On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote:

> Thanks for clarifying. Last question: where in the specifications is the 
> new 17613 code point documented?
>
> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor  
> wrote:
>
>> In our OWNERS meeting this week, there was some confusion on what's being 
>> proposed here (which is understandable, this isn't quite a typical intent 
>> for web exposed feature). Here's a summary of what we're trying to 
>> accomplish:
>>
>> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, 
>> which relies on the TLS ALPS protocol extension.
>> 2) There are 2 parts to this: the client being able to understand 
>> ALPS/ACCEPT_CH (and in return do something useful), and the server being 
>> able to send it.
>> 3) Because of a (long fixed) bug present in Chromium's implementation, 
>> it's risky for a server to send too much data via ACCEPT_CH, so it's 
>> usefulness is potentially limited.
>> 4) In order to guarantee that older clients don't have this bug, we 
>> propose to rev the version (aka, code point) at the protocol layer. This 
>> way, if a server sends the new code point and the client understands it, it 
>> can send a larger payload without triggering the bug (which may result in 
>> sad things like a connection being refused).
>> 5) This is sort of web observable, but right now if servers that support 
>> the old code point continue to send the old code point - nothing will 
>> break. Chromium will support both for now, with hopes to deprecate and 
>> remove the older one in the future when we're confident it won't result in 
>> performance regressions for servers sending ACCEPT_CH (since this is a 
>> performance optimization).
>>
>> I hope that helps clear it up, and I'm sure Victor or David will chime in 
>> if I'm getting something wrong. :)
>>
>> And to be clear - this isn't a request for a deprecation or removal 
>> (yet), but for shipping the new code point.
>> On 1/17/24 11:16 AM, Victor Tan wrote:
>>
>> If the server received the new code point, while it doesn't support, the 
>> ALPS extension will ignore. This also mean client might not know the 
>> server's client hints preferences before the first request. Currently, only 
>> few sites using the ALPS extension.  As TLS extension is negotiated, the 
>> server need to support both code points during the transition period, after 
>> some time, the server can drop the old one.  
>>
>> On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:
>>
>>> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:
>>>
>>> Contact emails 
>>>
>>> victor...@chromium.org, miketa...@chromium.org, david...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/WICG/client-hints-infrastructure/
>>> blob/main/reliability.md 
>>>
>>> Specification 
>>>
>>> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability 
>>>  
>>>
>>> https://tools.ietf.org/html/draft-vvv-httpbis-alps 
>>>
>>> https://tools.ietf.org/html/draft-vvv-tls-alps
>>>
>>>  
>>> Summary 
>>>
>>> Shipping a new code point (17613) for TLS ALPS extension to allow adding 
>>> more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 
>>> frame with the existing TLS ALPS extension code point (17513) had an 
>>> arithmetic overflow bug <https://crbug.com/1292069> in the Chrome ALPS 
>>> decoder. It limits the capability to add more than 128 bytes data (in 
>>> theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH 
>>> frame. With the new ALPS code point, we can fully mitigate the issue.
>>>
>>> Blink component 
>>>
>>> Blink>Network>ClientHints 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C=2>
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/549 
>>>
>>> TAG review status 
>>>
>>> Closed
>>>
>>> Risks
>>> Interoperability and Compatibility 
>>>
>>> This is switching to a new code point for the TLS ALPS extension. It 
>>> won’t change the design of ALPS

Re: [blink-dev] Intent to Ship: New ALPS code point

[Victor Tan]

> TAG review is from 2021, has anything changed since then or is it still 
the same feature/spec that is shipping now?

It's the same feature already shipping in the Blink. I don't think we have 
change anything for the ALPS. This intend is only a TLS extension code 
point change. 
what we do is trying to mitigate a bug in the old code point, not to 
re-active or de-active any feature. 




On Wednesday, January 17, 2024 at 11:16:47 AM UTC-5 Manuel Rego wrote:

>
>
> On 13/01/2024 00:08, Victor Tan wrote:
> > TAG review
> > 
> > https://github.com/w3ctag/design-reviews/issues/549 
> > <https://github.com/w3ctag/design-reviews/issues/549>
>
> TAG review is from 2021, has anything changed since then or is it still 
> the same feature/spec that is shipping now?
>
> > Firefox: Pending 
> https://github.com/mozilla/standards-positions/issues/510
> > <https://github.com/mozilla/standards-positions/issues/510>
>
> That's also quite old. Could you do a ping there, explaining the 
> willingness to ship in Blink, trying to reactivate it?
>
> > Safari: Pending 
> > https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html 
> > <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html>
>
> For WebKit I think we should fill a new standards position request at:
> https://github.com/WebKit/standards-positions/issues
>
> Thanks,
> Rego
>

-- 
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/e2359a13-6661-4346-8677-1081e9f709b3n%40chromium.org.

[blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

If the server received the new code point, while it doesn't support, the 
ALPS extension will ignore. This also mean client might not know the 
server's client hints preferences before the first request. Currently, only 
few sites using the ALPS extension.  As TLS extension is negotiated, the 
server need to support both code points during the transition period, after 
some time, the server can drop the old one. 

On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:

> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:
>
> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org, david...@chromium.org
>
> Explainer
>
> https://github.com/WICG/client-hints-infrastructure/
> blob/main/reliability.md 
>
> Specification
>
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability  
>
> https://tools.ietf.org/html/draft-vvv-httpbis-alps 
>
> https://tools.ietf.org/html/draft-vvv-tls-alps
>
>  
> Summary
>
> Shipping a new code point (17613) for TLS ALPS extension to allow adding 
> more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 
> frame with the existing TLS ALPS extension code point (17513) had an 
> arithmetic overflow bug <https://crbug.com/1292069> in the Chrome ALPS 
> decoder. It limits the capability to add more than 128 bytes data (in 
> theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH 
> frame. With the new ALPS code point, we can fully mitigate the issue.
>
> Blink component
>
> Blink>Network>ClientHints 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C=2>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/549 
>
> TAG review status
>
> Closed
>
> Risks
> Interoperability and Compatibility
>
> This is switching to a new code point for the TLS ALPS extension. It won’t 
> change the design of ALPS and ACCEPT_CH mechanism implementation.  The main 
> source of compatibility risk is that it causes conflicts with ALPS 
> negotiation since some clients could still use the old code point while 
> others are switching to use the new code point.  The ALPS extension could 
> be ignored if the code point doesn’t match during negotiation, which means 
> the server's client hints preferences won’t be delivered in the ACCEPT_CH 
> HTTP/2 and HTTP/3 frame.  We mitigate this by enabling servers to support 
> both code points, monitoring both code points usage and removing the old 
> ALPS code point support in a future intent once the usage is low enough. We 
> also split the rollout into two phases: we first start to enable the new 
> ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and 
> then eventually enable the new code point with HTTP/2 frame.
>
>
> Does the server have an indication if the client in question supports the 
> newer code point?
> If not, what would we expect servers that support the newer code point to 
> do?
>
>  
>
>
> Edge: No signals
>
> Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
> Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-
> April/031768.html
>
> Web/Framework developers: https://twitter.com/Sawtaytoes/status/
> 1369031447940526080 https://twitter.com/_jayphelps/status/
> 1369023028735148032
>
> Activation
>
> The site’s TLS and HTTP serving application would need to be updated to 
> support this new code point. We aren’t aware of many sites using this 
> feature yet, however.
>
> Debuggability
>
> No special DevTools support needed. The effects of the code point change 
> of ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the 
> NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is 
> negotiated successfully. 
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests 
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?
>
> No, this feature is tested with browser-side tests. We can’t test 
> TLS-adjacent features currently through web-platform-tests. See this issue: 
> https://github.com/web-platform-tests/wpt/issues/20159   
>
> Flag name
>
> UseNewAlpsCodepointHttp2
>
> UseNewAlpsCodepointQUIC
>
> Tracking bug
>
> b/289087287 
>
> Launch bug
>
> https://launch.corp.google.com/launch/4299022 
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5149147365900288 
>
>

-- 
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/1d4cd923-5487-4cdf-a167-4da7b6a0a84cn%40chromium.org.

[blink-dev] Intent to Ship: New ALPS code point

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org, david...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md
 

Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability  

https://tools.ietf.org/html/draft-vvv-httpbis-alps 

https://tools.ietf.org/html/draft-vvv-tls-alps

 
Summary

Shipping a new code point (17613) for TLS ALPS extension to allow adding 
more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 
frame with the existing TLS ALPS extension code point (17513) had an 
arithmetic overflow bug  in the Chrome ALPS 
decoder. It limits the capability to add more than 128 bytes data (in 
theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH 
frame. With the new ALPS code point, we can fully mitigate the issue.

Blink component

Blink>Network>ClientHints 


TAG review

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

TAG review status

Closed

Risks
Interoperability and Compatibility

This is switching to a new code point for the TLS ALPS extension. It won’t 
change the design of ALPS and ACCEPT_CH mechanism implementation.  The main 
source of compatibility risk is that it causes conflicts with ALPS 
negotiation since some clients could still use the old code point while 
others are switching to use the new code point.  The ALPS extension could 
be ignored if the code point doesn’t match during negotiation, which means 
the server's client hints preferences won’t be delivered in the ACCEPT_CH 
HTTP/2 and HTTP/3 frame.  We mitigate this by enabling servers to support 
both code points, monitoring both code points usage and removing the old 
ALPS code point support in a future intent once the usage is low enough. We 
also split the rollout into two phases: we first start to enable the new 
ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and 
then eventually enable the new code point with HTTP/2 frame.

Edge: No signals

Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
Safari: Pending 
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html

Web/Framework developers: 
https://twitter.com/Sawtaytoes/status/1369031447940526080 
https://twitter.com/_jayphelps/status/1369023028735148032

Activation

The site’s TLS and HTTP serving application would need to be updated to 
support this new code point. We aren’t aware of many sites using this 
feature yet, however.

Debuggability

No special DevTools support needed. The effects of the code point change of 
ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the 
NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is 
negotiated successfully. 

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

Yes

Is this feature fully tested by web-platform-tests 

?

No, this feature is tested with browser-side tests. We can’t test 
TLS-adjacent features currently through web-platform-tests. See this issue: 
https://github.com/web-platform-tests/wpt/issues/20159   

Flag name

UseNewAlpsCodepointHttp2

UseNewAlpsCodepointQUIC

Tracking bug

b/289087287 

Launch bug

https://launch.corp.google.com/launch/4299022 

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5149147365900288 

-- 
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/2c1aac5d-163f-44e6-b16d-436bb3ea3c3an%40chromium.org.

Re: [blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

[Victor Tan]

Hi blink-dev,

User-agent client hint is currently ramping up to 100% of the stable 
release population, enabling default TOT on Android WebView. 

Best,
Victor

On Tuesday, September 12, 2023 at 1:09:55 PM UTC-4 Victor Tan wrote:

> Hi blink-dev,
>
> User-agent client hint is currently ramping up to 10% of the stable 
> release population on Android WebView. 
>
> Best,
> Victor
>
> On Tuesday, August 29, 2023 at 2:13:52 PM UTC-4 Victor Tan wrote:
>
>> Hi blink-dev,
>>
>> User-agent client hint is currently ramping up to 1% of the stable 
>> release population on Android WebView. 
>> New schedule timeline as follows:
>> 1% ~ Aug 29, 2023
>> 10% ~ Sep 12, 2023
>> TOT default ~ Sep 26, 2023
>>
>> Thanks.
>>
>> Best,
>> Victor
>>
>> On Thursday, August 24, 2023 at 7:39:59 PM UTC-4 TAMURA, Kent wrote:
>>
>>> LGTM3.
>>>
>>>
>>> On Fri, Aug 25, 2023 at 12:34 AM 'Rick Byers' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Sorry for the delay, LGTM2
>>>>
>>>> I'm surprised you need a ramp-up for this. New APIs are generally safe 
>>>> so we usually don't finch them. But if you'd rather do a finch roll-out 
>>>> for 
>>>> extra safety, I have no objection.
>>>>
>>>> Rick
>>>>
>>>> On Thu, Aug 24, 2023 at 9:10 AM Peter Beverloo  
>>>> wrote:
>>>>
>>>>> Non-API OWNER LGTM to proceed on WebView - thank you for all the 
>>>>> diligence you've done on understanding and navigating the platform 
>>>>> constraints!
>>>>>
>>>>> Thanks,
>>>>> Peter
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2023 at 10:45 PM 'Victor Tan' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> can anyone take a look at this?   thanks.   :)
>>>>>>
>>>>>> On Wednesday, August 16, 2023 at 1:40:38 PM UTC-4 Chris Harrelson 
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM1
>>>>>>>
>>>>>>> On Tue, Aug 15, 2023 at 2:19 PM Victor Tan  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Currently, we haven't confirmed the public plan for 
>>>>>>>> user-agent reduction on WeView. We won't do user-agent reduction 
>>>>>>>> before 
>>>>>>>> completing roll-out user-agent client hints. 
>>>>>>>>
>>>>>>>> Victor
>>>>>>>>
>>>>>>>> On Tue, Aug 15, 2023 at 5:13 PM Bhanu Vattikonda  
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Is there a corresponding User-Agent reduction plan for Android 
>>>>>>>>> WebView?
>>>>>>>>>
>>>>>>>>> On Tuesday, August 15, 2023 at 12:30:17 PM UTC-7 
>>>>>>>>> vict...@chromium.org wrote:
>>>>>>>>>
>>>>>>>>>> Contact emails
>>>>>>>>>>
>>>>>>>>>> vict...@chromium.org, mike...@chromium.org
>>>>>>>>>>
>>>>>>>>>> Explainer
>>>>>>>>>>
>>>>>>>>>> https://github.com/WICG/client-hints-infrastructure#readme
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>>>>>>>>
>>>>>>>>>> Specification
>>>>>>>>>>
>>>>>>>>>> https://wicg.github.io/ua-client-hints/
>>>>>>>>>>
>>>>>>>>>> Summary
>>>>>>>>>>
>>>>>>>>>> User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate 
>>>>>>>>>> and replace the User-Agent header to reduce the passive 
>>>>>>>>>> fingerprinting 
>>>>>>>>>> surface we expose via HTTP requests. As we previously rolled-out 
>>>>>>>>>> user-agent 
>>>>>>>>>> client hints on Windows, Mac, Linux, Chrome OS and Android, we 
>>>>>

Re: [blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

[Victor Tan]

Hi blink-dev,

User-agent client hint is currently ramping up to 10% of the stable release 
population on Android WebView. 

Best,
Victor

On Tuesday, August 29, 2023 at 2:13:52 PM UTC-4 Victor Tan wrote:

> Hi blink-dev,
>
> User-agent client hint is currently ramping up to 1% of the stable release 
> population on Android WebView. 
> New schedule timeline as follows:
> 1% ~ Aug 29, 2023
> 10% ~ Sep 12, 2023
> TOT default ~ Sep 26, 2023
>
> Thanks.
>
> Best,
> Victor
>
> On Thursday, August 24, 2023 at 7:39:59 PM UTC-4 TAMURA, Kent wrote:
>
>> LGTM3.
>>
>>
>> On Fri, Aug 25, 2023 at 12:34 AM 'Rick Byers' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Sorry for the delay, LGTM2
>>>
>>> I'm surprised you need a ramp-up for this. New APIs are generally safe 
>>> so we usually don't finch them. But if you'd rather do a finch roll-out for 
>>> extra safety, I have no objection.
>>>
>>> Rick
>>>
>>> On Thu, Aug 24, 2023 at 9:10 AM Peter Beverloo  
>>> wrote:
>>>
>>>> Non-API OWNER LGTM to proceed on WebView - thank you for all the 
>>>> diligence you've done on understanding and navigating the platform 
>>>> constraints!
>>>>
>>>> Thanks,
>>>> Peter
>>>>
>>>>
>>>> On Wed, Aug 23, 2023 at 10:45 PM 'Victor Tan' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> can anyone take a look at this?   thanks.   :)
>>>>>
>>>>> On Wednesday, August 16, 2023 at 1:40:38 PM UTC-4 Chris Harrelson 
>>>>> wrote:
>>>>>
>>>>>> LGTM1
>>>>>>
>>>>>> On Tue, Aug 15, 2023 at 2:19 PM Victor Tan  
>>>>>> wrote:
>>>>>>
>>>>>>> Currently, we haven't confirmed the public plan for 
>>>>>>> user-agent reduction on WeView. We won't do user-agent reduction before 
>>>>>>> completing roll-out user-agent client hints. 
>>>>>>>
>>>>>>> Victor
>>>>>>>
>>>>>>> On Tue, Aug 15, 2023 at 5:13 PM Bhanu Vattikonda  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Is there a corresponding User-Agent reduction plan for Android 
>>>>>>>> WebView?
>>>>>>>>
>>>>>>>> On Tuesday, August 15, 2023 at 12:30:17 PM UTC-7 
>>>>>>>> vict...@chromium.org wrote:
>>>>>>>>
>>>>>>>>> Contact emails
>>>>>>>>>
>>>>>>>>> vict...@chromium.org, mike...@chromium.org
>>>>>>>>>
>>>>>>>>> Explainer
>>>>>>>>>
>>>>>>>>> https://github.com/WICG/client-hints-infrastructure#readme
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>>
>>>>>>>>> https://wicg.github.io/ua-client-hints/
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>>
>>>>>>>>> User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate 
>>>>>>>>> and replace the User-Agent header to reduce the passive 
>>>>>>>>> fingerprinting 
>>>>>>>>> surface we expose via HTTP requests. As we previously rolled-out 
>>>>>>>>> user-agent 
>>>>>>>>> client hints on Windows, Mac, Linux, Chrome OS and Android, we intend 
>>>>>>>>> to 
>>>>>>>>> proceed with shipping user-agent client hints on Android WebView. For 
>>>>>>>>> overridden user-agent strings, we only populate user-agent client 
>>>>>>>>> hints if 
>>>>>>>>> the overridden user-agent contains the default user-agent. In this 
>>>>>>>>> case, we 
>>>>>>>>> will only generate low-entropy user-agent client hints If users also 
>>>>>>>>> override the user-agent string through command-line.
>>>>>>>>>
>

Re: [blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

[Victor Tan]

Hi blink-dev,

User-agent client hint is currently ramping up to 1% of the stable release 
population on Android WebView. 
New schedule timeline as follows:
1% ~ Aug 29, 2023
10% ~ Sep 12, 2023
TOT default ~ Sep 26, 2023

Thanks.

Best,
Victor

On Thursday, August 24, 2023 at 7:39:59 PM UTC-4 TAMURA, Kent wrote:

> LGTM3.
>
>
> On Fri, Aug 25, 2023 at 12:34 AM 'Rick Byers' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Sorry for the delay, LGTM2
>>
>> I'm surprised you need a ramp-up for this. New APIs are generally safe so 
>> we usually don't finch them. But if you'd rather do a finch roll-out for 
>> extra safety, I have no objection.
>>
>> Rick
>>
>> On Thu, Aug 24, 2023 at 9:10 AM Peter Beverloo  
>> wrote:
>>
>>> Non-API OWNER LGTM to proceed on WebView - thank you for all the 
>>> diligence you've done on understanding and navigating the platform 
>>> constraints!
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> On Wed, Aug 23, 2023 at 10:45 PM 'Victor Tan' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> can anyone take a look at this?   thanks.   :)
>>>>
>>>> On Wednesday, August 16, 2023 at 1:40:38 PM UTC-4 Chris Harrelson wrote:
>>>>
>>>>> LGTM1
>>>>>
>>>>> On Tue, Aug 15, 2023 at 2:19 PM Victor Tan  
>>>>> wrote:
>>>>>
>>>>>> Currently, we haven't confirmed the public plan for 
>>>>>> user-agent reduction on WeView. We won't do user-agent reduction before 
>>>>>> completing roll-out user-agent client hints. 
>>>>>>
>>>>>> Victor
>>>>>>
>>>>>> On Tue, Aug 15, 2023 at 5:13 PM Bhanu Vattikonda  
>>>>>> wrote:
>>>>>>
>>>>>>> Is there a corresponding User-Agent reduction plan for Android 
>>>>>>> WebView?
>>>>>>>
>>>>>>> On Tuesday, August 15, 2023 at 12:30:17 PM UTC-7 
>>>>>>> vict...@chromium.org wrote:
>>>>>>>
>>>>>>>> Contact emails
>>>>>>>>
>>>>>>>> vict...@chromium.org, mike...@chromium.org
>>>>>>>>
>>>>>>>> Explainer
>>>>>>>>
>>>>>>>> https://github.com/WICG/client-hints-infrastructure#readme
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>>>>>>
>>>>>>>> Specification
>>>>>>>>
>>>>>>>> https://wicg.github.io/ua-client-hints/
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate 
>>>>>>>> and replace the User-Agent header to reduce the passive fingerprinting 
>>>>>>>> surface we expose via HTTP requests. As we previously rolled-out 
>>>>>>>> user-agent 
>>>>>>>> client hints on Windows, Mac, Linux, Chrome OS and Android, we intend 
>>>>>>>> to 
>>>>>>>> proceed with shipping user-agent client hints on Android WebView. For 
>>>>>>>> overridden user-agent strings, we only populate user-agent client 
>>>>>>>> hints if 
>>>>>>>> the overridden user-agent contains the default user-agent. In this 
>>>>>>>> case, we 
>>>>>>>> will only generate low-entropy user-agent client hints If users also 
>>>>>>>> override the user-agent string through command-line.
>>>>>>>>
>>>>>>>> Blink component
>>>>>>>>
>>>>>>>> Blink>Network>ClientHints
>>>>>>>>
>>>>>>>> TAG review
>>>>>>>>
>>>>>>>> https://github.com/w3ctag/design-reviews/issues/320 
>>>>>>>>
>>>>>>>> TAG review status
>>>>>>>>
>>>>>>>> Closed.
>>>>>>>>
>>>>>>>> Risks
>>>>>>>> Interoperability and Compatibility
>>>>>>>>
>>>>>>

Re: [blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

['Victor Tan' via blink-dev]

can anyone take a look at this?   thanks.   :)

On Wednesday, August 16, 2023 at 1:40:38 PM UTC-4 Chris Harrelson wrote:

> LGTM1
>
> On Tue, Aug 15, 2023 at 2:19 PM Victor Tan  wrote:
>
>> Currently, we haven't confirmed the public plan for user-agent reduction 
>> on WeView. We won't do user-agent reduction before completing roll-out 
>> user-agent client hints. 
>>
>> Victor
>>
>> On Tue, Aug 15, 2023 at 5:13 PM Bhanu Vattikonda  
>> wrote:
>>
>>> Is there a corresponding User-Agent reduction plan for Android WebView?
>>>
>>> On Tuesday, August 15, 2023 at 12:30:17 PM UTC-7 vict...@chromium.org 
>>> wrote:
>>>
>>>> Contact emails
>>>>
>>>> vict...@chromium.org, mike...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/WICG/client-hints-infrastructure#readme
>>>>
>>>>
>>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>>
>>>> Specification
>>>>
>>>> https://wicg.github.io/ua-client-hints/
>>>>
>>>> Summary
>>>>
>>>> User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate and 
>>>> replace the User-Agent header to reduce the passive fingerprinting surface 
>>>> we expose via HTTP requests. As we previously rolled-out user-agent client 
>>>> hints on Windows, Mac, Linux, Chrome OS and Android, we intend to proceed 
>>>> with shipping user-agent client hints on Android WebView. For overridden 
>>>> user-agent strings, we only populate user-agent client hints if the 
>>>> overridden user-agent contains the default user-agent. In this case, we 
>>>> will only generate low-entropy user-agent client hints If users also 
>>>> override the user-agent string through command-line.
>>>>
>>>> Blink component
>>>>
>>>> Blink>Network>ClientHints
>>>>
>>>> TAG review
>>>>
>>>> https://github.com/w3ctag/design-reviews/issues/320 
>>>>
>>>> TAG review status
>>>>
>>>> Closed.
>>>>
>>>> Risks
>>>> Interoperability and Compatibility
>>>>
>>>> Introducing User-Agent client hints in itself won't affect any page 
>>>> since it's purely opt-in features. It helps us to improve the 
>>>> interoperability between Chrome and WebView. 
>>>>
>>>> Here is our proposed rollout plan in Chrome Stable channel 
>>>> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we 
>>>> discover concerning breakage or regressions via health metrics or bug 
>>>> reports we will pause the rollout:
>>>>
>>>>
>>>> Stage
>>>>
>>>> Duration
>>>>
>>>> Date
>>>>
>>>> Stable 1% (M116+)
>>>>
>>>> M116 stable release is shipping to 100% (a best guess)
>>>>
>>>> Aug 22, 2023
>>>>
>>>> Stable 10% (M116+)
>>>>
>>>> ~2 weeks after previous stage
>>>>
>>>> Sep 5, 2023
>>>>
>>>> TOT Default (M117)
>>>>
>>>> ~2 weeks after previous stage
>>>>
>>>> Sep 19, 2023
>>>>
>>>> Stable 100% (M116=>M117)
>>>>
>>>> ~ Same business day as previous stage
>>>>
>>>> Sep 19, 2023
>>>>
>>>> Gecko: Non-harmful on User-Agent client hints (
>>>> https://github.com/mozilla/standards-positions/issues/202).
>>>>
>>>> WebKit: No signals (
>>>> https://github.com/WebKit/standards-positions/issues/70).
>>>>
>>>> Web developers: Mixed signals (https://crbug.com/1430051 
>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1430051>). We 
>>>> know at least one site that uses user-agent client hints on Android 
>>>> WebView..
>>>>
>>>> Debuggability
>>>>
>>>> No special DevTools support needed. The UA Client Hints headers will be 
>>>> as debuggable as other request headers, through DevTools’ network tab.
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows, 
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>
>>>> Yes
>>>>
>>>&g

[blink-dev] Re: Intent to Implement and Ship: User-Agent Client Hints on Android WebView

[Victor Tan]

Currently, we haven't confirmed the public plan for user-agent reduction on
WeView. We won't do user-agent reduction before completing roll-out
user-agent client hints.

Victor

On Tue, Aug 15, 2023 at 5:13 PM Bhanu Vattikonda  wrote:

> Is there a corresponding User-Agent reduction plan for Android WebView?
>
> On Tuesday, August 15, 2023 at 12:30:17 PM UTC-7 vict...@chromium.org
> wrote:
>
>> Contact emails
>>
>> vict...@chromium.org, mike...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/client-hints-infrastructure#readme
>>
>>
>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>
>> Specification
>>
>> https://wicg.github.io/ua-client-hints/
>>
>> Summary
>>
>> User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate and
>> replace the User-Agent header to reduce the passive fingerprinting surface
>> we expose via HTTP requests. As we previously rolled-out user-agent client
>> hints on Windows, Mac, Linux, Chrome OS and Android, we intend to proceed
>> with shipping user-agent client hints on Android WebView. For overridden
>> user-agent strings, we only populate user-agent client hints if the
>> overridden user-agent contains the default user-agent. In this case, we
>> will only generate low-entropy user-agent client hints If users also
>> override the user-agent string through command-line.
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/320
>>
>> TAG review status
>>
>> Closed.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Introducing User-Agent client hints in itself won't affect any page since
>> it's purely opt-in features. It helps us to improve the interoperability
>> between Chrome and WebView.
>>
>> Here is our proposed rollout plan in Chrome Stable channel
>> (Canary/Dev/Beta has been enabled 50%), with the understanding that if we
>> discover concerning breakage or regressions via health metrics or bug
>> reports we will pause the rollout:
>>
>>
>> Stage
>>
>> Duration
>>
>> Date
>>
>> Stable 1% (M116+)
>>
>> M116 stable release is shipping to 100% (a best guess)
>>
>> Aug 22, 2023
>>
>> Stable 10% (M116+)
>>
>> ~2 weeks after previous stage
>>
>> Sep 5, 2023
>>
>> TOT Default (M117)
>>
>> ~2 weeks after previous stage
>>
>> Sep 19, 2023
>>
>> Stable 100% (M116=>M117)
>>
>> ~ Same business day as previous stage
>>
>> Sep 19, 2023
>>
>> Gecko: Non-harmful on User-Agent client hints (
>> https://github.com/mozilla/standards-positions/issues/202).
>>
>> WebKit: No signals (
>> https://github.com/WebKit/standards-positions/issues/70).
>>
>> Web developers: Mixed signals (https://crbug.com/1430051
>> ). We
>> know at least one site that uses user-agent client hints on Android
>> WebView..
>>
>> Debuggability
>>
>> No special DevTools support needed. The UA Client Hints headers will be
>> as debuggable as other request headers, through DevTools’ network tab.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> Notes: The existing flag UserAgentClientHint was already enabled for
>> other five platforms (Windows, Mac, Linux, Chrome OS and Android).
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> https://wpt.fyi/results/client-hints
>>
>> Flag name
>>
>> UserAgentClientHint
>>
>> Tracking bug
>>
>> https://crbug.com/1430051
>> 
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4261345
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5127746375647232
>>
>

-- 
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/CAJh4P7Hs_mYf2XdSU8M-vTsVuapefb%3D-AOMSh-dmObk8s75X_g%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: User-Agent Client Hints on Android WebView

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure#readme

https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

Specification

https://wicg.github.io/ua-client-hints/

Summary

User-agent client hints (a set of `Sec-CH-UA-*`) aim to deprecate and
replace the User-Agent header to reduce the passive fingerprinting surface
we expose via HTTP requests. As we previously rolled-out user-agent client
hints on Windows, Mac, Linux, Chrome OS and Android, we intend to proceed
with shipping user-agent client hints on Android WebView. For overridden
user-agent strings, we only populate user-agent client hints if the
overridden user-agent contains the default user-agent. In this case, we
will only generate low-entropy user-agent client hints If users also
override the user-agent string through command-line.

Blink component

Blink>Network>ClientHints

TAG review

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

TAG review status

Closed.

Risks
Interoperability and Compatibility

Introducing User-Agent client hints in itself won't affect any page since
it's purely opt-in features. It helps us to improve the interoperability
between Chrome and WebView.

Here is our proposed rollout plan in Chrome Stable channel (Canary/Dev/Beta
has been enabled 50%), with the understanding that if we discover
concerning breakage or regressions via health metrics or bug reports we
will pause the rollout:


Stage

Duration

Date

Stable 1% (M116+)

M116 stable release is shipping to 100% (a best guess)

Aug 22, 2023

Stable 10% (M116+)

~2 weeks after previous stage

Sep 5, 2023

TOT Default (M117)

~2 weeks after previous stage

Sep 19, 2023

Stable 100% (M116=>M117)

~ Same business day as previous stage

Sep 19, 2023

Gecko: Non-harmful on User-Agent client hints (
https://github.com/mozilla/standards-positions/issues/202).

WebKit: No signals (https://github.com/WebKit/standards-positions/issues/70
).

Web developers: Mixed signals (https://crbug.com/1430051
). We know
at least one site that uses user-agent client hints on Android WebView..

Debuggability

No special DevTools support needed. The UA Client Hints headers will be as
debuggable as other request headers, through DevTools’ network tab.

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

Yes

Notes: The existing flag UserAgentClientHint was already enabled for other
five platforms (Windows, Mac, Linux, Chrome OS and Android).

Is this feature fully tested by web-platform-tests

?

https://wpt.fyi/results/client-hints

Flag name

UserAgentClientHint

Tracking bug

https://crbug.com/1430051


Launch bug

https://launch.corp.google.com/launch/4261345

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5127746375647232

-- 
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/CAJh4P7HgdbnjwsYqgMiS%3D0Anp8y77ipvaQ1j8MWAL7YApoVnXA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 6  is ramping up to 50% of the stable release population 
today. 

Thanks.
Victor

On Tuesday, April 4, 2023 at 2:04:37 PM UTC-4 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 6  is currently ramping up to 10% of the stable release 
> population. 
>
> Thanks.
> Victor
>
> On Tuesday, March 21, 2023 at 6:41:47 PM UTC-4 Victor Tan wrote:
>
>> Hi blink-dev,
>> UA Reduction Phase 6  is currently ramping up to 5% of the stable release 
>> population. We will keep monitor the change during the 2 week experiment. 
>>
>> Thanks.
>> Victor
>>
>> On Monday, March 20, 2023 at 12:09:41 PM UTC-4 Mike Taylor wrote:
>>
>>> Hi all,
>>>
>>> Correcting my message on 3/3 to be consistent with the rollout timeline I 
>>> posted on Feb 16 
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/zVOEHwgyyu4/m/e70R8E_kBQAJ?utm_medium=email_source=footer>.
>>>  
>>> We intend to begin the ramp up to 5% of stable traffic tomorrow.
>>> [done] Stable 1%: Feb 21, 2023
>>> [tomorrow] Stable 5%: Mar 21, 2023 (~4 weeks after previous)
>>> Stable 10%: Apr 4, 2023 (~2 weeks after previous)
>>> Stable 50%: Apr 18, 2023 (~2 weeks after previous)
>>> ToT Default: May 2, 2023 (~2 weeks after previous)
>>> Stable 100%: May 2, 2023
>>>
>>> thanks,
>>> Mike
>>>
>>> On 3/3/23 1:28 PM, Mike Taylor wrote:
>>>
>>>
>>>- 
>>>
>>>[done] February 21: Phase 6 roll-out starts one week after the 
>>>launch of Chrome 110 Stable with 1% traffic. 
>>>- 
>>>
>>>March 21: Roll-out increases to 10% traffic. 
>>>- 
>>>
>>>April 4: Roll-out increases to 50% traffic.
>>>- 
>>>
>>>April 18: Roll-out reaches full Stable population with 100% traffic.
>>>
>>>

-- 
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/ac262019-4c02-48bb-b8e0-e583d7314ba5n%40chromium.org.

Re: [blink-dev] Re: Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 6  is currently ramping up to 10% of the stable release 
population. 

Thanks.
Victor

On Tuesday, March 21, 2023 at 6:41:47 PM UTC-4 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 6  is currently ramping up to 5% of the stable release 
> population. We will keep monitor the change during the 2 week experiment. 
>
> Thanks.
> Victor
>
> On Monday, March 20, 2023 at 12:09:41 PM UTC-4 Mike Taylor wrote:
>
>> Hi all,
>>
>> Correcting my message on 3/3 to be consistent with the rollout timeline I 
>> posted on Feb 16 
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/zVOEHwgyyu4/m/e70R8E_kBQAJ?utm_medium=email_source=footer>.
>>  
>> We intend to begin the ramp up to 5% of stable traffic tomorrow.
>> [done] Stable 1%: Feb 21, 2023
>> [tomorrow] Stable 5%: Mar 21, 2023 (~4 weeks after previous)
>> Stable 10%: Apr 4, 2023 (~2 weeks after previous)
>> Stable 50%: Apr 18, 2023 (~2 weeks after previous)
>> ToT Default: May 2, 2023 (~2 weeks after previous)
>> Stable 100%: May 2, 2023
>>
>> thanks,
>> Mike
>>
>> On 3/3/23 1:28 PM, Mike Taylor wrote:
>>
>>
>>- 
>>
>>[done] February 21: Phase 6 roll-out starts one week after the launch 
>>of Chrome 110 Stable with 1% traffic. 
>>- 
>>
>>March 21: Roll-out increases to 10% traffic. 
>>- 
>>
>>April 4: Roll-out increases to 50% traffic.
>>- 
>>
>>April 18: Roll-out reaches full Stable population with 100% traffic.
>>
>>

-- 
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/fbd7f70c-06c4-4036-a6c3-65693f1d31f1n%40chromium.org.

Re: [blink-dev] Re: Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 6  is currently ramping up to 5% of the stable release 
population. We will keep monitor the change during the 2 week experiment. 

Thanks.
Victor

On Monday, March 20, 2023 at 12:09:41 PM UTC-4 Mike Taylor wrote:

> Hi all,
>
> Correcting my message on 3/3 to be consistent with the rollout timeline I 
> posted on Feb 16 
> .
>  
> We intend to begin the ramp up to 5% of stable traffic tomorrow.
> [done] Stable 1%: Feb 21, 2023
> [tomorrow] Stable 5%: Mar 21, 2023 (~4 weeks after previous)
> Stable 10%: Apr 4, 2023 (~2 weeks after previous)
> Stable 50%: Apr 18, 2023 (~2 weeks after previous)
> ToT Default: May 2, 2023 (~2 weeks after previous)
> Stable 100%: May 2, 2023
>
> thanks,
> Mike
>
> On 3/3/23 1:28 PM, Mike Taylor wrote:
>
>
>- 
>
>[done] February 21: Phase 6 roll-out starts one week after the launch 
>of Chrome 110 Stable with 1% traffic. 
>- 
>
>March 21: Roll-out increases to 10% traffic. 
>- 
>
>April 4: Roll-out increases to 50% traffic.
>- 
>
>April 18: Roll-out reaches full Stable population with 100% traffic.
>
>

-- 
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/6d296143-38a7-45ba-b8c9-c74087209df0n%40chromium.org.

Re: [blink-dev] Re: Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi blink-dev,

Phase 6 of UA Reduction is currently ramping up to 1% of the stable release 
population on Android platform. 
No changes will occur between now and March 21st, 2023, pending site 
compatibility feedback. Thanks.

Best,
Victor

On Thursday, February 16, 2023 at 12:31:56 PM UTC-5 Mike Taylor wrote:

> Hi all,
>
> Due to an unrelated release blocker bug, our best-guess prediction of Feb 
> 14th to start the 1% roll-out was incorrect (M110 on Android is currently 
> at 50% ). I'm 
> hopeful we'll be at 100% by next Tuesday, so at the risk of being wrong 
> again (if the timeline slips by a day or two extra, we will not shorten the 
> rollout, but adjust the schedule accordingly), here's an updated roll-out 
> schedule:
>
> Stable 1%: Feb 21, 2023
> Stable 5%: Mar 21, 2023 (~4 weeks after previous)
> Stable 10%: Apr 4, 2023 (~2 weeks after previous)
> Stable 50%: Apr 18, 2023 (~2 weeks after previous)
> ToT Default: May 2, 2023 (~2 weeks after previous)
> Stable 100%: May 2, 2023
>
> As always, we'll monitor for breakage and stability, and may pause or 
> back-out to investigate concerning feedback or data.
>
> thanks,
> Mike 
> On Thursday, February 9, 2023 at 5:05:03 PM UTC-5 James Rosewell wrote:
>
>> The issue is that automated testing of the web experience for Android 
>> uses this feature in automated test environments which can not be Android. 
>> As it doesn't work it is no longer possible to automatically test changes 
>> that could easily be tested with a variety of UAS values. Thus the only 
>> option is to take longer to test using human testers. This increases cost 
>> and delays to implementors that would be avoided if the related tools works 
>> or UAS were not altered further.
>>
>> On Thursday, 9 February 2023 at 19:52:14 UTC Mike Taylor wrote:
>>
>>> Hi James,
>>>
>>> Thanks for letting us know that this issue has not been fixed yet. I've 
>>> asked someone on my team to take over the task. Phase 6 will only affect 
>>> the Android User-Agent string and headless Chrome is not supported on 
>>> mobile.
>>>
>>> On 2/1/23 9:30 AM, 'James Rosewell' via blink-dev wrote:
>>>
>>> Resolving the issues associated with automated testing prior to 
>>> commencement of deployment and 14th February should be dependency. See this 
>>> link. 
>>>
>>> 1212793 - Client hints not sent in headless chrome - chromium 
>>> 
>>>
>>> The lack of functional parity in the test environment causes disruption 
>>> and cost to the rest of the eco-system.
>>>
>>> On Tuesday, 17 January 2023 at 16:02:45 UTC vict...@chromium.org wrote:
>>>
 Contact emails 

 vict...@chromium.org, mike...@chromium.org 

 Explainer 


 https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

 Specification 

 https://www.chromium.org/updates/ua-reduction is the closest thing 
 that specifies Chrome’s UA Reduction plans today. As these changes land in 
 Chromium and ship to 100% stable, the Compat Standard 
  will be updated in the UA String 
 section , 
 like we did for the Phase 4 and plan to do for Phase 5 changes.

 Summary 

 As previously detailed on the Chromium Blog 
 ,
  
 we intend to proceed with Phase 6 of the User-Agent Reduction plan 
 .
  
 In Phase 6, we change the deviceModel token to “K” and change the 
 androidVersion token to a static “10” string in Android User-Agent 
 string. The navigator.platform will be a “Linux armv81” constant on 
 the Android platform.

 Blink component 

 Blink>Network>ClientHints

 TAG review 

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

 TAG review status 

 Closed satisfied with concerns.

 Risks 
 Interoperability and Compatibility 

 Any time you modify the User-Agent string there is a risk of breaking 
 existing patterns, like some content somewhere depending on the previous 
 format.

 We do not expect interoperability risks, as each browser sends its own 
 User-Agent string format. However there is a risk that - on the Android 
 platform - content may rely  on User-Agents to parse deviceModel and 
 androidVersion information. To mitigate the risk of this change, we intend 
 to slowly roll out the format via Finch on the Android platform and 
 observe 
 health metrics and bug reports. See timeline below on our slow roll out 
 plan. This gives us the option to roll this back for the Android platform 
 if major issues arise.

 Displaying a 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 100% of the stable release 
population. 

Thanks.
Victor

On Monday, January 23, 2023 at 4:13:15 PM UTC-5 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 5  is currently ramping up to 50% of the stable release 
> population. 
>
> Thanks.
> Victor
>
> On Monday, January 9, 2023 at 2:31:08 PM UTC-5 Victor Tan wrote:
>
>> Hi blink-dev,
>> UA Reduction Phase 5  is currently ramping up to 10% of the stable 
>> release population. We will monitor the change has any impacts. 
>>
>> Thanks.
>> Victor
>>
>> On Wednesday, December 7, 2022 at 4:56:18 PM UTC-5 Victor Tan wrote:
>>
>>> Hi blink-dev,
>>> UA Reduction Phase 5  is currently ramping up to 5% of the stable 
>>> release population. We will monitor the change has any impacts. 
>>>
>>> Thanks.
>>> Victor
>>>
>>> On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:
>>>
>>>> Thanks Ziling. We're unlikely to make the change just ahead of the 
>>>> weekend, but will ping this thread early next week once the move to 5% is 
>>>> submitted.
>>>>
>>>> On 12/1/22 1:36 PM, Ziling Zhao wrote:
>>>>
>>>> Hey Mike, 
>>>>
>>>> I think moving to 5% early sounds good for YouTube. The 1% doesn't seem 
>>>> to be giving us consistent data and we would want to get more traffic as 
>>>> soon as possible. If we were to move forward, would this re-roll the 
>>>> experiment or just expand? How soon would we be able to roll this out?
>>>>
>>>> Thanks!
>>>>
>>>> On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
>>>> wrote:
>>>>
>>>>> Hi Ziling,
>>>>>
>>>>> (forgive the delay in replying, I took some time off and managed to 
>>>>> not check my email)
>>>>>
>>>>> Based on the other feedback we've received both internally and 
>>>>> externally (and the lack of any negative impact thus far), I don't think 
>>>>> we 
>>>>> want to add an additional month to our rollout schedule before hitting 
>>>>> 100%. Another possible option would be to move to 5% sooner, at least 1 
>>>>> month ahead of Jan 9th, ideally with enough time to observe metrics ahead 
>>>>> of the Finch freeze on Dec 16th, in case something scary happens that 
>>>>> would 
>>>>> warrant a rollback.
>>>>>
>>>>> Would that work for YouTube?
>>>>>
>>>>> thanks,
>>>>> Mike
>>>>>
>>>>> On 11/17/22 7:12 PM, Ziling Zhao wrote:
>>>>>
>>>>> Hello, 
>>>>>
>>>>> YouTube -- and various other Google properties -- have been analyzing 
>>>>> the results of this 1% experiment. We're concerned that the 1% may not 
>>>>> provide enough data especially due to the amount of slicing (modern 
>>>>> chrome, 
>>>>> non windows vs. legacy windows, etc.). On YT, we are seeing significant 
>>>>> metrics impact on, and given the holidays, there's a short amount of time 
>>>>> available for us to iterate and debug issues before we rollout to 10%.
>>>>>
>>>>> We'd like to propose:
>>>>>
>>>>>- An intermediate state of 5% on January 9th rather than jumping 
>>>>>directly to 10%. 
>>>>>- The 5% should hold for at least a month, enough for us to do a 
>>>>>few rounds of experimental analysis and debugging. 
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 
>>>>> mike...@chromium.org wrote:
>>>>>
>>>>>> Howdy blink-dev,
>>>>>>
>>>>>> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
>>>>>> release population. No changes will occur between now and January 9th, 
>>>>>> pending site compatibility feedback.
>>>>>>
>>>>>> thanks,
>>>>>> Mike
>>>>>>
>>>>>> On 9/7/22 12:16 PM, Victor Tan wrote:
>>>>>>
>>>>>> Thanks all. I just realized there are some date typos for the roll 
>>>>>> out plan. Update as follows:  
>>>>>>
&g

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 50% of the stable release 
population. 

Thanks.
Victor

On Monday, January 9, 2023 at 2:31:08 PM UTC-5 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 5  is currently ramping up to 10% of the stable release 
> population. We will monitor the change has any impacts. 
>
> Thanks.
> Victor
>
> On Wednesday, December 7, 2022 at 4:56:18 PM UTC-5 Victor Tan wrote:
>
>> Hi blink-dev,
>> UA Reduction Phase 5  is currently ramping up to 5% of the stable release 
>> population. We will monitor the change has any impacts. 
>>
>> Thanks.
>> Victor
>>
>> On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:
>>
>>> Thanks Ziling. We're unlikely to make the change just ahead of the 
>>> weekend, but will ping this thread early next week once the move to 5% is 
>>> submitted.
>>>
>>> On 12/1/22 1:36 PM, Ziling Zhao wrote:
>>>
>>> Hey Mike, 
>>>
>>> I think moving to 5% early sounds good for YouTube. The 1% doesn't seem 
>>> to be giving us consistent data and we would want to get more traffic as 
>>> soon as possible. If we were to move forward, would this re-roll the 
>>> experiment or just expand? How soon would we be able to roll this out?
>>>
>>> Thanks!
>>>
>>> On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
>>> wrote:
>>>
>>>> Hi Ziling,
>>>>
>>>> (forgive the delay in replying, I took some time off and managed to not 
>>>> check my email)
>>>>
>>>> Based on the other feedback we've received both internally and 
>>>> externally (and the lack of any negative impact thus far), I don't think 
>>>> we 
>>>> want to add an additional month to our rollout schedule before hitting 
>>>> 100%. Another possible option would be to move to 5% sooner, at least 1 
>>>> month ahead of Jan 9th, ideally with enough time to observe metrics ahead 
>>>> of the Finch freeze on Dec 16th, in case something scary happens that 
>>>> would 
>>>> warrant a rollback.
>>>>
>>>> Would that work for YouTube?
>>>>
>>>> thanks,
>>>> Mike
>>>>
>>>> On 11/17/22 7:12 PM, Ziling Zhao wrote:
>>>>
>>>> Hello, 
>>>>
>>>> YouTube -- and various other Google properties -- have been analyzing 
>>>> the results of this 1% experiment. We're concerned that the 1% may not 
>>>> provide enough data especially due to the amount of slicing (modern 
>>>> chrome, 
>>>> non windows vs. legacy windows, etc.). On YT, we are seeing significant 
>>>> metrics impact on, and given the holidays, there's a short amount of time 
>>>> available for us to iterate and debug issues before we rollout to 10%.
>>>>
>>>> We'd like to propose:
>>>>
>>>>- An intermediate state of 5% on January 9th rather than jumping 
>>>>directly to 10%. 
>>>>- The 5% should hold for at least a month, enough for us to do a 
>>>>few rounds of experimental analysis and debugging. 
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 mike...@chromium.org 
>>>> wrote:
>>>>
>>>>> Howdy blink-dev,
>>>>>
>>>>> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
>>>>> release population. No changes will occur between now and January 9th, 
>>>>> pending site compatibility feedback.
>>>>>
>>>>> thanks,
>>>>> Mike
>>>>>
>>>>> On 9/7/22 12:16 PM, Victor Tan wrote:
>>>>>
>>>>> Thanks all. I just realized there are some date typos for the roll out 
>>>>> plan. Update as follows:  
>>>>>
>>>>> Stage
>>>>>
>>>>> Time
>>>>>
>>>>> Date
>>>>>
>>>>> Stable 1% (M107+)
>>>>>
>>>>> Canary/Dev/Beta 100%
>>>>>
>>>>> M107 stable release is shipping to 100% (a best guess)
>>>>>
>>>>> Nov 1, 2022
>>>>>
>>>>> Stable 10% (M107/M108/M109)
>>>>>
>>>>> ~10 weeks after previous stage
>>>>>
>>>>> Jan 9, *2023*
>>>>>
>

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi Torne,
Thanks for the clarification. Sorry, I misread that we are going to ship
the UA-CH in android webview.
I agree we need to meet to discuss the plan for UA-CH and UA reduction on
Webview sometime in the near future.

Best,
Victor

On Wed, Jan 18, 2023 at 12:49 PM Torne (Richard Coles) 
wrote:

> On Wed, 18 Jan 2023 at 12:29, Victor Tan  wrote:
>
>> Hi Torne,
>> Thanks for your information. We understand your concern.
>> UA-CH in WebView will be shipping in Chrome M110
>> <https://chromestatus.com/feature/4936247663919104>.
>>
>
> UA-CH is entirely disabled in WebView at present and shipping CH
> persistence as covered in that bug is *not* supposed to be enabling it,
> because we haven't yet done any of the design work to figure out what the
> APIs exposed to apps for controlling it should be, how it should interact
> with custom UA strings, whether there should be a way to distinguish
> WebView from Chrome in the UA-CH values and whether that needs to be
> standardized, etc.
>
> The referenced bug *should* just be about making all the non-UA client
> hints work properly in WebView (currently they're mostly useless as
> Accept-CH isn't being persisted across requests).
>
> UA reduction in WebView is also in our future plan list, we will see how
>> the UA-CH works in Webview.
>>
>
> We need a plan for how to ship UA-CH for WebView and what it should
> include first :)
>
>
>> For now, I don't think what we did in this phase on Android will impact
>> Webview much since we already did the UA reduction phase 4 on
>> Android platform.
>> For the future plan, we will work out a plan (if UA-CH works as expected)
>> to do the UA reduction in Webview to match what we did in Chrome.
>> Also, we are glad to discuss with Webview for all other possibilities and
>> impacts.  Thanks.
>>
>
> Understood, but if we ultimately want to change WebView's UA in a way that
> doesn't pass the current CDD/CTS requirements then the work to change those
> requirements needs to happen at *least* an entire Android release ahead of
> time, and ideally would have been done several years ago if we want it to
> have the most impact :(
>
>
>>
>> Best,
>> Victor
>>
>> On Wed, Jan 18, 2023 at 12:20 PM Rick Byers  wrote:
>>
>>> Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
>>> having a unified plan for WebView. I assume the format (eg. not omitting
>>> the device model completely) is being driven by web compat concerns which
>>> would matter for WebView as well, right?
>>>
>>
> It's not really directly about web compat concerns. See
> https://chromium.googlesource.com/chromium/src/+/HEAD/android_webview/docs/web-platform-compatibility.md#Android_s-Compatibility-Test-Suite-tests-some-WebView-behaviours
> for more on this, but briefly: CTS/CDD are about *application*
> compatibility - they are requirements the Android OS must satisfy to be
> considered compatible with existing Android applications. Anything that's
> tested by CTS is something that app developers are expected to be able to
> rely on.
>
> It's likely that *most* consideration of WebView's UA string is happening
> on the web side (by JS or by server side logic), but the UA string is also
> exposed directly to apps via Java APIs and so the actual code of the app
> might *also* be parsing this information (and the Java API currently does
> *not* provide any way to access client hints, other than loading a page and
> injecting JS into it to access the JS APIs). Web content that's designed
> only to be loaded in a specific WebView application might potentially rely
> much more heavily on the specific format of the UA string than content
> that's intended to be used by multiple browsers, and may not ever be loaded
> in Chrome or ever show up in web crawler data.
>
>
>> Do we have any data on the web compatibility of removing the model string
>>> entirely?
>>>
>>
> The model string is currently omitted automatically on prerelease versions
> of the Android OS as a basic precaution to not leak model names of
> unreleased devices. This doesn't get a lot of production usage, but we do
> regularly get bugs filed against us every single android release by device
> vendors or other developers complaining that the useragent is "wrong" (even
> though omitting the model entirely has been explicitly allowed by CTS for
> quite a few releases now). We've also previously discussed removing the
> model with various parties who had very strong objections on the grounds
> that they use it for targeting downloads/support info/etc to particular
> devices; if this information 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi Torne,
Thanks for your information. We understand your concern.
UA-CH in WebView will be shipping in Chrome M110
<https://chromestatus.com/feature/4936247663919104>. UA reduction in
WebView is also in our future plan list, we will see how the UA-CH works in
Webview.
For now, I don't think what we did in this phase on Android will impact
Webview much since we already did the UA reduction phase 4 on
Android platform.
For the future plan, we will work out a plan (if UA-CH works as expected)
to do the UA reduction in Webview to match what we did in Chrome.
Also, we are glad to discuss with Webview for all other possibilities and
impacts.  Thanks.

Best,
Victor

On Wed, Jan 18, 2023 at 12:20 PM Rick Byers  wrote:

> Thanks Torne. I don't think it necessarily blocks this intent, but +1 to
> having a unified plan for WebView. I assume the format (eg. not omitting
> the device model completely) is being driven by web compat concerns which
> would matter for WebView as well, right? Do we have any data on the web
> compatibility of removing the model string entirely? My assumption is that
> it would be too breaking, but that's just an assumption. Victor, can you or
> your team meet with Torne and figure out whether a long-term plan for
> WebView would impact what we do for Chrome now?
>
> Thanks,
>Rick
>
> On Wed, Jan 18, 2023 at 12:06 PM Torne (Richard Coles) 
> wrote:
>
>> I have some concerns that we won't be able to use this format for Android
>> WebView. I realise we're not currently shipping UA reduction for WebView,
>> but AFAIK we are still hoping to do so at some point in the future.
>>
>> WebView's UA format is mandated by Android's CTS compatibility tests. I
>> relaxed the test criteria some time ago to allow the device model and
>> Android build ID to be omitted (though WebView currently still includes
>> this information), but the test currently requires these fields to either
>> be entirely absent, or to exactly match the underlying OS properties. It
>> also does not allow the less-granular OS version to be omitted or spoofed.
>>
>> It'd be good to have a long term plan for what we're going to do with the
>> UA and with UA-CH in WebView that matches Chrome as closely as possible.
>>
>> On Tue, 17 Jan 2023 at 11:02, Victor Tan  wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>
>>> Specification
>>>
>>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>>> specifies Chrome’s UA Reduction plans today. As these changes land in
>>> Chromium and ship to 100% stable, the Compat Standard
>>> <https://compat.spec.whatwg.org/> will be updated in the UA String
>>> section <https://compat.spec.whatwg.org/#ua-string-pattern-chrome>,
>>> like we did for the Phase 4 and plan to do for Phase 5 changes.
>>>
>>> Summary
>>>
>>> As previously detailed on the Chromium Blog
>>> <https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html>,
>>> we intend to proceed with Phase 6 of the User-Agent Reduction plan
>>> <https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-6>.
>>> In Phase 6, we change the deviceModel token to “K” and change the
>>> androidVersion token to a static “10” string in Android User-Agent
>>> string. The navigator.platform will be a “Linux armv81” constant on the
>>> Android platform.
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/640
>>>
>>> TAG review status
>>>
>>> Closed satisfied with concerns.
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Any time you modify the User-Agent string there is a risk of breaking
>>> existing patterns, like some content somewhere depending on the previous
>>> format.
>>>
>>> We do not expect interoperability risks, as each browser sends its own
>>> User-Agent string format. However there is a risk that - on the Android
>>> platform - content may rely  on User-Agents to parse deviceModel and
>>> androidVersion information. To mitigate the risk of this change, we intend
>>> to slowly roll out the format via Finch on the Android platform and observe
>>> health metrics and bug reports. See timeline belo

[blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org

Explainer

https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

Specification

https://www.chromium.org/updates/ua-reduction is the closest thing that
specifies Chrome’s UA Reduction plans today. As these changes land in
Chromium and ship to 100% stable, the Compat Standard
 will be updated in the UA String section
, like we did for
the Phase 4 and plan to do for Phase 5 changes.

Summary

As previously detailed on the Chromium Blog
,
we intend to proceed with Phase 6 of the User-Agent Reduction plan
.
In Phase 6, we change the deviceModel token to “K” and change the
androidVersion token to a static “10” string in Android User-Agent string.
The navigator.platform will be a “Linux armv81” constant on the Android
platform.

Blink component

Blink>Network>ClientHints

TAG review

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

TAG review status

Closed satisfied with concerns.

Risks
Interoperability and Compatibility

Any time you modify the User-Agent string there is a risk of breaking
existing patterns, like some content somewhere depending on the previous
format.

We do not expect interoperability risks, as each browser sends its own
User-Agent string format. However there is a risk that - on the Android
platform - content may rely  on User-Agents to parse deviceModel and
androidVersion information. To mitigate the risk of this change, we intend
to slowly roll out the format via Finch on the Android platform and observe
health metrics and bug reports. See timeline below on our slow roll out
plan. This gives us the option to roll this back for the Android platform
if major issues arise.

Displaying a static androidVersion and a deviceModel token for Android
clients will not create a problem syntactically. But the web can get pretty
weird in ways we don't anticipate. For example, sites can rely on the
deviceModel in the User-Agent string to determine whether the device is a
mobile, laptop or desktop. Currently, we change the deviceModel to a static
string, sites need to use client hints as the alternative to determine the
right behavior.  Hence the slow roll-out and incremental path towards
User-Agent Reduction.

Here is our proposed rollout plan in Chrome Stable channel (Canary/Dev/Beta
has been enabled 50%), with the understanding that if we discover
concerning breakage or regressions via health metrics or bug reports we
will pause the rollout or roll back the feature entirely (and update this
thread if so):

Stage

Duration

Date

Stable 1% (M110+)

M110 stable release is shipping to 100% (a best guess)

Feb 14, 2023

Stable 10% (M110/M111)

~4 weeks after previous stage

Mar 14, 2023

Stable 50%

(M110/M111)

~2 weeks

Mar 28, 2023

TOT Default (M114)

~2 weeks after previous stage

Apr 11, 2023

Stable 100% (M110=>M114)

~ Same business day as previous stage

Apr 11, 2023

Web stakeholders can still test with the user agent reduction deprecation
origin trial

until M113 (late May) if they need more time to adapt to the coming
changes. The UA-RD OT allows web stakeholders to request the legacy
user-agent string values (i.e. non-reduced values).

Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
string already.

WebKit: Shipped/Shipping. Safari has already frozen everything in their
desktop UA string except for Safari and WebKit versions. Also, UA reduction
phase 6 will only apply to the Android platform.

Web developers: Mixed signals. Various channels have different reactions.
It’s similar for the UA reduction phase 4 and phase 5.


Debuggability

No special DevTools support needed.

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

No (Only for Android)

Is this feature fully tested by web-platform-tests

?

No, because User-Agents vary across browsers.

Flag name

#reduce-user-agent-android-version-device-model

Notes: The existing flag #reduce-user-agent will provide the same format
User-Agent string on the Android platform since this is the last phase for
User-Agent reduction.

Tracking bug

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

Launch bug

https://launch.corp.google.com/launch/4225291

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177681979637760

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

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 10% of the stable release 
population. We will monitor the change has any impacts. 

Thanks.
Victor

On Wednesday, December 7, 2022 at 4:56:18 PM UTC-5 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 5  is currently ramping up to 5% of the stable release 
> population. We will monitor the change has any impacts. 
>
> Thanks.
> Victor
>
> On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:
>
>> Thanks Ziling. We're unlikely to make the change just ahead of the 
>> weekend, but will ping this thread early next week once the move to 5% is 
>> submitted.
>>
>> On 12/1/22 1:36 PM, Ziling Zhao wrote:
>>
>> Hey Mike, 
>>
>> I think moving to 5% early sounds good for YouTube. The 1% doesn't seem 
>> to be giving us consistent data and we would want to get more traffic as 
>> soon as possible. If we were to move forward, would this re-roll the 
>> experiment or just expand? How soon would we be able to roll this out?
>>
>> Thanks!
>>
>> On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
>> wrote:
>>
>>> Hi Ziling,
>>>
>>> (forgive the delay in replying, I took some time off and managed to not 
>>> check my email)
>>>
>>> Based on the other feedback we've received both internally and 
>>> externally (and the lack of any negative impact thus far), I don't think we 
>>> want to add an additional month to our rollout schedule before hitting 
>>> 100%. Another possible option would be to move to 5% sooner, at least 1 
>>> month ahead of Jan 9th, ideally with enough time to observe metrics ahead 
>>> of the Finch freeze on Dec 16th, in case something scary happens that would 
>>> warrant a rollback.
>>>
>>> Would that work for YouTube?
>>>
>>> thanks,
>>> Mike
>>>
>>> On 11/17/22 7:12 PM, Ziling Zhao wrote:
>>>
>>> Hello, 
>>>
>>> YouTube -- and various other Google properties -- have been analyzing 
>>> the results of this 1% experiment. We're concerned that the 1% may not 
>>> provide enough data especially due to the amount of slicing (modern chrome, 
>>> non windows vs. legacy windows, etc.). On YT, we are seeing significant 
>>> metrics impact on, and given the holidays, there's a short amount of time 
>>> available for us to iterate and debug issues before we rollout to 10%.
>>>
>>> We'd like to propose:
>>>
>>>- An intermediate state of 5% on January 9th rather than jumping 
>>>directly to 10%. 
>>>- The 5% should hold for at least a month, enough for us to do a few 
>>>    rounds of experimental analysis and debugging. 
>>>
>>>
>>> Thanks.
>>>
>>> On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 mike...@chromium.org 
>>> wrote:
>>>
>>>> Howdy blink-dev,
>>>>
>>>> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
>>>> release population. No changes will occur between now and January 9th, 
>>>> pending site compatibility feedback.
>>>>
>>>> thanks,
>>>> Mike
>>>>
>>>> On 9/7/22 12:16 PM, Victor Tan wrote:
>>>>
>>>> Thanks all. I just realized there are some date typos for the roll out 
>>>> plan. Update as follows:  
>>>>
>>>> Stage
>>>>
>>>> Time
>>>>
>>>> Date
>>>>
>>>> Stable 1% (M107+)
>>>>
>>>> Canary/Dev/Beta 100%
>>>>
>>>> M107 stable release is shipping to 100% (a best guess)
>>>>
>>>> Nov 1, 2022
>>>>
>>>> Stable 10% (M107/M108/M109)
>>>>
>>>> ~10 weeks after previous stage
>>>>
>>>> Jan 9, *2023*
>>>>
>>>> Stable 50%
>>>>
>>>> (M107/M108/M109)
>>>>
>>>> ~2 weeks
>>>>
>>>> Jan 23, *2023* 
>>>>
>>>> TOT Default (M111)
>>>>
>>>> ~2 weeks after previous stage
>>>>
>>>> Feb 7, *2023*
>>>>
>>>> Stable 100% (M107=>M111)
>>>>
>>>> ~ Same business day as previous stage
>>>>
>>>> Feb 7, *2023*
>>>>
>>>> Bests,
>>>> Victor
>>>>
>>>> On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  
>>>> wrote:
>>

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 5% of the stable release 
population. We will monitor the change has any impacts. 

Thanks.
Victor

On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:

> Thanks Ziling. We're unlikely to make the change just ahead of the 
> weekend, but will ping this thread early next week once the move to 5% is 
> submitted.
>
> On 12/1/22 1:36 PM, Ziling Zhao wrote:
>
> Hey Mike, 
>
> I think moving to 5% early sounds good for YouTube. The 1% doesn't seem to 
> be giving us consistent data and we would want to get more traffic as soon 
> as possible. If we were to move forward, would this re-roll the experiment 
> or just expand? How soon would we be able to roll this out?
>
> Thanks!
>
> On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
> wrote:
>
>> Hi Ziling,
>>
>> (forgive the delay in replying, I took some time off and managed to not 
>> check my email)
>>
>> Based on the other feedback we've received both internally and externally 
>> (and the lack of any negative impact thus far), I don't think we want to 
>> add an additional month to our rollout schedule before hitting 100%. 
>> Another possible option would be to move to 5% sooner, at least 1 month 
>> ahead of Jan 9th, ideally with enough time to observe metrics ahead of the 
>> Finch freeze on Dec 16th, in case something scary happens that would 
>> warrant a rollback.
>>
>> Would that work for YouTube?
>>
>> thanks,
>> Mike
>>
>> On 11/17/22 7:12 PM, Ziling Zhao wrote:
>>
>> Hello, 
>>
>> YouTube -- and various other Google properties -- have been analyzing the 
>> results of this 1% experiment. We're concerned that the 1% may not provide 
>> enough data especially due to the amount of slicing (modern chrome, non 
>> windows vs. legacy windows, etc.). On YT, we are seeing significant metrics 
>> impact on, and given the holidays, there's a short amount of time available 
>> for us to iterate and debug issues before we rollout to 10%.
>>
>> We'd like to propose:
>>
>>- An intermediate state of 5% on January 9th rather than jumping 
>>directly to 10%. 
>>- The 5% should hold for at least a month, enough for us to do a few 
>>rounds of experimental analysis and debugging. 
>>
>>
>> Thanks.
>>
>> On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 mike...@chromium.org 
>> wrote:
>>
>>> Howdy blink-dev,
>>>
>>> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
>>> release population. No changes will occur between now and January 9th, 
>>> pending site compatibility feedback.
>>>
>>> thanks,
>>> Mike
>>>
>>> On 9/7/22 12:16 PM, Victor Tan wrote:
>>>
>>> Thanks all. I just realized there are some date typos for the roll out 
>>> plan. Update as follows:  
>>>
>>> Stage
>>>
>>> Time
>>>
>>> Date
>>>
>>> Stable 1% (M107+)
>>>
>>> Canary/Dev/Beta 100%
>>>
>>> M107 stable release is shipping to 100% (a best guess)
>>>
>>> Nov 1, 2022
>>>
>>> Stable 10% (M107/M108/M109)
>>>
>>> ~10 weeks after previous stage
>>>
>>> Jan 9, *2023*
>>>
>>> Stable 50%
>>>
>>> (M107/M108/M109)
>>>
>>> ~2 weeks
>>>
>>> Jan 23, *2023* 
>>>
>>> TOT Default (M111)
>>>
>>> ~2 weeks after previous stage
>>>
>>> Feb 7, *2023*
>>>
>>> Stable 100% (M107=>M111)
>>>
>>> ~ Same business day as previous stage
>>>
>>> Feb 7, *2023*
>>>
>>> Bests,
>>> Victor
>>>
>>> On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  wrote:
>>>
>>>> LGTM3
>>>>
>>>> On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  
>>>> wrote:
>>>>
>>>>> LGTM2
>>>>>
>>>>> /Daniel
>>>>> On 2022-09-07 17:50, Chris Harrelson wrote:
>>>>>
>>>>> LGTM1. If any issues come up during this rollout that affect the plan, 
>>>>> please bring them back to this thread for our consideration.
>>>>>
>>>>> On Thu, Sep 1, 2022 at 11:29 AM Victor Tan  
>>>>> wrote:
>>>>>
>>>>>> Contact emails 
>>>>>>
>>>>>> mike...@chromium.org, vict...@chromium.org
>>&

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

A blog post just went out for this Origin Trial: 
https://developer.chrome.com/blog/origin-trial-for-accept-language-reduction/


On Tuesday, November 1, 2022 at 5:19:08 PM UTC-4 Victor Tan wrote:

> Hi Jeffrey,
> Thanks for your information. I updated the Chrome Status entry to 
> correctly represent current status. 
> I will work on spec and migrate the explainer to CG if needed. 
>
> Bests,
> Victor
>
> On Tue, Nov 1, 2022 at 2:26 PM Jeffrey Yasskin  
> wrote:
>
>> I see that your Chrome Status entry 
>> <https://chromestatus.com/feature/5188040623390720#details> says 
>> "Specification being incubated in a Community Group", but your explainer is 
>> not hosted by a CG, and the specification you cite is 1) in a WG and 2) not 
>> the specification you'll need to write for this to be a web feature. Could 
>> you work on migrating this to a CG? And now that you've started an origin 
>> trial, it's also time to start working on your web-side specification, 
>> which will probably eventually merge into Fetch 
>> <https://fetch.spec.whatwg.org/#concept-fetch>. Let me or your spec 
>> mentor <https://sites.google.com/a/chromium.org/dev/blink/spec-mentors> 
>> know if you need help with that.
>>
>> Thanks,
>> Jeffrey
>>
>> On Thu, Oct 27, 2022 at 10:57 AM Victor Tan  
>> wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org 
>>>
>>> Explainer
>>>
>>> https://github.com/Tanych/accept-language
>>>
>>> Specification
>>>
>>> Variants header: 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>
>>> Summary
>>>
>>> We want to reduce the amount of information the Accept-Language header 
>>> exposes in HTTP requests and JS interface navigator.languages. Instead of 
>>> sending all user’s Accept-Language, we only send the user’s most preferred 
>>> language after language negotiation in the Accept-Language header. 
>>> navigator.languages returns the same value as navigator.language during 
>>> this experiment. 
>>>
>>> We would like to run an origin trial for sites to opt into the Reduce 
>>> Accept-Language origin trial to proactively test for breakage. See below 
>>> for more details. 
>>>
>>> Implementation Doc
>>>
>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>
>>> Blink component
>>>
>>> Privacy>Fingerprinting 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The compatibility risk is low since we're planning to reduce the amount 
>>> of information in the Accept-Language header and navigator.languages, 
>>> rather than remove the header or change value format in the header. Most 
>>> existing Accept-Language detection code should continue to work. 
>>>
>>> As for interoperability, no signal for other vendors. For multilingual 
>>> sites to rely on the Accept-Language header, developers would need to 
>>> depend on a user's full Accept-Language list for some browsers and a 
>>> primary user's Accept-Language for others. 
>>>
>>> Another signal is that the Chrome incognito model already reduced the 
>>> Accept-Language header and JS interface navigator.languages to one 
>>> language. The Accept-Language header can potentially expand to two if the 
>>> first Accept-Language includes a region code, like en-US, the reduced 
>>> Accept-Language  header will be en-US,en;q=0.9. 
>>>
>>> Experiment Summary
>>>
>>> The experiment is going to be a little different from a normal Origin 
>>> Trial. The goal is enabling developers to test and ensure compatibility 
>>> with our proposed changes. It’s incredibly important we give developers any 
>>> chance to test systems at every level since this change represents vast 
>>> dependencies on the introduced headers. 
>>>
>>> As for enabling with the origin trial itself, there will be two 
>>> components controlled by the same origin trial:
>>>
>>>- 
>>>
>>>Reducing the information in navigator.languages if the origin trial 
>>>enabled.
>>>- 
>>>
>>>The Accept-Language HTTP request header contains the user’s primary 
>>&

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Hi Jeffrey,
Thanks for your information. I updated the Chrome Status entry to correctly
represent current status.
I will work on spec and migrate the explainer to CG if needed.

Bests,
Victor

On Tue, Nov 1, 2022 at 2:26 PM Jeffrey Yasskin 
wrote:

> I see that your Chrome Status entry
> <https://chromestatus.com/feature/5188040623390720#details> says
> "Specification being incubated in a Community Group", but your explainer is
> not hosted by a CG, and the specification you cite is 1) in a WG and 2) not
> the specification you'll need to write for this to be a web feature. Could
> you work on migrating this to a CG? And now that you've started an origin
> trial, it's also time to start working on your web-side specification,
> which will probably eventually merge into Fetch
> <https://fetch.spec.whatwg.org/#concept-fetch>. Let me or your spec mentor
> <https://sites.google.com/a/chromium.org/dev/blink/spec-mentors> know if
> you need help with that.
>
> Thanks,
> Jeffrey
>
> On Thu, Oct 27, 2022 at 10:57 AM Victor Tan 
> wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language header
>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>> sending all user’s Accept-Language, we only send the user’s most preferred
>> language after language negotiation in the Accept-Language header.
>> navigator.languages returns the same value as navigator.language during
>> this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the amount
>> of information in the Accept-Language header and navigator.languages,
>> rather than remove the header or change value format in the header. Most
>> existing Accept-Language detection code should continue to work.
>>
>> As for interoperability, no signal for other vendors. For multilingual
>> sites to rely on the Accept-Language header, developers would need to
>> depend on a user's full Accept-Language list for some browsers and a
>> primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin trial
>>enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s primary
>>preferred language, this can change if we detect a more preferred language
>>during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a valid
>> origin token must be sent in the response header by origins which opt-in
>> the origin trial. Also two new headers Variants
>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>> (indicating sites supporting languages) accept-language and
>> Content-Language <https://datatracker.ietf.org/doc/html/rfc3282> need to
>> be sent in the response header in order to make the languag

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Hi Will,
Please feel free to add your feedback and cases to
https://github.com/Tanych/accept-language once the origin trial is
available. Thanks.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:00 PM Will Dillard  wrote:

> You should keep all the languages in the Navigator even though it takes up
> more file space it helps people understand where they might want to
> navigate to and shows origin of speech which is not readily available it
> adds a nice touch and you should also include the narrator from Microsoft
> Edge or something like it. That's perspective and makes the software more
> diverse
>
> On Thu, Oct 27, 2022, 12:57 PM Victor Tan  wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language header
>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>> sending all user’s Accept-Language, we only send the user’s most preferred
>> language after language negotiation in the Accept-Language header.
>> navigator.languages returns the same value as navigator.language during
>> this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the amount
>> of information in the Accept-Language header and navigator.languages,
>> rather than remove the header or change value format in the header. Most
>> existing Accept-Language detection code should continue to work.
>>
>> As for interoperability, no signal for other vendors. For multilingual
>> sites to rely on the Accept-Language header, developers would need to
>> depend on a user's full Accept-Language list for some browsers and a
>> primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin trial
>>enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s primary
>>preferred language, this can change if we detect a more preferred language
>>during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a valid
>> origin token must be sent in the response header by origins which opt-in
>> the origin trial. Also two new headers Variants
>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>> (indicating sites supporting languages) accept-language and
>> Content-Language <https://datatracker.ietf.org/doc/html/rfc3282> need to
>> be sent in the response header in order to make the language negotiation to
>> work correctly.
>>
>> Please see the design and implementation document
>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#heading=h.b6kmd248xsy4>for
>> more information.
>>
>> Experiment Goals
>>
>> The goal of this origin trial is to enable developers to test how
>> reducing the Accept-Language request header and 

[blink-dev] Re: Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Hi Brian,
Currently, we don't have such a mechanism, but we can see how the origin
trial goes regarding the JS interface.
Free feel to add your feedback to
https://github.com/Tanych/accept-language once
the origin trial is available.

On Mon, Oct 31, 2022 at 8:32 PM Brian Birtles  wrote:

> Hi,
>
> Where should developers give feedback about this proposal?
>
> The changes to the Accept-Language header are ameliorated by the Variants
> header. Is there any such mechanism proposed for the changes to the JS
> interface?
>
> Thanks,
>
> Brian
>
> 2022年10月28日金曜日 2:57:18 UTC+9 vict...@chromium.org:
>
>> Contact emails
>>
>> vict...@chromium.org, mike...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language header
>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>> sending all user’s Accept-Language, we only send the user’s most preferred
>> language after language negotiation in the Accept-Language header.
>> navigator.languages returns the same value as navigator.language during
>> this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the amount
>> of information in the Accept-Language header and navigator.languages,
>> rather than remove the header or change value format in the header. Most
>> existing Accept-Language detection code should continue to work.
>>
>> As for interoperability, no signal for other vendors. For multilingual
>> sites to rely on the Accept-Language header, developers would need to
>> depend on a user's full Accept-Language list for some browsers and a
>> primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin trial
>>enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s primary
>>preferred language, this can change if we detect a more preferred language
>>during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a valid
>> origin token must be sent in the response header by origins which opt-in
>> the origin trial. Also two new headers Variants
>> 
>> (indicating sites supporting languages) accept-language and
>> Content-Language  need to
>> be sent in the response header in order to make the language negotiation to
>> work correctly.
>>
>> Please see the design and implementation document
>> for
>> more information.
>>
>> Experiment Goals
>>
>> The goal of this origin trial is to enable developers to test how
>> reducing the Accept-Language request header and the JS getter
>> navigator.languages will affect their systems, especially to understand the
>> user cases on navigator.languages. We hope this can provide sufficient time
>> for developers to test. We can validate our current plans for reducing
>> Accept-Language and safely roll out them to the web based on their feedback.
>>
>> We will be relying heavily on user and developer feedback to identify
>> where breakage occurs,  or where use cases are not accounted for,
>> especially for multilingual sites depending on the Accept-Language header,
>> and navigator.languages.  We will create a GitHub repository and a public
>> mailing list for gathering feedback. When the 

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Yeap, M109 to M104 inclusive is enough for this OT.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:58 AM Yoav Weiss  wrote:

> Even though this is not a typical OT, I don't think it should go beyond
> the current policy of 6 milestone before showing significant progress
> towards shipping.
> Would M109 to M114 (inclusive) be enough?
>
> On Mon, Oct 31, 2022 at 3:36 PM Victor Tan  wrote:
>
>> Sorry for the unclear end milestone, we would like to experiment from
>> M109 to M115.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss 
>> wrote:
>>
>>> When do you expect the experiment to end?
>>>
>>> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan 
>>> wrote:
>>>
>>>> We are expected to start in M109 Beta until 2023 Q2. We will document
>>>> more in the web blog post.
>>>>
>>>> Bests,
>>>> Victor
>>>>
>>>> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> That's fair. What is the experiment's timeline?
>>>>>
>>>>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
>>>>> wrote:
>>>>>
>>>>>> > How would the OT work for the Accept-Language values of the
>>>>>> very-first request sent to the origin?
>>>>>> As described in the implementation doc
>>>>>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#bookmark=id.ob15kaq2dmkv>,
>>>>>> there are some limitations for the current OT architecture, we can't
>>>>>> validate the response OT token before we send the request.
>>>>>> For the very first request, we are still sending the full
>>>>>> Accept-Language user's list, after we validate the response, all 
>>>>>> subsequent
>>>>>> requests start to send a reduced Accept-Language header.
>>>>>>
>>>>>> Bests,
>>>>>> Victor
>>>>>>
>>>>>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> How would the OT work for the Accept-Language values of the
>>>>>>> very-first request sent to the origin? Or are we expecting this request 
>>>>>>> to
>>>>>>> send higher entropy, but not to hide potential breakage with later 
>>>>>>> requests
>>>>>>> sending lower entropy?
>>>>>>>
>>>>>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Contact emails
>>>>>>>>
>>>>>>>> victor...@chromium.org, miketa...@chromium.org
>>>>>>>>
>>>>>>>> Explainer
>>>>>>>>
>>>>>>>> https://github.com/Tanych/accept-language
>>>>>>>>
>>>>>>>> Specification
>>>>>>>>
>>>>>>>> Variants header:
>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> We want to reduce the amount of information the Accept-Language
>>>>>>>> header exposes in HTTP requests and JS interface navigator.languages.
>>>>>>>> Instead of sending all user’s Accept-Language, we only send the user’s 
>>>>>>>> most
>>>>>>>> preferred language after language negotiation in the Accept-Language
>>>>>>>> header. navigator.languages returns the same value as 
>>>>>>>> navigator.language
>>>>>>>> during this experiment.
>>>>>>>>
>>>>>>>> We would like to run an origin trial for sites to opt into the
>>>>>>>> Reduce Accept-Language origin trial to proactively test for breakage. 
>>>>>>>> See
>>>>>>>> below for more details.
>>>>>>>>
>>>>>>>> Implementation Doc
>>>>>>>>
>>>>>>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>>>>>>
>>>>>>>> Blink component
>>>>>>&g

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Sorry for the unclear end milestone, we would like to experiment from M109
to M115.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss  wrote:

> When do you expect the experiment to end?
>
> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan  wrote:
>
>> We are expected to start in M109 Beta until 2023 Q2. We will document
>> more in the web blog post.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss 
>> wrote:
>>
>>> That's fair. What is the experiment's timeline?
>>>
>>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan 
>>> wrote:
>>>
>>>> > How would the OT work for the Accept-Language values of the
>>>> very-first request sent to the origin?
>>>> As described in the implementation doc
>>>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#bookmark=id.ob15kaq2dmkv>,
>>>> there are some limitations for the current OT architecture, we can't
>>>> validate the response OT token before we send the request.
>>>> For the very first request, we are still sending the full
>>>> Accept-Language user's list, after we validate the response, all subsequent
>>>> requests start to send a reduced Accept-Language header.
>>>>
>>>> Bests,
>>>> Victor
>>>>
>>>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> How would the OT work for the Accept-Language values of the very-first
>>>>> request sent to the origin? Or are we expecting this request to send 
>>>>> higher
>>>>> entropy, but not to hide potential breakage with later requests sending
>>>>> lower entropy?
>>>>>
>>>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>>>>> wrote:
>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> victor...@chromium.org, miketa...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>>
>>>>>> https://github.com/Tanych/accept-language
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> Variants header:
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> We want to reduce the amount of information the Accept-Language
>>>>>> header exposes in HTTP requests and JS interface navigator.languages.
>>>>>> Instead of sending all user’s Accept-Language, we only send the user’s 
>>>>>> most
>>>>>> preferred language after language negotiation in the Accept-Language
>>>>>> header. navigator.languages returns the same value as navigator.language
>>>>>> during this experiment.
>>>>>>
>>>>>> We would like to run an origin trial for sites to opt into the Reduce
>>>>>> Accept-Language origin trial to proactively test for breakage. See below
>>>>>> for more details.
>>>>>>
>>>>>> Implementation Doc
>>>>>>
>>>>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>>>>
>>>>>> Blink component
>>>>>>
>>>>>> Privacy>Fingerprinting
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> The compatibility risk is low since we're planning to reduce the
>>>>>> amount of information in the Accept-Language header and
>>>>>> navigator.languages, rather than remove the header or change value format
>>>>>> in the header. Most existing Accept-Language detection code should 
>>>>>> continue
>>>>>> to work.
>>>>>>
>>>>>> As for interoperability, no signal for other vendors. For
>>>>>> multilingual sites to rely on the Accept-Language header, developers 
>>>>>> would
>>>>>> need to depend on a user's full Accept-Language list for some browsers 
>>>>>> and
>>>>>> a primary user's Accept-Language for others.
>>>>>>
>

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

We are expected to start in M109 Beta until 2023 Q2. We will document more
in the web blog post.

Bests,
Victor

On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss  wrote:

> That's fair. What is the experiment's timeline?
>
> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan  wrote:
>
>> > How would the OT work for the Accept-Language values of the very-first
>> request sent to the origin?
>> As described in the implementation doc
>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#bookmark=id.ob15kaq2dmkv>,
>> there are some limitations for the current OT architecture, we can't
>> validate the response OT token before we send the request.
>> For the very first request, we are still sending the full Accept-Language
>> user's list, after we validate the response, all subsequent requests start
>> to send a reduced Accept-Language header.
>>
>> Bests,
>> Victor
>>
>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss 
>> wrote:
>>
>>> How would the OT work for the Accept-Language values of the very-first
>>> request sent to the origin? Or are we expecting this request to send higher
>>> entropy, but not to hide potential breakage with later requests sending
>>> lower entropy?
>>>
>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan 
>>> wrote:
>>>
>>>> Contact emails
>>>>
>>>> victor...@chromium.org, miketa...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/Tanych/accept-language
>>>>
>>>> Specification
>>>>
>>>> Variants header:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>>
>>>> Summary
>>>>
>>>> We want to reduce the amount of information the Accept-Language header
>>>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>>>> sending all user’s Accept-Language, we only send the user’s most preferred
>>>> language after language negotiation in the Accept-Language header.
>>>> navigator.languages returns the same value as navigator.language during
>>>> this experiment.
>>>>
>>>> We would like to run an origin trial for sites to opt into the Reduce
>>>> Accept-Language origin trial to proactively test for breakage. See below
>>>> for more details.
>>>>
>>>> Implementation Doc
>>>>
>>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>>
>>>> Blink component
>>>>
>>>> Privacy>Fingerprinting
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> The compatibility risk is low since we're planning to reduce the amount
>>>> of information in the Accept-Language header and navigator.languages,
>>>> rather than remove the header or change value format in the header. Most
>>>> existing Accept-Language detection code should continue to work.
>>>>
>>>> As for interoperability, no signal for other vendors. For multilingual
>>>> sites to rely on the Accept-Language header, developers would need to
>>>> depend on a user's full Accept-Language list for some browsers and a
>>>> primary user's Accept-Language for others.
>>>>
>>>> Another signal is that the Chrome incognito model already reduced the
>>>> Accept-Language header and JS interface navigator.languages to one
>>>> language. The Accept-Language header can potentially expand to two if the
>>>> first Accept-Language includes a region code, like en-US, the reduced
>>>> Accept-Language  header will be en-US,en;q=0.9.
>>>>
>>>> Experiment Summary
>>>>
>>>> The experiment is going to be a little different from a normal Origin
>>>> Trial. The goal is enabling developers to test and ensure compatibility
>>>> with our proposed changes. It’s incredibly important we give developers any
>>>> chance to test systems at every level since this change represents vast
>>>> dependencies on the introduced headers.
>>>>
>>>> As for enabling with the origin trial itself, there will be two
>>>> components controlled by the same origin trial:
>>>>
>>>>-
>>>>
>>&g

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

> How would the OT work for the Accept-Language values of the very-first
request sent to the origin?
As described in the implementation doc
<https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#bookmark=id.ob15kaq2dmkv>,
there are some limitations for the current OT architecture, we can't
validate the response OT token before we send the request.
For the very first request, we are still sending the full Accept-Language
user's list, after we validate the response, all subsequent requests start
to send a reduced Accept-Language header.

Bests,
Victor

On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss  wrote:

> How would the OT work for the Accept-Language values of the very-first
> request sent to the origin? Or are we expecting this request to send higher
> entropy, but not to hide potential breakage with later requests sending
> lower entropy?
>
> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan  wrote:
>
>> Contact emails
>>
>> victor...@chromium.org, miketa...@chromium.org
>>
>> Explainer
>>
>> https://github.com/Tanych/accept-language
>>
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> We want to reduce the amount of information the Accept-Language header
>> exposes in HTTP requests and JS interface navigator.languages. Instead of
>> sending all user’s Accept-Language, we only send the user’s most preferred
>> language after language negotiation in the Accept-Language header.
>> navigator.languages returns the same value as navigator.language during
>> this experiment.
>>
>> We would like to run an origin trial for sites to opt into the Reduce
>> Accept-Language origin trial to proactively test for breakage. See below
>> for more details.
>>
>> Implementation Doc
>>
>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The compatibility risk is low since we're planning to reduce the amount
>> of information in the Accept-Language header and navigator.languages,
>> rather than remove the header or change value format in the header. Most
>> existing Accept-Language detection code should continue to work.
>>
>> As for interoperability, no signal for other vendors. For multilingual
>> sites to rely on the Accept-Language header, developers would need to
>> depend on a user's full Accept-Language list for some browsers and a
>> primary user's Accept-Language for others.
>>
>> Another signal is that the Chrome incognito model already reduced the
>> Accept-Language header and JS interface navigator.languages to one
>> language. The Accept-Language header can potentially expand to two if the
>> first Accept-Language includes a region code, like en-US, the reduced
>> Accept-Language  header will be en-US,en;q=0.9.
>>
>> Experiment Summary
>>
>> The experiment is going to be a little different from a normal Origin
>> Trial. The goal is enabling developers to test and ensure compatibility
>> with our proposed changes. It’s incredibly important we give developers any
>> chance to test systems at every level since this change represents vast
>> dependencies on the introduced headers.
>>
>> As for enabling with the origin trial itself, there will be two
>> components controlled by the same origin trial:
>>
>>-
>>
>>Reducing the information in navigator.languages if the origin trial
>>enabled.
>>-
>>
>>The Accept-Language HTTP request header contains the user’s primary
>>preferred language, this can change if we detect a more preferred language
>>during the language negotiation process.
>>
>> Because of the experimental nature of reducing Accept-Language, a valid
>> origin token must be sent in the response header by origins which opt-in
>> the origin trial. Also two new headers Variants
>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>> (indicating sites supporting languages) accept-language and
>> Content-Language <https://datatracker.ietf.org/doc/html/rfc3282> need to
>> be sent in the response header in order to make the language negotiation to
>> work correctly.
>>
>> Please see the design and implementation document
>> <https://docs.google.com/document/d/1R

[blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org

Explainer

https://github.com/Tanych/accept-language

Specification

Variants header:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

Summary

We want to reduce the amount of information the Accept-Language header
exposes in HTTP requests and JS interface navigator.languages. Instead of
sending all user’s Accept-Language, we only send the user’s most preferred
language after language negotiation in the Accept-Language header.
navigator.languages returns the same value as navigator.language during
this experiment.

We would like to run an origin trial for sites to opt into the Reduce
Accept-Language origin trial to proactively test for breakage. See below
for more details.

Implementation Doc
https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY

Blink component

Privacy>Fingerprinting


Risks

Interoperability and Compatibility

The compatibility risk is low since we're planning to reduce the amount of
information in the Accept-Language header and navigator.languages, rather
than remove the header or change value format in the header. Most existing
Accept-Language detection code should continue to work.

As for interoperability, no signal for other vendors. For multilingual
sites to rely on the Accept-Language header, developers would need to
depend on a user's full Accept-Language list for some browsers and a
primary user's Accept-Language for others.

Another signal is that the Chrome incognito model already reduced the
Accept-Language header and JS interface navigator.languages to one
language. The Accept-Language header can potentially expand to two if the
first Accept-Language includes a region code, like en-US, the reduced
Accept-Language  header will be en-US,en;q=0.9.

Experiment Summary

The experiment is going to be a little different from a normal Origin
Trial. The goal is enabling developers to test and ensure compatibility
with our proposed changes. It’s incredibly important we give developers any
chance to test systems at every level since this change represents vast
dependencies on the introduced headers.

As for enabling with the origin trial itself, there will be two components
controlled by the same origin trial:

   -

   Reducing the information in navigator.languages if the origin trial
   enabled.
   -

   The Accept-Language HTTP request header contains the user’s primary
   preferred language, this can change if we detect a more preferred language
   during the language negotiation process.

Because of the experimental nature of reducing Accept-Language, a valid
origin token must be sent in the response header by origins which opt-in
the origin trial. Also two new headers Variants

(indicating sites supporting languages) accept-language and Content-Language
 need to be sent in the
response header in order to make the language negotiation to work correctly.

Please see the design and implementation document
for
more information.

Experiment Goals

The goal of this origin trial is to enable developers to test how reducing
the Accept-Language request header and the JS getter navigator.languages
will affect their systems, especially to understand the user cases on
navigator.languages. We hope this can provide sufficient time for
developers to test. We can validate our current plans for reducing
Accept-Language and safely roll out them to the web based on their feedback.

We will be relying heavily on user and developer feedback to identify where
breakage occurs,  or where use cases are not accounted for, especially for
multilingual sites depending on the Accept-Language header, and
navigator.languages.  We will create a GitHub repository and a public
mailing list for gathering feedback. When the origin trial is ready, we
plan to publish developer guidance on how to enroll and provide feedback.

Experiment Risks

There are some risks, as many multilingual sites have come to rely on the
value in Accept-Language header and JS interfaces navigator.languages to
send the right representation pages to the user.  Site breakage can take
many forms, both obvious and non-obvious. However, since sites are in
control of the Origin-Trial, Variants and Content-Language headers, a site
can quickly opt out of the experiment when breakage is encountered.

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

No (All but WebView)

Is this feature fully tested by web-platform-tests

?

No (We fully test in browser_tests, 

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Thanks all. I just realized there are some date typos for the roll out
plan. Update as follows:

Stage

Time

Date

Stable 1% (M107+)

Canary/Dev/Beta 100%

M107 stable release is shipping to 100% (a best guess)

Nov 1, 2022

Stable 10% (M107/M108/M109)

~10 weeks after previous stage

Jan 9, *2023*

Stable 50%

(M107/M108/M109)

~2 weeks

Jan 23, *2023*

TOT Default (M111)

~2 weeks after previous stage

Feb 7, *2023*

Stable 100% (M107=>M111)

~ Same business day as previous stage

Feb 7, *2023*

Bests,
Victor

On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  wrote:

> LGTM3
>
> On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2022-09-07 17:50, Chris Harrelson wrote:
>>
>> LGTM1. If any issues come up during this rollout that affect the plan,
>> please bring them back to this thread for our consideration.
>>
>> On Thu, Sep 1, 2022 at 11:29 AM Victor Tan 
>> wrote:
>>
>>> Contact emails
>>>
>>> miketa...@chromium.org, victor...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>
>>> Specification
>>>
>>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>>> specifies Chrome’s UA Reduction plans today. As these changes land in
>>> Chromium and ship to 100% of stable, the Compat Standard
>>> <https://compat.spec.whatwg.org/> will be updated in the UA String
>>> section <https://compat.spec.whatwg.org/#ua-string-pattern-chrome>,
>>> like we did for the Phase 4 changes.
>>>
>>> Summary
>>>
>>> As previously detailed on the Chromium Blog
>>> <https://blog.chromium.org/2021/09/user-agent-reduction-origin-trial-and-dates.html>,
>>> we intend to proceed with Phase 5 of the User-Agent Reduction plan
>>> <https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-5>.
>>> In Phase 5, the User-Agent string changes the platform and oscpu tokens
>>> from their platform-defined values to the relevant unifiedPlatform
>>> <https://www.chromium.org/updates/ua-reduction/#token-reference> token
>>> value. The `navigator.platform`, `navigator.platform`, and
>>> `navigator.appVersion` JS APIs will be similarly reduced.
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/640
>>>
>>> TAG review status
>>>
>>> Closed with concerns.
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Any time you modify the User-Agent string there is a risk of some
>>> content somewhere depending on the previous format.
>>>
>>> We do not expect interop risks, as each browser sends its own User-Agent
>>> string format. But there is a risk, especially on legacy Windows platforms,
>>> that content somewhere is relying on User-Agents to parse platform and
>>> oscpu information. We believe the risk is somewhat low. But in order to
>>> mitigate the risk of this change, we intend to slowly roll it out via Finch
>>> creating two sub groups: one group enabling the feature for all platforms
>>> except legacy Windows platforms, another group enabling the feature on
>>> legacy Windows platforms and observing health metrics and bug reports. This
>>> gives us the option to roll this back specifically for legacy Windows
>>> clients if needed, but proceed for other platforms.
>>>
>>> Displaying a modern OS version for legacy clients will not create a
>>> problem syntactically on legacy Windows platforms. But the web can get
>>> pretty weird in ways we don't anticipate, hence the slow roll-out and
>>> incremental path towards User-Agent Reduction.
>>>
>>> Here is our proposed rollout plan, with the understanding that if we
>>> discover concerning breakage or regressions via health metrics or bug
>>> reports we will pause the rollout or roll back the feature entirely (and
>>> update this thread if so):
>>>
>>> Stage
>>>
>>> Time
>>>
>>> Date
>>>
>>> Stable 1% (M107+)
>>>
>>> Canary/Dev/Beta 100%
>>>
>>> M107 stable release is shipping to 100% (a best guess)
>>>
>>> Nov 1, 2022
>>>
>>> Stable 10% (M107/M108/M109)
>>>
>>> ~10 weeks after previous stage
>>&

[blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Contact emails

miketa...@chromium.org, victor...@chromium.org

Explainer

https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity

Specification

https://www.chromium.org/updates/ua-reduction is the closest thing that
specifies Chrome’s UA Reduction plans today. As these changes land in
Chromium and ship to 100% of stable, the Compat Standard
 will be updated in the UA String section
, like we did for
the Phase 4 changes.

Summary

As previously detailed on the Chromium Blog
,
we intend to proceed with Phase 5 of the User-Agent Reduction plan
.
In Phase 5, the User-Agent string changes the platform and oscpu tokens
from their platform-defined values to the relevant unifiedPlatform
 token
value. The `navigator.platform`, `navigator.platform`, and
`navigator.appVersion` JS APIs will be similarly reduced.

Blink component

Blink>Network>ClientHints

TAG review

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

TAG review status

Closed with concerns.

Risks
Interoperability and Compatibility

Any time you modify the User-Agent string there is a risk of some content
somewhere depending on the previous format.

We do not expect interop risks, as each browser sends its own User-Agent
string format. But there is a risk, especially on legacy Windows platforms,
that content somewhere is relying on User-Agents to parse platform and
oscpu information. We believe the risk is somewhat low. But in order to
mitigate the risk of this change, we intend to slowly roll it out via Finch
creating two sub groups: one group enabling the feature for all platforms
except legacy Windows platforms, another group enabling the feature on
legacy Windows platforms and observing health metrics and bug reports. This
gives us the option to roll this back specifically for legacy Windows
clients if needed, but proceed for other platforms.

Displaying a modern OS version for legacy clients will not create a problem
syntactically on legacy Windows platforms. But the web can get pretty weird
in ways we don't anticipate, hence the slow roll-out and incremental path
towards User-Agent Reduction.

Here is our proposed rollout plan, with the understanding that if we
discover concerning breakage or regressions via health metrics or bug
reports we will pause the rollout or roll back the feature entirely (and
update this thread if so):

Stage

Time

Date

Stable 1% (M107+)

Canary/Dev/Beta 100%

M107 stable release is shipping to 100% (a best guess)

Nov 1, 2022

Stable 10% (M107/M108/M109)

~10 weeks after previous stage

Jan 9, 2022

Stable 50%

(M107/M108/M109)

~2 weeks

Jan 23, 2022

TOT Default (M111)

~2 weeks after previous stage

Feb 7, 2022

Stable 100% (M107=>M111)

~ Same business day as previous stage

Feb 7, 2022


Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
string already.

WebKit: Shipped/Shipping. Safari has already frozen everything in their
desktop UA string except for Safari and WebKit versions.

Web developers: Mixed signals. Reactions have ranged from positive to
indifferent to negative, from various channels.

Debuggability

No special DevTools support needed.

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

No (Only for desktop platforms: Windows, Mac, Linux, Chrome OS)

Is this feature fully tested by web-platform-tests

?

No

Flag name

#reduce-user-agent-platform-oscpu

Tracking bug

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

Launch bug

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

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5098783126323200

-- 
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/CAJh4P7FysJS2D2i4G3YNkf6X8N4_eyUcP%2BpoFrUB_ikdiATwuA%40mail.gmail.com.

[blink-dev] Re: Intent to Extend Experiment: User-Agent Reduction Origin Trial

[Victor Tan]

Hi, 
The User-Agent Reduction Origin Trial is now live and will continue to work 
until Oct 18.

Bests,
Victor

On Tuesday, August 2, 2022 at 1:44:52 PM UTC-4 Mike Taylor wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * Hi there, We would like to extend the User-Agent Reduction OT again, 
> from M104 to M106 (inclusive). The original extension expired on July 26th. 
> We’ve heard from several partners that they would like to have more time to 
> test the fully reduced UA string ahead of Phase 5 and Phase 6 rollouts.  
> Original I2E 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ/ 
>   
> First I2EE 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6x6WH2Odzfo/m/FkDjee5cHQAJ
>  
> 
>   
> Experiment Timeline M103-M106 inclusive Reason this experiment is being 
> extended Like the previous extension, we believe the risks for burn-in 
> don't apply, because this OT just enables what we are planning to ship as 
> default behavior in the future (and the OT stopped working last week). We 
> still have not received negative feedback or reports of breaking from OT 
> participants, and are encouraged by that fact. Here’s the relevant info 
> required for OT extensions beyond 6 milestones: Draft spec:  - 
> https://compat.spec.whatwg.org/#ua-string-chrome 
>   - We’ve made solid 
> progress against the open UA string issues, and have documented the recent 
> landing of “Phase 4” in Chromium. We plan to continue improving things 
> here. TAG review: - https://github.com/w3ctag/design-reviews/issues/640 
>  - closed as 
> “Satisfied with concerns” bit.ly/blink-signals 
>  requests - Gecko: Shipped/Shipping. Firefox 
> has frozen (or capped) much of their UA string already. - WebKit: 
> Shipped/Shipping. Safari has already frozen everything in their UA string 
> except for version number info. - Web developers: Mixed signals. Reactions 
> have ranged from positive to indifferent to negative, from various 
> channels. WPT tests - None yet, since UAs have flexibility to diverge 
> here. With more alignment, this may make sense in the future. Thanks, Mike *
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b045bf59-e73a-462d-9bc4-f096dde1e89fn%40chromium.org.

[blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

yea, for malicious site trying to learn all of the user’s language 
preference, we probably will start rate limit language changes or distinct 
language lists from a site.  
It could be practical when taking advantage of the existing storage service 
(Prefs) in Chromium. 
I will double check the example related to incognito mode. it should be 
helpful. 

On Monday, May 23, 2022 at 5:37:17 PM UTC-4 eri...@microsoft.com wrote:

> The fact that the server can still actively probe to discover all of the 
> users' languages makes this feel like a questionable Privacy/UX tradeoff; 
> do we think the mitigations listed in the explainer are practical?
>
> It would also be helpful if this proposal included learnings from the 
> rollout of the similar change made to Incognito mode (
> https://bugs.chromium.org/p/chromium/issues/detail?id=1077547#c32)
>
> On Thursday, May 19, 2022 at 9:20:29 AM UTC-5 vict...@chromium.org wrote:
>
>> Contact emails
>>
>> vict...@chromium.org, abe...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/Tanych/accept-language 
>> Specification
>>
>> Variants header: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> Support the HTTP Variants header and implement the reduction of 
>> information that could be used for fingerprinting in the Accept-Language 
>> header, so that Chrome only sends the user’s most preferred language in the 
>> Accept-Language header on the initial request.
>> Blink component
>>
>> Privacy>Fingerprinting 
>> 
>>
>> Motivation
>>
>>
>> The Accept-Language header is a source of passive fingerprinting 
>> information about users, as it can contain a high degree of entropy, 
>> particularly if the user has many accepted languages. 
>>
>> Chrome (and other browsers) send a full list of the user's accepted 
>> languages on every HTTP request via the Accept-Language header. While some 
>> sites use this information for content negotiation, servers can also 
>> passively capture this information without the user's awareness, to 
>> fingerprint a user.  
>>
>> We propose to only send a single language—one of the user’s preferred 
>> languages determined by the language negotiation process—in the 
>> Accept-Language request header by default. Here’s what that would look like 
>> when a user tries to access https://example.com:
>>
>> Get / HTTP/1.1
>>
>> Host: example.com
>>
>> Accept-Language: en
>>
>> HTTP/1.1 200 OK
>>
>> Content-Language: en
>>
>> Vary: Accept-Language
>>
>> Variants: Accept-Language=(en)
>>
>> As the response shows, in addition to the Content-Language in the 
>> response header, sites will respond with a Variants 
>>  
>> header (support for which will be prototyped as part of this intent), the 
>> value of which includes all the languages the site supports. Browsers can 
>> use the Variants header to do language negotiation if sites offer a page in 
>> a language that doesn’t match the user's preferred languages. Initial 
>> public proposal
>>
>>
>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>>  
>>
>>
>> TAG review
>>
>> To be filed.
>>
>> RisksInteroperability and Compatibility
>>
>> We are reducing the number of languages sent in the Accept-Language 
>> header to protect user privacy. The main source of risk is that sites rely 
>> on all or part of a user’s preferred languages instead of the most 
>> preferred language. We feel it’s important to minimize the breakage of the 
>> features depending on Accept-Language as much as possible, to maintain 
>> stability of the web ecosystem. To mitigate the risk of this change, we 
>> intend to gradually roll it out via Finch configuration and keep monitoring 
>> health metrics and bug reports from the community. 
>>
>> Gecko: No signals
>>
>> WebKit: No signals
>>
>> Web developers:  See the explainer for details.
>> Debuggability
>>
>> No special DevTools support needed.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>>
>> It will be.
>>
>> Flag name
>>
>> reduce-accept-language
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905
>>
>>
>> *Launch bug*
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484  
>>
>
>> *Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5188040623390720 
>> 
>>
>>
>>

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

[blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

1. We will start limit navigator.languages to return only a single 
language. we know it might cause impacts in some cases. Also, will keep 
tracking how it works in the ecosystem. 
2. Users can only know one language, in this case, which makes service 
confused.  We will monitor how the performance works when introduce the 
resending. 
3. thanks for your suggestion. will double check with team to add options 
for users to determine their language privacy in this case.  

On Monday, May 23, 2022 at 10:35:04 AM UTC-4 han.g...@gmail.com wrote:

> 1. What about pure client side i18n?
> If `navigator.languages` limits to an array which has only one language, 
> client can't select the best language if the first doesn't match.
>
> 2. Could it send two languages in Accept-Language header by default (not 
> one)?
> I guest a lot of people can understand one or two languages, but few 
> people can understand more than 4 languages. To trade off 
> performance(resending request) and privacy, maybe sending two languages in 
> Accept-Language by default is better.
>
> 3. Could browser add a setting (in chrome://settings/privacy) for users to 
> confirm what information is user's privacy?
> What is personal privacy actually varies from person to person. For 
> example, for me, I don't care others know what languages I can speak. If a 
> user check "languages is not in his/her privacy scope", browser can send 
> all languages in Accept-Language header. If the user select "languages I 
> can understand are my privacy", browser could even not send any language 
> (no Accept-Language).
>
> On Thursday, May 19, 2022 at 10:20:29 PM UTC+8 vict...@chromium.org wrote:
>
>> Contact emails
>>
>> vict...@chromium.org, abe...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/Tanych/accept-language 
>> Specification
>>
>> Variants header: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> Support the HTTP Variants header and implement the reduction of 
>> information that could be used for fingerprinting in the Accept-Language 
>> header, so that Chrome only sends the user’s most preferred language in the 
>> Accept-Language header on the initial request.
>> Blink component
>>
>> Privacy>Fingerprinting 
>> 
>>
>> Motivation
>>
>>
>> The Accept-Language header is a source of passive fingerprinting 
>> information about users, as it can contain a high degree of entropy, 
>> particularly if the user has many accepted languages. 
>>
>> Chrome (and other browsers) send a full list of the user's accepted 
>> languages on every HTTP request via the Accept-Language header. While some 
>> sites use this information for content negotiation, servers can also 
>> passively capture this information without the user's awareness, to 
>> fingerprint a user.  
>>
>> We propose to only send a single language—one of the user’s preferred 
>> languages determined by the language negotiation process—in the 
>> Accept-Language request header by default. Here’s what that would look like 
>> when a user tries to access https://example.com:
>>
>> Get / HTTP/1.1
>>
>> Host: example.com
>>
>> Accept-Language: en
>>
>> HTTP/1.1 200 OK
>>
>> Content-Language: en
>>
>> Vary: Accept-Language
>>
>> Variants: Accept-Language=(en)
>>
>> As the response shows, in addition to the Content-Language in the 
>> response header, sites will respond with a Variants 
>>  
>> header (support for which will be prototyped as part of this intent), the 
>> value of which includes all the languages the site supports. Browsers can 
>> use the Variants header to do language negotiation if sites offer a page in 
>> a language that doesn’t match the user's preferred languages. Initial 
>> public proposal
>>
>>
>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>>  
>>
>>
>> TAG review
>>
>> To be filed.
>>
>> RisksInteroperability and Compatibility
>>
>> We are reducing the number of languages sent in the Accept-Language 
>> header to protect user privacy. The main source of risk is that sites rely 
>> on all or part of a user’s preferred languages instead of the most 
>> preferred language. We feel it’s important to minimize the breakage of the 
>> features depending on Accept-Language as much as possible, to maintain 
>> stability of the web ecosystem. To mitigate the risk of this change, we 
>> intend to gradually roll it out via Finch configuration and keep monitoring 
>> health metrics and bug reports from the community. 
>>
>> Gecko: No signals
>>
>> WebKit: No signals
>>
>> Web developers:  See the explainer for details.
>> Debuggability
>>
>> No special DevTools support needed.
>>
>> Is this feature fully tested by web-platform-tests 
>> 

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

Yea, we definitely will collect metrics on those performance. thanks for 
your comments. 

On Sunday, May 22, 2022 at 2:08:02 PM UTC-4 Harald Alvestrand wrote:

> I hope you will be recording the percentage of extra round trips, split on 
> main language preference. This may be a disproportionate impact on people 
> without English as their first language.
>
>
>
> On Sun, May 22, 2022 at 6:15 PM Victor Tan  wrote:
>
>> The browser will only do language negotiation if necessary. Yea, you are 
>> right, it would take an extra round trip in some cases. We also plan to 
>> save some selections in memory to avoid introducing large latency.  
>>
>> On Sunday, May 22, 2022 at 12:11:23 PM UTC-4 Harald Alvestrand wrote:
>>
>>> So one extra round trip per page?
>>>
>>>
>>> On Sun, May 22, 2022 at 5:31 PM Victor Tan  
>>> wrote:
>>>
>>>> Hi Harald, 
>>>> The browser will do language negotiation with resend the request (only 
>>>> happen once) with accept-language:en to get a result with English page. 
>>>>
>>>> Victor
>>>>
>>>> On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote:
>>>>
>>>>> So if my config is (no, en), the site supports (fr, en), the first 
>>>>> response will be in French with a Vary:(fr, en) header? Will the browser 
>>>>> automatically detect that a better alternative is available and re-ask, 
>>>>> imposing an extra RTT, or will the result remain French?
>>>>>
>>>>> fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
>>>>> blink-dev@chromium.org>:
>>>>>
>>>>>> NOTES: This intend won't implement Variants in the HTTP cache. It 
>>>>>> only focus on using Variants http header as a support-languages head 
>>>>>> which 
>>>>>> in the definition on section 2  
>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>>>>>> .
>>>>>>
>>>>>> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emails
>>>>>>>
>>>>>>> vict...@chromium.org, abe...@chromium.org
>>>>>>>
>>>>>>> Explainer
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/Tanych/accept-language 
>>>>>>> Specification
>>>>>>>
>>>>>>> Variants header: 
>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> Support the HTTP Variants header and implement the reduction of 
>>>>>>> information that could be used for fingerprinting in the 
>>>>>>> Accept-Language 
>>>>>>> header, so that Chrome only sends the user’s most preferred language in 
>>>>>>> the 
>>>>>>> Accept-Language header on the initial request.
>>>>>>> Blink component
>>>>>>>
>>>>>>> Privacy>Fingerprinting 
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>>>>>
>>>>>>> Motivation
>>>>>>>
>>>>>>>
>>>>>>> The Accept-Language header is a source of passive fingerprinting 
>>>>>>> information about users, as it can contain a high degree of entropy, 
>>>>>>> particularly if the user has many accepted languages. 
>>>>>>>
>>>>>>> Chrome (and other browsers) send a full list of the user's accepted 
>>>>>>> languages on every HTTP request via the Accept-Language header. While 
>>>>>>> some 
>>>>>>> sites use this information for content negotiation, servers can also 
>>>>>>> passively capture this information without the user's awareness, to 
>>>>>>> fingerprint a user.  
>>>>>>>
>>>>>>> We propose to only send a single language—one of the user’s 
>>>>>>> preferred languages determined by the language negotiation process—in 
>>>>>>> the 
>>>>>>> Accept-L

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

The browser will only do language negotiation if necessary. Yea, you are 
right, it would take an extra round trip in some cases. We also plan to 
save some selections in memory to avoid introducing large latency.  

On Sunday, May 22, 2022 at 12:11:23 PM UTC-4 Harald Alvestrand wrote:

> So one extra round trip per page?
>
>
> On Sun, May 22, 2022 at 5:31 PM Victor Tan  wrote:
>
>> Hi Harald, 
>> The browser will do language negotiation with resend the request (only 
>> happen once) with accept-language:en to get a result with English page. 
>>
>> Victor
>>
>> On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote:
>>
>>> So if my config is (no, en), the site supports (fr, en), the first 
>>> response will be in French with a Vary:(fr, en) header? Will the browser 
>>> automatically detect that a better alternative is available and re-ask, 
>>> imposing an extra RTT, or will the result remain French?
>>>
>>> fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
>>> blink-dev@chromium.org>:
>>>
>>>> NOTES: This intend won't implement Variants in the HTTP cache. It only 
>>>> focus on using Variants http header as a support-languages head which in 
>>>> the definition on section 2  
>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>>>> .
>>>>
>>>> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org 
>>>> wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> vict...@chromium.org, abe...@chromium.org
>>>>>
>>>>> Explainer
>>>>>
>>>>>
>>>>> https://github.com/Tanych/accept-language 
>>>>> Specification
>>>>>
>>>>> Variants header: 
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>>>
>>>>> Summary
>>>>>
>>>>> Support the HTTP Variants header and implement the reduction of 
>>>>> information that could be used for fingerprinting in the Accept-Language 
>>>>> header, so that Chrome only sends the user’s most preferred language in 
>>>>> the 
>>>>> Accept-Language header on the initial request.
>>>>> Blink component
>>>>>
>>>>> Privacy>Fingerprinting 
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>>>
>>>>> Motivation
>>>>>
>>>>>
>>>>> The Accept-Language header is a source of passive fingerprinting 
>>>>> information about users, as it can contain a high degree of entropy, 
>>>>> particularly if the user has many accepted languages. 
>>>>>
>>>>> Chrome (and other browsers) send a full list of the user's accepted 
>>>>> languages on every HTTP request via the Accept-Language header. While 
>>>>> some 
>>>>> sites use this information for content negotiation, servers can also 
>>>>> passively capture this information without the user's awareness, to 
>>>>> fingerprint a user.  
>>>>>
>>>>> We propose to only send a single language—one of the user’s preferred 
>>>>> languages determined by the language negotiation process—in the 
>>>>> Accept-Language request header by default. Here’s what that would look 
>>>>> like 
>>>>> when a user tries to access https://example.com:
>>>>>
>>>>> Get / HTTP/1.1
>>>>>
>>>>> Host: example.com
>>>>>
>>>>> Accept-Language: en
>>>>>
>>>>> HTTP/1.1 200 OK
>>>>>
>>>>> Content-Language: en
>>>>>
>>>>> Vary: Accept-Language
>>>>>
>>>>> Variants: Accept-Language=(en)
>>>>>
>>>>> As the response shows, in addition to the Content-Language in the 
>>>>> response header, sites will respond with a Variants 
>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06> 
>>>>> header (support for which will be prototyped as part of this intent), the 
>>>>> value of which includes all the languages the site supports. Browsers can 
>>>>> use the Variants header to do language negotiation if sites offer a

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

Hi Harald, 
The browser will do language negotiation with resend the request (only 
happen once) with accept-language:en to get a result with English page. 

Victor

On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote:

> So if my config is (no, en), the site supports (fr, en), the first 
> response will be in French with a Vary:(fr, en) header? Will the browser 
> automatically detect that a better alternative is available and re-ask, 
> imposing an extra RTT, or will the result remain French?
>
> fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
> blink-dev@chromium.org>:
>
>> NOTES: This intend won't implement Variants in the HTTP cache. It only 
>> focus on using Variants http header as a support-languages head which in 
>> the definition on section 2  
>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
>> .
>>
>> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org 
>> wrote:
>>
>>> Contact emails
>>>
>>> vict...@chromium.org, abe...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/Tanych/accept-language 
>>> Specification
>>>
>>> Variants header: 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>
>>> Summary
>>>
>>> Support the HTTP Variants header and implement the reduction of 
>>> information that could be used for fingerprinting in the Accept-Language 
>>> header, so that Chrome only sends the user’s most preferred language in the 
>>> Accept-Language header on the initial request.
>>> Blink component
>>>
>>> Privacy>Fingerprinting 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>
>>> Motivation
>>>
>>>
>>> The Accept-Language header is a source of passive fingerprinting 
>>> information about users, as it can contain a high degree of entropy, 
>>> particularly if the user has many accepted languages. 
>>>
>>> Chrome (and other browsers) send a full list of the user's accepted 
>>> languages on every HTTP request via the Accept-Language header. While some 
>>> sites use this information for content negotiation, servers can also 
>>> passively capture this information without the user's awareness, to 
>>> fingerprint a user.  
>>>
>>> We propose to only send a single language—one of the user’s preferred 
>>> languages determined by the language negotiation process—in the 
>>> Accept-Language request header by default. Here’s what that would look like 
>>> when a user tries to access https://example.com:
>>>
>>> Get / HTTP/1.1
>>>
>>> Host: example.com
>>>
>>> Accept-Language: en
>>>
>>> HTTP/1.1 200 OK
>>>
>>> Content-Language: en
>>>
>>> Vary: Accept-Language
>>>
>>> Variants: Accept-Language=(en)
>>>
>>> As the response shows, in addition to the Content-Language in the 
>>> response header, sites will respond with a Variants 
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06> 
>>> header (support for which will be prototyped as part of this intent), the 
>>> value of which includes all the languages the site supports. Browsers can 
>>> use the Variants header to do language negotiation if sites offer a page in 
>>> a language that doesn’t match the user's preferred languages. Initial 
>>> public proposal
>>>
>>>
>>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>>>  
>>>
>>>
>>> TAG review
>>>
>>> To be filed.
>>>
>>> RisksInteroperability and Compatibility
>>>
>>> We are reducing the number of languages sent in the Accept-Language 
>>> header to protect user privacy. The main source of risk is that sites rely 
>>> on all or part of a user’s preferred languages instead of the most 
>>> preferred language. We feel it’s important to minimize the breakage of the 
>>> features depending on Accept-Language as much as possible, to maintain 
>>> stability of the web ecosystem. To mitigate the risk of this change, we 
>>> intend to gradually roll it out via Finch configuration and keep monitoring 
>>> health metrics and bug reports from the community. 
>>>
>>> Gecko: No signals
>>>
>>&

[blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Victor Tan' via blink-dev]

NOTES: This intend won't implement Variants in the HTTP cache. It only 
focus on using Variants http header as a support-languages head which in 
the definition on section 2  

.

On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org wrote:

> Contact emails
>
> vict...@chromium.org, abe...@chromium.org
>
> Explainer
>
>
> https://github.com/Tanych/accept-language 
> Specification
>
> Variants header: 
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> Support the HTTP Variants header and implement the reduction of 
> information that could be used for fingerprinting in the Accept-Language 
> header, so that Chrome only sends the user’s most preferred language in the 
> Accept-Language header on the initial request.
> Blink component
>
> Privacy>Fingerprinting 
> 
>
> Motivation
>
>
> The Accept-Language header is a source of passive fingerprinting 
> information about users, as it can contain a high degree of entropy, 
> particularly if the user has many accepted languages. 
>
> Chrome (and other browsers) send a full list of the user's accepted 
> languages on every HTTP request via the Accept-Language header. While some 
> sites use this information for content negotiation, servers can also 
> passively capture this information without the user's awareness, to 
> fingerprint a user.  
>
> We propose to only send a single language—one of the user’s preferred 
> languages determined by the language negotiation process—in the 
> Accept-Language request header by default. Here’s what that would look like 
> when a user tries to access https://example.com:
>
> Get / HTTP/1.1
>
> Host: example.com
>
> Accept-Language: en
>
> HTTP/1.1 200 OK
>
> Content-Language: en
>
> Vary: Accept-Language
>
> Variants: Accept-Language=(en)
>
> As the response shows, in addition to the Content-Language in the response 
> header, sites will respond with a Variants 
>  
> header (support for which will be prototyped as part of this intent), the 
> value of which includes all the languages the site supports. Browsers can 
> use the Variants header to do language negotiation if sites offer a page in 
> a language that doesn’t match the user's preferred languages. Initial 
> public proposal
>
>
> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>  
>
>
> TAG review
>
> To be filed.
>
> RisksInteroperability and Compatibility
>
> We are reducing the number of languages sent in the Accept-Language header 
> to protect user privacy. The main source of risk is that sites rely on all 
> or part of a user’s preferred languages instead of the most preferred 
> language. We feel it’s important to minimize the breakage of the features 
> depending on Accept-Language as much as possible, to maintain stability of 
> the web ecosystem. To mitigate the risk of this change, we intend to 
> gradually roll it out via Finch configuration and keep monitoring health 
> metrics and bug reports from the community. 
>
> Gecko: No signals
>
> WebKit: No signals
>
> Web developers:  See the explainer for details.
> Debuggability
>
> No special DevTools support needed.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> It will be.
>
> Flag name
>
> reduce-accept-language
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905
>
>
> *Launch bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484  
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5188040623390720 
> 
>
>
>

-- 
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/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org.

[blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

NOTES: This intent won't implement Variants in HTTP cache behavior. It only 
focus on taking advantage of the definition of Section 2 
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>
 as 
a Support-Languages header in this case

On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 Victor Tan wrote:

> Contact emails
>
> victor...@chromium.org, abe...@chromium.org
>
> Explainer
>
>
> https://github.com/Tanych/accept-language 
> Specification
>
> Variants header: 
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>
> Summary
>
> Support the HTTP Variants header and implement the reduction of 
> information that could be used for fingerprinting in the Accept-Language 
> header, so that Chrome only sends the user’s most preferred language in the 
> Accept-Language header on the initial request.
> Blink component
>
> Privacy>Fingerprinting 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>
> Motivation
>
>
> The Accept-Language header is a source of passive fingerprinting 
> information about users, as it can contain a high degree of entropy, 
> particularly if the user has many accepted languages. 
>
> Chrome (and other browsers) send a full list of the user's accepted 
> languages on every HTTP request via the Accept-Language header. While some 
> sites use this information for content negotiation, servers can also 
> passively capture this information without the user's awareness, to 
> fingerprint a user.  
>
> We propose to only send a single language—one of the user’s preferred 
> languages determined by the language negotiation process—in the 
> Accept-Language request header by default. Here’s what that would look like 
> when a user tries to access https://example.com:
>
> Get / HTTP/1.1
>
> Host: example.com
>
> Accept-Language: en
>
> HTTP/1.1 200 OK
>
> Content-Language: en
>
> Vary: Accept-Language
>
> Variants: Accept-Language=(en)
>
> As the response shows, in addition to the Content-Language in the response 
> header, sites will respond with a Variants 
> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06> 
> header (support for which will be prototyped as part of this intent), the 
> value of which includes all the languages the site supports. Browsers can 
> use the Variants header to do language negotiation if sites offer a page in 
> a language that doesn’t match the user's preferred languages. Initial 
> public proposal
>
>
> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>  
>
>
> TAG review
>
> To be filed.
>
> RisksInteroperability and Compatibility
>
> We are reducing the number of languages sent in the Accept-Language header 
> to protect user privacy. The main source of risk is that sites rely on all 
> or part of a user’s preferred languages instead of the most preferred 
> language. We feel it’s important to minimize the breakage of the features 
> depending on Accept-Language as much as possible, to maintain stability of 
> the web ecosystem. To mitigate the risk of this change, we intend to 
> gradually roll it out via Finch configuration and keep monitoring health 
> metrics and bug reports from the community. 
>
> Gecko: No signals
>
> WebKit: No signals
>
> Web developers:  See the explainer for details.
> Debuggability
>
> No special DevTools support needed.
>
> Is this feature fully tested by web-platform-tests 
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?
>
> It will be.
>
> Flag name
>
> reduce-accept-language
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905
>
>
> *Launch bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484  
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5188040623390720 
> <https://chromestatus.com/feature/5188040623390720#details>
>
>
>

-- 
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/ec45210f-9d45-4a37-8bc6-989f4ba7f7f6n%40chromium.org.

[blink-dev] Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

Contact emails

victor...@chromium.org, abe...@chromium.org

Explainer


https://github.com/Tanych/accept-language
Specification

Variants header:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

Summary

Support the HTTP Variants header and implement the reduction of information
that could be used for fingerprinting in the Accept-Language header, so
that Chrome only sends the user’s most preferred language in the
Accept-Language header on the initial request.
Blink component

Privacy>Fingerprinting


Motivation


The Accept-Language header is a source of passive fingerprinting
information about users, as it can contain a high degree of entropy,
particularly if the user has many accepted languages.

Chrome (and other browsers) send a full list of the user's accepted
languages on every HTTP request via the Accept-Language header. While some
sites use this information for content negotiation, servers can also
passively capture this information without the user's awareness, to
fingerprint a user.

We propose to only send a single language—one of the user’s preferred
languages determined by the language negotiation process—in the
Accept-Language request header by default. Here’s what that would look like
when a user tries to access https://example.com:

Get / HTTP/1.1

Host: example.com

Accept-Language: en

HTTP/1.1 200 OK

Content-Language: en

Vary: Accept-Language

Variants: Accept-Language=(en)

As the response shows, in addition to the Content-Language in the response
header, sites will respond with a Variants

header (support for which will be prototyped as part of this intent), the
value of which includes all the languages the site supports. Browsers can
use the Variants header to do language negotiation if sites offer a page in
a language that doesn’t match the user's preferred languages. Initial
public proposal

https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835



TAG review

To be filed.

RisksInteroperability and Compatibility

We are reducing the number of languages sent in the Accept-Language header
to protect user privacy. The main source of risk is that sites rely on all
or part of a user’s preferred languages instead of the most preferred
language. We feel it’s important to minimize the breakage of the features
depending on Accept-Language as much as possible, to maintain stability of
the web ecosystem. To mitigate the risk of this change, we intend to
gradually roll it out via Finch configuration and keep monitoring health
metrics and bug reports from the community.

Gecko: No signals

WebKit: No signals

Web developers:  See the explainer for details.
Debuggability

No special DevTools support needed.

Is this feature fully tested by web-platform-tests

?

It will be.

Flag name

reduce-accept-language


Requires code in //chrome?

False

Tracking bug

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


*Launch bug*
https://bugs.chromium.org/p/chromium/issues/detail?id=1307484

*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5188040623390720


-- 
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/CAJh4P7EyEjZJjTQQg4_sAargPes-t8kSHtSQBZ7WQV6ikFveWw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Sec-CH-UA-Full-Version-List user-agent client hint

[Victor Tan]

Hi,
Could you also review and ship this in blink-dev? Thanks!

Bests,
Victor

On Monday, November 22, 2021 at 11:39:47 AM UTC-5 Victor Tan wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org
>
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list
>
>
> Summary
>
> The Sec-CH-UA-Full-Version-List request header field gives a server 
> information about the full version for each brand in its brands list.
>
>
> Blink component
>
> Privacy>Fingerprinting 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>
>
> Motivation
>
> As raised in UA-CH Issue 196 
> <https://github.com/WICG/ua-client-hints/issues/196>, 
> Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary 
> brand in the brand list 
> <https://wicg.github.io/ua-client-hints/#user-agent-brands>, especially 
> for embedders. In order to prevent classes of bugs where a site might think 
> the fictional “Hamburger” browser is not up to date (because its version 
> scheme is different, and lower than Chromium’s), we propose to expose the 
> full version of each brand in the brand list, by requesting this new client 
> hint.
>
> Here’s what that would look like:
>
> Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium"; 
> v="92.0.4515.131", "?Not:A Browser"; v="3.1.2.0"
>
> Eventually, it will make sense to deprecate and remove 
> Sec-CH-UA-Full-Version 
> <https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version> 
> (assuming usage allows us to do so). But we do not intend to do that until 
> we ship its replacement.
>
>
> Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
>
> TAG review status
>
> Pending (there’s a pre-existing review, and this hint came up in the 
> review process as feedback from other browsers, so the TAG is aware of it).
>
>
> RisksInteroperability and CompatibilityThis is a new hint, so it should 
> not create compatibility issues.
>
>   Edge: This hint was added to solve a bug (maybe a feature request?) 
> <https://github.com/WICG/ua-client-hints/issues/196> by Edge folks.
>
> Gecko: Non-harmful (
> https://mozilla.github.io/standards-positions/#ua-client-hints)
>
> WebKit: Requested through email 
> <https://lists.webkit.org/pipermail/webkit-dev/2021-November/032047.html>
>
> Web developers: No signals
> Debuggability
>
> No special DevTools support needed. It should just work™.
>
>
> Is this feature fully tested by web-platform-tests 
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?
>
> Yes. https://chromium-review.googlesource.com/c/chromium/src/+/3256910 
>
>
> Flag name
>
> UserAgentClientHintFullVersionList
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1249246
>
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1260418
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5703317813460992
>
>

-- 
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/0695b943-d6d9-462d-ad3c-b8de537ee9b5n%40chromium.org.

[blink-dev] Intent to Ship: Sec-CH-UA-Full-Version-List user-agent client hint

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org


Specification

https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list


Summary

The Sec-CH-UA-Full-Version-List request header field gives a server
information about the full version for each brand in its brands list.


Blink component

Privacy>Fingerprinting



Motivation

As raised in UA-CH Issue 196
,
Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary
brand in the brand list
, especially for
embedders. In order to prevent classes of bugs where a site might think the
fictional “Hamburger” browser is not up to date (because its version scheme
is different, and lower than Chromium’s), we propose to expose the full
version of each brand in the brand list, by requesting this new client hint.

Here’s what that would look like:

Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium";
v="92.0.4515.131", "?Not:A Browser"; v="3.1.2.0"

Eventually, it will make sense to deprecate and remove
Sec-CH-UA-Full-Version
 (assuming
usage allows us to do so). But we do not intend to do that until we ship
its replacement.


Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196

TAG review

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


TAG review status

Pending (there’s a pre-existing review, and this hint came up in the review
process as feedback from other browsers, so the TAG is aware of it).


RisksInteroperability and CompatibilityThis is a new hint, so it should not
create compatibility issues.

  Edge: This hint was added to solve a bug (maybe a feature request?)
 by Edge folks.

Gecko: Non-harmful (
https://mozilla.github.io/standards-positions/#ua-client-hints)

WebKit: Requested through email


Web developers: No signals
Debuggability

No special DevTools support needed. It should just work™.


Is this feature fully tested by web-platform-tests

?

Yes. https://chromium-review.googlesource.com/c/chromium/src/+/3256910


Flag name

UserAgentClientHintFullVersionList

Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5703317813460992

-- 
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/CAJh4P7FdCmHAA-8b1CH_So%3D2Fur2dZO8SKNetWmEetQ1KcP9_A%40mail.gmail.com.

[blink-dev] Intent to Prototype: Sec-CH-UA-Full-Version-List user-agent client hint

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org

Specification

https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list

Summary

The Sec-CH-UA-Full-Version-List request header field gives a server
information about the full version for each brand in its brands list.

Blink component

Privacy>Fingerprinting


Motivation

As raised in UA-CH Issue 196
,
Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary
brand in the brand list
, especially for
embedders. In order to prevent classes of bugs where a site might think the
fictional “Hamburger” browser is not up to date (because its version scheme
is different, and lower than Chromium’s), we propose to expose the full
version of each brand in the brand list, by requesting this new client hint.

Here’s what that would look like:

Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium";
v="92.0.4515.131", "?Not:Your Browser"; v="3.1.2.0"

Eventually, it will make sense to deprecate and remove
Sec-CH-UA-Full-Version
 (assuming
usage allows us to do so). But we do not intend to do that until we ship
its replacement.

Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196
TAG review

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

TAG review status

Pending (there’s a pre-existing review, but this hint came up in the review
process as feedback from other browsers)

RisksInteroperability and CompatibilityThis is a new hint, so it should not
create compatibility issues.

Gecko: Non-harmful (
https://mozilla.github.io/standards-positions/#ua-client-hints)

WebKit: No signal

Web developers: No signals
Debuggability

No special DevTools support needed. It should just work™.

Is this feature fully tested by web-platform-tests

?

It will be.

Flag name

UserAgentClientHintFullVersionList

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5703317813460992

-- 
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/CAJh4P7G949yrZzeYERgHgZXT0k_WJKfm3j8%2BaLaitzWgJSZFFQ%40mail.gmail.com.