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 
>>  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 
>> . Let me or your spec 
>> mentor  
>> 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 
>>> 
>>>
>>> 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 
>>> 

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
>  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
> . Let me or your spec mentor
>  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
>> 
>>
>> 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 

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

[Jeffrey Yasskin]

I see that your Chrome Status entry
 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
. Let me or your spec mentor
 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
> 
>
> 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 

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

[Will Dillard]

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

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

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

[Yoav Weiss]

LGTM to experiment M109-M114

On Mon, Oct 31, 2022 at 4:02 PM Victor Tan  wrote:

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

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

 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 

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

[Yoav Weiss]

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

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

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

[Yoav Weiss]

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

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

 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
 

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

[Yoav Weiss]

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

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

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

[Yoav Weiss]

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