[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] Re: Intent to Experiment: Reduce Accept-Language Origin Trial

[Mike Taylor]

Hi Brian,

Feedback as issues opened against 
https://github.com/Tanych/accept-language would be most welcome.


later,
Mike

On 10/31/22 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

Dochttps://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, 

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

[Brian Birtles]

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