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

[Victor Tan]

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

https://chromestatus.com/feature/5188040623390720

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.