Intent to Ship: Accept-Language Reduction (HTTP-only)

[Victor Tan]

Contact emails

vict...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/explainers-by-googlers/reduce-accept-language 

TAG review

To 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. 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

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?

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

[Jeffrey Yasskin]

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

--
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+...@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.

[Mike Taylor]

On 4/1/25 5:00 PM, Jeffrey Yasskin wrote:

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 think it may be possible to standardize the "only send one language" aspect, but not the rest (until other vendors express support). But my take on https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-language is that this is already covered. If approved to ship, we're happy to take on the work to move this to Fetch (I can also work on a PR if that's useful now).

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.

I appreciate the concerns raised, but I don't share them. Our experiments (and Safari's behavior) show that this change is web-compatible. Solving for navigator.languages may be trickier, but that's why we've split it out from the proposal.

[Vladimir Levin]

Can you file the various review gates as well?

 

TAG reviewTo be filed

Is this accurate?

 

[Victor Tan]

Hi,

Vladimir, Thanks for the reminder. I requested those review gates. For the TAG review, I will publish soon and link the issue here once it is published. 

Jeffrey, Thanks for raising this concern. We understand that some popular multilingual sites, based on our study, do indeed use the full language list in the HTTP header. Your concerned use case, in other words, highlights a privacy issue that this feature intends to mitigate. These multilingual sites typically support major popular languages. However, for users whose primary language is less common and therefore might not be supported by those sites, but whose second or third languages are more widely used, exposing the full language list in the HTTP header creates significant passive fingerprinting. This means these individuals could be easily identified. 

Hope this helps.

Thanks,

Victor

[Jeffrey Yasskin]

On Wed, Apr 2, 2025 at 8:36 AM Victor Tan <vict...@chromium.org> wrote:

Jeffrey, Thanks for raising this concern. We understand that some popular multilingual sites, based on our study, do indeed use the full language list in the HTTP header. Your concerned use case, in other words, highlights a privacy issue that this feature intends to mitigate. These multilingual sites typically support major popular languages. However, for users whose primary language is less common and therefore might not be supported by those sites, but whose second or third languages are more widely used, exposing the full language list in the HTTP header creates significant passive fingerprinting. This means these individuals could be easily identified.

It's certainly good to reduce how identifiable these people are, but not at the cost of making them read content in a worse language. Have any of these sites adopted Avail-Language to regain their localization? Is there a way to validate the theory that when we break localization, people know to file bugs? 

Of your tests, I think manual language translation is a useful signal. Evidence that very few sites used by multilingual users respond to Accept-Language would also help, but I'm not sure the top 10k sites are likely to be the sites used by multilingual users. 2.6% of embedded iframes changing behavior seems like a negative signal, and Safari behavior, crashes, and latency don't seem very relevant. It'd be really nice to know what percent of page loads, by people who've configured multiple languages, change their HTTP response after this Chromium change.

Jeffrey

[Victor Tan]

During the 1% stable experiment period, I don't think those sites adopted Avail-Language. 

For now, we can keep monitoring any significant changes over the translation metrics and feature related metrics. 

2.6% embedded iframes changing means they change content with different Accept-Language, it includes sites they actually only care about the first language.  

Bests,

Victor

[Victor Tan]

TAG review issue open: https://github.com/w3ctag/design-reviews/issues/1078 

Victor

[Peter Beverloo]

Hi Victor - you write that the feature is supported on all of Blink's platforms but WebView: is there a plan to follow up and avoid a more permanent divergence in behaviour?

Thanks,

Peter

--

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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/35bf986c-e830-4265-8621-c1a24a70ce43n%40chromium.org.

[Mike Taylor]

We do intend to follow suit there once we learn we can ship this and its compatible with the web. It seems nice to separate web compat problems from app compat problems, if we can.

[Peter Beverloo]

Agreed, and thank you for iterating on this. If this is launching behind a Finch flag then we'd be happy to help with an initial assessment too :)

Thanks,

Peter

[Victor Tan]

Hi Peter,

I don't think we currently support the feature on WebView even if we turn on the finch flag. 

WebView might work a little differently, there is some work to support this feature on WebView. We can start the work in the near future. 

Victor

[Mike Taylor]

Also, thanks for the offer to help with the appcompat assessment - let's connect off-list to discuss that.

[Frank Yung-Fong Tang]

> Safari already reduced the Accept-Language to a single language in most cases.

If my understanding of the English is correct:

This mean, right now, in some cases,  Safari does NOT reduced the Accept-Language to a single language, right?

Please read https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2093927039, the claim that "safari only contains one language" is incorrect when I check last May. Please correct me if Apple change that after May 2024.

Then., we should understand why Apple does NOT reduce to only one language for those cases?

In https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2098949098

I listed the following regions which should have higher impact by this change:

Tier 1: High Importance India, South Africa, Singapore, Switzerland
Tier 2: Moderate Importance Canada, Belgium, Malaysia, Nigeria

I think we need to be careful about undercoverage bias and sampling bias while analysis the impact of this change

https://www.scribbr.com/research-bias/undercoverage-bias/
https://www.scribbr.com/research-bias/sampling-bias

> HTTP-only

Does this mean you are not proposing to ship this to HTTPS?

Regards,

Frank

[Shane Carr]

Hi, I'm here to note that the concerns from the i18n perspective, as listed on GitHub, have not yet been addressed. I look forward to productive dialogue. In the mean time, please do not ship this.

[Mike Taylor]

On 4/9/25 3:51 PM, Frank Yung-Fong Tang wrote:

> Safari already reduced the Accept-Language to a single language in most cases.

If my understanding of the English is correct:

This mean, right now, in some cases,  Safari does NOT reduced the Accept-Language to a single language, right?

Please read https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2093927039, the claim that "safari only contains one language" is incorrect when I check last May. Please correct me if Apple change that after May 2024.

Then., we should understand why Apple does NOT reduce to only one language for those cases?

Yes, we would love to have more info on this, and would be happy to align with it - maybe that's a better outcome. I have asked for more information at https://github.com/WebKit/standards-positions/issues/338#issuecomment-2791172271.

In https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2098949098

I listed the following regions which should have higher impact by this change:

Tier 1: High Importance India, South Africa, Singapore, Switzerland
Tier 2: Moderate Importance Canada, Belgium, Malaysia, Nigeria

I think we need to be careful about undercoverage bias and sampling bias while analysis the impact of this change

https://www.scribbr.com/research-bias/undercoverage-bias/
https://www.scribbr.com/research-bias/sampling-bias

> HTTP-only

Does this mean you are not proposing to ship this to HTTPS?

No, this is just shorthand for not touching the JS APIs, but only the Accept-Language header sent over HTTP (or HTTPS).