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

235 views
Skip to first unread message

Victor Tan

unread,
May 19, 2022, 10:20:29 AMMay 19
to blin...@chromium.org

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.


Risks

Interoperability 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


Victor Tan

unread,
May 20, 2022, 12:05:47 PMMay 20
to blink-dev, 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

Victor Tan

unread,
May 20, 2022, 1:11:09 PMMay 20
to blink-dev, vict...@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 .

Harald Alvestrand

unread,
May 21, 2022, 8:38:47 AMMay 21
to Victor Tan, blink-dev, vict...@chromium.org
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?

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

Victor Tan

unread,
May 22, 2022, 11:31:53 AMMay 22
to blink-dev, Harald Alvestrand, blink-dev, Victor Tan, 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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Harald Alvestrand

unread,
May 22, 2022, 12:11:23 PMMay 22
to Victor Tan, blink-dev, Victor Tan
So one extra round trip per page?


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Victor Tan

unread,
May 22, 2022, 12:15:04 PMMay 22
to blink-dev, Harald Alvestrand, blink-dev, Victor Tan, 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.  

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Harald Alvestrand

unread,
May 22, 2022, 2:08:02 PMMay 22
to Victor Tan, blink-dev, Victor Tan
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.



To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Victor Tan

unread,
May 23, 2022, 10:05:07 AMMay 23
to blink-dev, Harald Alvestrand, blink-dev, Victor Tan, Victor Tan
Yea, we definitely will collect metrics on those performance. thanks for your comments. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Guokai Han

unread,
May 23, 2022, 10:35:04 AMMay 23
to blink-dev, vict...@chromium.org
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).

Eric Lawrence

unread,
May 23, 2022, 5:37:17 PMMay 23
to blink-dev, vict...@chromium.org
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)

Victor Tan

unread,
May 23, 2022, 8:31:24 PMMay 23
to blink-dev, han.g...@gmail.com, 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.  

Victor Tan

unread,
May 23, 2022, 8:42:20 PMMay 23
to blink-dev, eri...@microsoft.com, 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. 

Brian Birtles

unread,
May 24, 2022, 8:00:41 PMMay 24
to blink-dev, vict...@chromium.org, han.g...@gmail.com
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).
 

Daniel Bratell

unread,
May 25, 2022, 11:25:24 AMMay 25
to Victor Tan, blink-dev, Harald Alvestrand, Victor Tan

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1bef704-a140-4271-923c-59bb69861f32n%40chromium.org.

Brian Birtles

unread,
May 25, 2022, 6:45:38 PMMay 25
to blink-dev, Daniel Bratell, Harald Alvestrand, Victor Tan, vict...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages