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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>

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
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06>
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
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
?

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
<https://chromestatus.com/feature/5188040623390720#details>

-- 
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/CAJh4P7EyEjZJjTQQg4_sAargPes-t8kSHtSQBZ7WQV6ikFveWw%40mail.gmail.com.

Reply via email to