1. We will start limit navigator.languages to return only a single language. we know it might cause impacts in some cases. Also, will keep tracking how it works in the ecosystem. 2. Users can only know one language, in this case, which makes service confused. We will monitor how the performance works when introduce the resending. 3. thanks for your suggestion. will double check with team to add options for users to determine their language privacy in this case.
On Monday, May 23, 2022 at 10:35:04 AM UTC-4 han.g...@gmail.com wrote: > 1. What about pure client side i18n? > If `navigator.languages` limits to an array which has only one language, > client can't select the best language if the first doesn't match. > > 2. Could it send two languages in Accept-Language header by default (not > one)? > I guest a lot of people can understand one or two languages, but few > people can understand more than 4 languages. To trade off > performance(resending request) and privacy, maybe sending two languages in > Accept-Language by default is better. > > 3. Could browser add a setting (in chrome://settings/privacy) for users to > confirm what information is user's privacy? > What is personal privacy actually varies from person to person. For > example, for me, I don't care others know what languages I can speak. If a > user check "languages is not in his/her privacy scope", browser can send > all languages in Accept-Language header. If the user select "languages I > can understand are my privacy", browser could even not send any language > (no Accept-Language). > > On Thursday, May 19, 2022 at 10:20:29 PM UTC+8 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/7fd3ef4c-5a4c-4010-91f8-99b62537976an%40chromium.org.
