Reduce Accept-Language

[Tanych]

Hi there TAG,

I'm requesting a TAG review of Reduce Accept-Language and the plan to reduce the information available in the Accept-Language HTTP header first, and then reduce related JS APIs navigator.languages in future phases.

Chrome (and other browsers) send all of the user's language preferences on every HTTP request via the Accept-Language header. The header's value contains a lot of entropy about the user that is sent to servers by default. We want to reduce the amount of information the Accept-Language header exposes in HTTP requests and JS interface navigator.languages. Instead of sending all user’s 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. The JS getter navigator.languages returns the same value as navigator.language.

• Explainer¹ (minimally containing user needs and example code):
  https://github.com/explainers-by-googlers/reduce-accept-language/blob/main/README.md
• Specification URL: N/A
• Tests:
  https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/navigator_language
• User research: N/A
• Security and Privacy self-review²: https://github.com/explainers-by-googlers/reduce-accept-language/blob/main/tag-security-privacy.md
• GitHub repo: https://github.com/explainers-by-googlers/reduce-accept-language
• Primary contacts (and their relationship to the specification):
  Victor Tan (@Tanych - editor)
  Mike Taylor(@miketaylr - editor)
• Organization(s)/project(s) driving the specification: Chromium
• This work is being funded by: Google
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
• Key pieces of multi-implementer support:
  • Mozilla comments: Reduce Accept-Language mozilla/standards-positions#1014
  • WebKit comments: Reduce Accept-Language WebKit/standards-positions#338
• Major unresolved issues with or opposition to this specification: some i18n concerns have been raised, but our experimental data doesn’t align with them: I18N objections to reducing accept-language explainers-by-googlers/reduce-accept-language#10
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  https://chromestatus.com/feature/5188040623390720

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We will consider starting roll-out in Chrome stable population 2025 Q2.
• The group where the work on this specification is currently being done: N/A
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): N/A

[aphillips]

In I18N's 2025-04-24 call, our WG agreed to raise this issue to 'needs-resolution', not because we support this proposal, but as a signal of our reasonably intense interest in the outcome here.

some i18n concerns have been raised, but our experimental data doesn’t align with them

I18N has not seen the "experimental data". Can a pointer be provided?

[yoavweiss]

I think this proposal is suboptimal and assumes users have a "main" language in which they want to consume all of their web content. I don't believe that's the case. I've written about it at some length.

[miketaylr]

I18N has not seen the "experimental data". Can a pointer be provided?

Not sure why the scare quotes (it's data from an experiment), but I can write up a summary and link it here.

I've written about it at some length.

Thanks for the reminder - I should write a few responses to this, a few things are incorrectly stated.

(note: things are a bit busy right now, so it may be a few weeks.)