[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 

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

[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

[Guokai Han]

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

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

['Eric Lawrence' via blink-dev]

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 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f065a422-368d-402f-bb9e-6d0853111eaan%40chromium.org.

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

[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 
https://group

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

[Brian Birtles]

2022年5月24日火曜日 9:31:24 UTC+9 vict...@chromium.org:

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


It would be good to see a concrete proposal for this since, unlike the HTTP 
header case, there doesn't appear to be a proposed workaround. For apps 
that perform purely client-side language switching, losing this information 
would be a significant regression. I imagine there are possible workarounds 
that could be introduced such as introducing a function that takes a list 
of available languages and returns the preferred one (with suitable 
restrictions on the function to prevent abuse).
 

-- 
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/096ea4b3-0e17-455b-b91a-b13d641a86f7n%40chromium.org.

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

['Harald Alvestrand' via blink-dev]

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

-- 
You 

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

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

['Harald Alvestrand' via blink-dev]

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

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  
 
 .

 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 
> 

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

['Harald Alvestrand' via blink-dev]

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

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

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

[Daniel Bratell]

I am happy to see you working on reducing the fingerprinting surface on 
the web, and this seems like a worthwhile place get rid of some entropy. 
Though, just like some other comments here suggest, I also suspect that 
just a single language might not be enough.


There is a disparity between the languages that are primary languages 
for people on this planet, and the languages used for content on the 
web. The web has a dominance of languages that are shared by many, such 
as English, Chinese, Russian, Spanish and Persian. If someone's primary 
language is a smaller language they will face a couple of bad options:


1. Use a common second language as primary language, and miss out on 
content in the language they understand best.


2. Accept that they will get some default language on pages and hope 
that is one they can read.


3. Hope that every multi-language site they visit is rewritten to 
negotiate a language.


I think expanding from one to two languages will be enough to cover many 
of the use cases, and I don't think that will add much information 
(TBD). Here in Sweden, I expect a majority to have [sv, en] for 
instance, in Catalonia it might be [ca, es] and so on.


A compromise might be to always keep the first "common" language though 
it adds the problem of determining what is a "common" language.


I'm a bit concerned that this might cause issues that will be invisible 
for those that live entirely on the English speaking web so I hope you 
take care to avoid such biases.


/Daniel

On 2022-05-23 16:05, Victor Tan wrote:
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 :

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

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

[Brian Birtles]

2022年5月26日木曜日 0:25:24 UTC+9 Daniel Bratell:

> I think expanding from one to two languages will be enough to cover many 
> of the use cases, and I don't think that will add much information (TBD).
>
I'm skeptical about that, particularly because of different variants. e.g. 
for a site only available in Korean or Japanese, "en-AU, en-UK, en-US, en, 
ja, da" should still show Japanese content. Similarly for a user who 
understands various flavours of Chinese, followed by Japanese, but not 
English.

>

-- 
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/95b40315-e36d-4df7-ab30-0dafedd58e58n%40chromium.org.