Reducing fingerprinting risk of Accept-Language browser header

A new proposal to reduce the granularity of the Accept-Language header aims to decrease web fingerprinting surface to improve user privacy and reduce risks.

Problem

Today, when we connect to a website, the browser sends an Accept-Languageheader listing all of our preferred languages — often including specific locales like en-US, fr-CA, de-DE. This helps in unique identification (fingerprinting) of users, with the potential to track users on the web. Accept-Language contributes measurable identification signal to browser fingerprints—changing only the language turned more than 60% of non-unique fingerprints into unique ones.

Solution

The proposal changes today's behavior by sending only the user's top language preference in the header. Instead of revealing a detailed list, the browser would just say "en", for example, and leave it to the website to respond accordingly. If the content doesn’t match the user’s language, the browser can retry the request using a fallback from the site's advertised supported languages (Avail-Language). This moves language negotiation logic into the browser.

Attack

A site could lie about which languages it supports in order to trigger retries and slowly infer the user's full language list. One way to mitigate this risk is rate limiting. So reducing the frequency of checking the language. So the trick is to balance it properly in a way that it won't be easy to defeat.