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?
fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev < blink-dev@chromium.org>: > 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 > <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2> > . > > On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 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/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOqqYVGq65XSvPh%3DBcJy8W2TpSk1cFjv-pRrVgdMSJ8BdVb4kA%40mail.gmail.com.
