Have you proposed that a standards body adopt this into a working group of some sort? Especially since Safari is doing something similar, it seems like the WHATWG might be willing to adopt this into the Fetch standard.
I'm also somewhat concerned about the internationalization concerns expressed in https://github.com/explainers-by-googlers/reduce-accept-language/issues/10. I couldn't get `curl` to reproduce the content negotiation claimed in https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2093906527 (e.g. Wikipedia seems to react to navigator.language and not Accept-Language), but it'd be good to at least get all the Googlers on that thread to agree on the facts about website behavior. Jeffrey On Tue, Apr 1, 2025 at 7:56 AM Victor Tan <victor...@chromium.org> wrote: > Contact emails > > victor...@chromium.org, miketa...@chromium.org > > Explainer > > https://github.com/explainers-by-googlers/reduce-accept-language > > TAG reviewTo be filedSummary > > 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. Instead of sending every user's language preferences via > Accept-Language, we propose to 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”). To minimize compatibility risks, this > intent only covers HTTP. We plan to reduce the related navigator.languages > JS getters in the future. > > We would like to start rolling out in M136. > > 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, > rather than remove the header or change value format in the header. Most > existing Accept-Language detection code should continue to work. The 1% > stable experiment from M128 to M132 inclusive showed that there is no > interesting movement on crashes, latency metrics, and manually language > translation metrics. Also, we didn’t receive compatibility bug reports. Our > study of the top 10k sites provided by Tranco shows that few sites actually > use the Accept-Language header. For subresources, we found no impact to CSS > or images. For JavaScripts, there are only a few sites that have different > locale bundles loaded when requesting with different Accept-Language. Only > a few embedded iframes (~30 unique origins, ~2.6% of all unique subresource > origins) have changed content based on a different requesting > Accept-Language header. > > For the interoperability issues, it might create inconsistencies between > browsers for sites using the Accept-Language header, since some provide a > user's full Accept-Language list, while others only provide the user's > primary language. Another signal is that the Chrome incognito model already > reduces the Accept-Language header and JS interface navigator.languages to > a single language, and Safari ships this same behavior. > > 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: No signals, but some concerns have been raised about the > client-side language negotiation implications ( > https://github.com/explainers-by-googlers/reduce-accept-language/issues/10 > ). However, for this launch, we intend to reduce only the Accept-Language > HTTP header. Client-side language negotiation may not be impacted at this > phase, since tools use navigator.languages for language negotiation. > Additionally, most existing tools have a fallback language if they do not > find a language they support. > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > None > > 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, for WPT, we have tests for JS getter > and it has limits to set different users’ language preference to cover all > the test cases in the Accept-Language HTTP header regarding the language > negotiation). But otherwise, the simple case is covered. > > Flag name on chrome://flags > > #reduce-accept-language-http > > Finch Flag name > > kReduceAcceptLanguageHTTP > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HisRSZYAgG99BpAR_Kjwxx26czQx05NqH-apXdSJo_3g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HisRSZYAgG99BpAR_Kjwxx26czQx05NqH-apXdSJo_3g%40mail.gmail.com?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXmME4fWX8ue1np1npAW_b3NpbySYNPme3Nh4ZWWXPHR3g%40mail.gmail.com.
