Migrating some high-entropy HTTP request headers to Client Hints.

[mikewest]

Guten TAG!

I'm requesting a TAG review of the general concept of migrating high-entropy HTTP request headers to the Client Hints infrastructure. I have two concrete proposals that I think make sense, but they make the most sense together as part of a broader story about reducing the passive fingerprinting surface available to both network attackers and servers.

• Explainer, Requirements Doc, or Example code:

  • https://github.com/mikewest/ua-client-hints suggests that we split User-Agent into UA, UA-Platform, UA-Arch, and UA-Model Client Hints.
  • https://github.com/mikewest/lang-client-hint suggests that we turn Accept-Language into a Lang Client Hint.

• Primary contacts: @mikewest, @thiemonagel

Further details (optional):

• Relevant time constraints or deadlines: None
• I am passingly familiar with the Self-Review Questionnare on Security and Privacy.
• I have reviewed the TAG's API Design Principles

You should also know that there's some active disagreement about the value of Client Hints generally. We had a number of discussions on the topic at TPAC, and I hope I'm not overstating things to suggest that there was some level of agreement that the infrastructure of Client Hints might be a reasonable one to support, even in the face of substantial disagreement about the specific hints that the infrastructure might support.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

Thanks folks! You're still my favorite architectural review body in the W3C!

[annevk]

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.

[mikewest]

@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.

[annevk]

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.

[yoavweiss]

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

[mikewest]

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?).

[annevk]

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

[mikewest]

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.

[mikewest]

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?

[mikewest]

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).

[mikewest]

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. :)

[mikewest]

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.

[chaffeqa]

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?

[mikewest]

@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.

[chaffeqa]

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!