Reduce Accept-Language

[Tanych]

WebKittens

No response

Title of the spec

Reduce languages in Accept-Language

URL to the spec

https://github.com/Tanych/accept-language/blob/main/README.md

URL to the spec's repository

https://github.com/Tanych/accept-language

Issue Tracker URL

No response

Explainer URL

https://github.com/Tanych/accept-language/blob/main/README.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#1014

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Most 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. Reduce Accept-Language intends 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.

Also, Safari currently only sends single language over the Accept-Language and JS getter navigator.languages.

[annevk]

Could you clarify what you mean with this statement

the user’s most preferred language after language negotiation

? Thanks!

Overall I get the impression you'd be aligning with WebKit on this, but I'd like to make sure I understand correctly.

[Tanych]

basically the server can provide the support language on the HTTP response header, and browser take responsible to find the best language match both server supported language and user accept-language. you can find more details example on https://github.com/Tanych/accept-language/blob/main/README.md#language-negotiation.

[miketaylr]

Aside from that, yes, we would be aligning with WebKit.

[annevk]

Currently as I understand it Safari's networking stack sends up to two languages (two when the user's preferred language from the system's language, otherwise just one).

It seems in your proposal you introduce a cost for the website to obtain the second language, which seems like a nice property, but it comes with the drawback that it won't work on any existing website.

It's not entirely clear why that is the correct trade-off given that the additional language will be exposed to an active attacker and comes with a worse experience on existing websites.