Restricting accept-language to 'common combinations' is fundamentally at odds with personal agency. This can break the web for people with uncommon combinations of accepted languages. This change would effectively discriminate against these people by denying them access to websites in their preferred languages that previously worked just fine.
Language preferences should not be ignored just because they're unique, and therefore trackable. On Wednesday, August 7, 2024 at 8:41:48 AM UTC-7 vict...@chromium.org wrote: Email Body Contact emails vict...@chromium.org, mike...@chromium.org Explainer https://github.com/explainers-by-googlers/reduce-accept-language TAG reviewTo be filed. Summary In order to reduce the amount of passively available entropy in HTTP requests, we want to reduce the amount of information the Accept-Language header exposes in HTTP requests and JS interface navigator.languages. Instead of sending every user's language preferences via Accept-Language, we only send the user’s most preferred language after language negotiation in the Accept-Language header. For the HTTP Accept-Language header, we will potentially expand a base language based on the language-region pair (e.g., if the preferred language is “en-US” we will expand to “en-US, en;q=0.9”). The JS getter navigator.languages returns the same value as navigator.language. We would like to run a Finch 1% experiment from M128 to M131 inclusive. Blink component Privacy>Fingerprinting <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting> Risks Interoperability and Compatibility The compatibility risk is relatively low for most users since we're planning to reduce the amount of information in the Accept-Language header and navigator.languages, rather than remove the header or change value format in the header. Most existing Accept-Language detection code should continue to work. This experiment should help us validate this assumption and identify corner cases. As for interoperability, for multilingual sites to rely on the Accept-Language, developers would need to depend on a user's full Accept-Language list for some browsers and a primary user's Accept-Language for others. Another signal is that the Chrome incognito model already reduced the Accept-Language header and JS interface navigator.languages to one language, and Safari ships this behavior for many users today. Gecko: Pending (https://github.com/mozilla/standards-positions/issues/1014) WebKit: Shipped (https://github.com/WebKit/standards-positions/issues/338) Safari already reduced the Accept-Language to a single language in most cases. Web developers: Some web developers are concerned about the client-side language negotiation implications ( https://github.com/Tanych/accept-language/issues/10). Experiment Goals The goal of this experiment is to ensure web compatibility with our proposed changes. Developers can also test how reducing the Accept-Language request header and the JS getter navigator.languages will affect their systems via the chrome://flags/#reduce-accept-language flag, especially to understand the impact on client side language negotiation via navigator.languages. We will be relying heavily on user and developer feedback to identify where breakage occurs, or where use cases are not accounted for, especially for multilingual sites depending on the Accept-Language header, and navigator.languages. Experiment Risks There are some risks, as many multilingual sites have come to rely on the value in Accept-Language header and JS interfaces navigator.languages to send the right representation pages to the user. Site breakage can take many forms, both obvious and non-obvious - which is the point of running this experiment. If we are confident the design is largely web-compatible, we will request a Deprecation Trial for sites to be able to have time to migrate or modify how their sites work. Debuggability Both of these settings and the resulting network requests are visible in DevTools. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No (All but WebView) Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? No (We fully test in browser_tests, WPT has limits to cover all the test cases in the Accept-Language header). Flag name on chrome://flags #reduce-accept-language Finch Flag name kReduceAcceptLanguage Tracking bug https://issues.chromium.org/issues/40218547 Launch bug https://launch.corp.google.com/launch/4317282 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/9480bbd1-4c35-4e9c-9c08-79d87b90b45bn%40chromium.org.
