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.