From f32ef12c9674b4cd1e0224751bafd78b89c2c9f2 Mon Sep 17 00:00:00 2001 From: Mike West Date: Tue, 6 Nov 2018 10:41:28 +0100 Subject: [PATCH] 'Sec-CH-' prefix. --- README.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 85d813e..53e4a40 100644 --- a/README.md +++ b/README.md @@ -38,12 +38,12 @@ accomplish this as follows: to something genericly appropriate (perhaps based normal language preferences for the user's rough, IP-based geolocation), and eventually removing it entirely. -2. Browsers should introduce a new `Lang` Client Hint header field, representing the users' +2. Browsers should introduce a new `Sec-CH-Lang` header field, representing the users' language preferences. This would be a [Structured Header][2] whose value is a flat list of language codes in the users' preferred order. For example: ```http - Lang: "en-US", "en", "de" + Sec-CH-Lang: "en-US", "en", "de" ``` 3. Browsers should restrict the `navigator.language` and `navigator.languages` APIs to secure @@ -67,7 +67,7 @@ accomplish this as follows: If the server absolutely requires language information to make a reasonable decision about what data to send to the user, it can do so by sending an `Accept-CH` header along with a 302 response, -causing another navigation request, which will include the `Lang` header. +causing another navigation request, which will include the `Sec-CH-Lang` header. ## Should we include the `q` weighting? @@ -84,3 +84,11 @@ Right. There are more than a few open PRs: * HTML integration of Accept-CH-Lifetime and the ACHL cache: [whatwg/HTML#3774](https://github.com/whatwg/html/issues/3774) * Adding new CH features to the CH list in Fetch: [whatwg/fetch#725](https://github.com/whatwg/fetch/issues/725) * Other PRs for adding the Feature Policy 3rd party opt-in: [whatwg/fetch#811](https://github.com/whatwg/fetch/issues/811) and [wicg/feature-folicy#220](https://github.com/wicg/feature-policy/issues/220) + +## What's with the `Sec-CH-` prefix? + + Based on some discussion in [w3ctag/design-reviews#320](https://github.com/w3ctag/design-reviews/issues/320#issuecomment-435874298), +it seems reasonable to forbid access to these headers from JavaScript, and demarcate them as +browser-controlled client hints so they can be documented and included in requests without triggering +CORS preflights. A `Sec-CH-` prefix seems like a viable approach. _This bit might shift as the broader +Client Hints discussions above coalesce into something more solid that lands in specs_.