So one extra round trip per page?
On Sun, May 22, 2022 at 5:31 PM Victor Tan <victor...@chromium.org> wrote: > Hi Harald, > The browser will do language negotiation with resend the request (only > happen once) with accept-language:en to get a result with English page. > > Victor > > On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote: > >> 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/CAOqqYVH1VX81nmqN65PCj%3DtVBbKGnKzLTDGxzunXnMnmB5jnpA%40mail.gmail.com.
