Intent to Implement: `Sec-CH-Lang` Client Hint.
104 views
Skip to first unread message
Mike West
Jan 22, 2019, 5:23:22 AM1/22/19
to blink-dev
# Contact emails
# Spec
The `Sec-CH-Lang` client hint aims to deprecate and replace the `Accept-Languages` header in order to reduce the passive fingerprinting surface we expose via HTTP requests.
# Motivation
User agents specify a set of languages as part of each HTTP request via the `Accept-Languages` header. This header's value is critical for some kinds of content negotiation, ideally allowing servers to give each user content in a language they prefer. For example, my user agent sends a header along the lines of:
```
Accept-Language: en-US,en;q=0.9,de;q=0.8
```
This shows that I prefer content in English, but accept content in German as well. That's great for a few important use cases, but exposes quite a bit of entropy to the web at large, even though only a small subset of sites I visit will actually use the information to improve my experience.
I'd suggest that we deprecate that header, and move to an opt-in model which will reveal my language preferences to the specific sites that declare they can do something useful with it, while keeping them off the wire for the rest.
# Interoperability risk
User agents specify a set of languages as part of each HTTP request via the `Accept-Languages` header. This header's value is critical for some kinds of content negotiation, ideally allowing servers to give each user content in a language they prefer. For example, my user agent sends a header along the lines of:
```
Accept-Language: en-US,en;q=0.9,de;q=0.8
```
This shows that I prefer content in English, but accept content in German as well. That's great for a few important use cases, but exposes quite a bit of entropy to the web at large, even though only a small subset of sites I visit will actually use the information to improve my experience.
I'd suggest that we deprecate that header, and move to an opt-in model which will reveal my language preferences to the specific sites that declare they can do something useful with it, while keeping them off the wire for the rest.
# Interoperability risk
At TPAC, we had an interesting discussion with folks from Brave, Safari, Edge, and others in the room. I think it's fair to say that folks are skeptical of client hints generally, but positive on the potential of using the infrastructure to reduce fingerprinting surface via these specific hints.
* Edge: No public signals, but see above.
* Safari: Mixed signals. See above.
* Firefox: Mixed signals. Mozilla folks weren't in the room at TPAC, but we have other evidence to point to. They consider Client Hints generally to be "non-harmful", but I've gotten positive feedback on this hints in particular (https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0176.html, for instance).
# Compatibility risk
Introducing this hint in itself won't affect any page, as it's purely opt-in. In the future, deprecating and removing `Accept-Languages` would force developers to shift their current approach to actively asking for language information, which might well have a compatibility impact for those sites that support language-based content negotiation.
# Ongoing technical constraints
None.
# Will this feature be supported on all six Blink platforms
Yes.
# OWP launch tracking bug
# Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5901445979176960
# Requesting approval to ship?
No
Thanks!
-mike
Reply all
Reply to author
Forward
0 new messages