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 [email protected] wrote: > Contact emails > > [email protected], [email protected] > > 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 [email protected]. 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.
