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.
On Monday, May 23, 2022 at 5:37:17 PM UTC-4 eri...@microsoft.com wrote: > 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 vict...@chromium.org wrote: > >> 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 >> <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/f176bb27-e4f5-4881-8d06-1169f94c6183n%40chromium.org.
