To what extent did you think through how this impacts CORS? As I understand it only Chrome has shipped Clients Hints and basically extended the CORS safelist of headers that can be sent cross-origin without preflight. This is specified to some extent, but there are major issues that are mostly left unaddressed. To then further build on it seems somewhat inappropriate.

@annevk: Good question. I'm blindly assuming that whatever the Client Hints folks work out for CORS will make sense for these headers too. I kinda haven't been following along with that conversation... :( Perhaps @yoavweiss has?

I recall that you and I discussed something along these lines for the CSP:EE work, and you suggesting that the Sec- prefix somewhat mitigated your concerns, though not entirely. I wonder if something like Sec-CH- would be a reasonable pattern to adopt for hints generally... Hrm.

Reportedly the client hints community also wants to be able to control these headers at times so Sec- wouldn't work for them. https://github.com/whatwg/fetch/labels/topic%3A%20client%20hints has all the relevant Fetch discussion on this topic.

Yeah, adding CORS request headers to the safelist has been a somewhat painful process. I'd be fine with requiring all future hints to switch to using a Sec-CH prefix (or just a CH- prefix, as it used to be defined back in the day) to avoid extending the list further and further. It might even be possible for us to migrate current users to the prefixed values.

Reportedly the client hints community also wants to be able to control these headers at times so Sec- wouldn't work for them. https://github.com/whatwg/fetch/labels/topic%3A%20client%20hints has all the relevant Fetch discussion on this topic.

At least the hints that Mike is discussing have no reasonable use-case for user-side manipulations. I need to revisit the user-side manipulations use-case and see if we can't:

• Have the browser set Sec-CH-X headers that are safelisted by default
• Have users set X headers, which are not

Reportedly the client hints community also wants to be able to control these headers at times so Sec- wouldn't work for them.

I'll defer to folks who know what they're talking about, then. Some sort of prefix might make sense. And perhaps for these items in particular, we could decide that we don't want folks to be able to control them from JavaScript. Allowing folks to control the user agent, for instance, seems weird (though I guess we allow it today?).

User-Agent can be set (Chrome might have a bug here), but requires a CORS preflight as well.

User-Agent can be set (Chrome might have a bug here), but requires a CORS preflight as well.

Aparently this is https://bugs.chromium.org/p/chromium/issues/detail?id=571722, which past-me said he was fine with as long as it required a preflight. Silly past-me. :)

I think present-me would be happier if we chose not to make a replacement for User-Agent user-modifiable.

I've updated both the UA-* and Lang proposals to send Sec-CH-* headers (in WICG/ua-client-hints@f3570bf and WICG/lang-client-hint@f32ef12), and I filed httpwg/http-extensions#716 for @yoavweiss to follow up on whether this prefix makes sense for hints generally. It seems like it might!

But it also seems somewhat tangential to the question I'd like to discuss here: infrastructure to the side, are these hints good ideas? Or should we address User-Agent and Accept-Language differently?

I sketched these headers out in a little more detail in https://tools.ietf.org/html/draft-west-ua-client-hints and https://tools.ietf.org/html/draft-west-lang-client-hint. Feedback would be most welcome (also around the Fetch integration in particular, @annevk).

I think I can find folks to implement some pieces of this in Chrome in the ~Q1 timeframe. If y'all have thoughts about how these APIs should be shaped, now would be a great time to pass them on. :)

There's also a bit of discussion around where the underlying concepts should be defined in the HTTP WG thread at https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0003.html. Y'all might have opinions?

/ccing @torgo explicitly, since this has been sitting around for ~2 months. :)

Intents to implement in Blink: https://groups.google.com/a/chromium.org/d/msg/blink-dev/vN-5SjwHPus/saJY6qwXDwAJ for Sec-CH-Lang, and https://groups.google.com/a/chromium.org/d/msg/blink-dev/WQ0eC_Gf8bw/dhWMhCYYDwAJ for Sec-CH-UA-*. I'd appreciate y'all's thoughts.

/ccing @ylafon, since @torgo is busy.

I dont know the appropriate place to make this request, but one of the biggest pain points I see in web development with browsers is that there is absolutely no way for sure to know the viewport size of the requesting browser until after the first visit (where you can set cookies to hint to the server on subsequent requests).

This issue severely handicaps any non-trivial web application that hopes to integrate SSR since the application must be completely responsive. The only alternative is to guess (read: hints) at the viewport based on the UA on the initial request (we have employed such techniques in order to support drastically different layouts... so if requester is an iPhone we guess at a "small" viewport w to hydrate redux stores like https://github.com/AlecAivazis/redux-responsive#server-side-rendering).

To note, many devices now support "split screen" so guessing at the viewport size based on device type is more and more a bad idea.

Similar issue (just for visibility AlecAivazis/redux-responsive#111)

My proposal: I don't think its a security / tracking / fingerprinting concern to always pass on hints of the viewport size of the device, something along the lines of CH-UA-VW and CH-UA-VH?

@chaffeqa: It's a bit tangential to this specific review request, which I'd like to keep focused on the two hints I'd like to add. Still, I think I agree that viewport information can be useful for content negotiation (and Chrome actually already ships a Viewport-Width hint that you can persistently opt-into via Accept-CH-Lifetime!). But I think I disagree that it's not a fingerprinting concern to always pass on hints, generally. An explicit opt-in seems like the right compromise to me.

Makes sense to keep the discussion to the initial mentioned items. And thanks for the heads up on Viewport-Width! I've used it before but it still doesn't solve the issue of the first-contact render.

I'll try to find the appropriate place to ask if there is a solution / discussion on that front.

Still excited to see movement in this area, thanks for taking it on!

For Accept-Language, I'd rather have the server sending variants than requesting language preferences via client-hints. In that case, indicating to the server that you would like to be presented with multi-lingual options should be enough.
That said, I did not track the state of the Variants spec...

Hey Mike!

At today's Tokyo F2F, we had a great discussion about this proposal. We didn't dive too deeply into the technical proposal, but discussed the problem space at a high-level. As you might have expected, the TAG is supportive of efforts to reduce fingerprinting, especially passive fingerprinting which we think has a much smaller surface area that we can affect in the browser. Given this framing, we are actually quite happy to see this effort around the User Agent string (and Accept header) move forward. We believe it will be great to have the User Agent string (that is sent by default) ultimately have less-entropy by transitioning the entropy into opt-in client hints.

We liked the fact that, as client hints, the client can be aware of which servers are asking for the extra entropy, and potential for fingerprinting that go with it.

So... this is the official "thumbs-up" from the TAG. Please continue developing this proposal, and we look forward to being involved in future review requests!

The is TAG, signing off.

Hi Mike,

Simple detail added. I see the UA would not be informing about the language to HTTP end points. Is that a problem?

I see the UA would not be informing about the language to HTTP end points.

Correct. This is documented in https://tools.ietf.org/html/draft-west-lang-client-hint-00#section-3.1.

Is that a problem?

I don't think so. It means that language preferences will not be leaked over plaintext channels, reducing the opportunity for network attackers to build a profile of a given agent's behavior over time. Similarly, I'd like to limit the navigator.language and navigator.languages accessors (see 3 in https://github.com/WICG/lang-client-hint#a-proposal).

Do you think it's a problem?