Consider a `Sec-CH-` prefix for client hint headers

[mikewest]

In w3ctag/design-reviews#320, @annevk (re-)raised the question of Client Hints' integration with CORS. One suggestion in that thread is to prefix headers with Sec-CH-, which on the one hand makes them trivial to add en masse to the CORS-safelisted list, and on the other prevents JavaScript from setting their values (which in turn limits the risk associated with adding them to the CORS-safelisted list in the first place).

I have two concrete proposals for hints (UA-* and Lang) that adopt this pattern. Perhaps it's one that could be baked more deeply into the Client Hints infrastructure?

/cc @igrigorik @yoavweiss @arturjanc

[reschke]

Please no additional overloading of names.

[yoavweiss]

Please no additional overloading of names.

OK. Can you expand on that?

[reschke]

Names are names. I realize that there's a precedent with "Sec-". But it really doesn't scale.

If we're serious about this, it needs to be done with a plan that explains how this would work with the next keyword being added. In particular, if the "next" extension is completely orthogonal to this one.

[mikewest]

Sec- exists, and has meaning (at least in browsers). Are you objecting to that in itself? Or are you objecting to adding an additional CH-?

[reschke]

I object to this unless we have a documented and agreed-upon plan how this scheme would work with future keywords.

[mikewest]

Sec-CH-Next-. :)

[reschke]

What if "Next" doesn't automatically always have the properties of "Sec"?

[yoavweiss]

@reschke apologies, but at least to me, it's still not clear what you're objecting to.
Is it Sec- prefixes in general? Adding CH- prefixes to the Sec- prefix? If it's the latter, would a stand-alone CH- prefix (like we used to have) work better?

[reschke]

I'm objecting to the further abuse of overloading names with semantics without having a plan how this would work with future extensions.

We dropped "CH-" because we did not need it, right?

[yoavweiss]

The reason we realize now that it is in fact needed is that we want client-hints to get a free-pass when it's comes to the CORS safelist. That is, we don't want to add every new header to the list.
Having a prefix will enable us to give all these headers the same treatment, but will also enable us to have a clearer mind when doing so, because the prefix reduces the probability that some existing server is already using those request header values in their logic in an unpredicted way.

[mikewest]

we want client-hints to get a free-pass when it's comes to the CORS safelist

FWIW, I don't actually care about this. It's fine with me if Fetch just lists all the headers, and y'all have to send PRs to Fetch to add them. :)

because the prefix reduces the probability that some existing server is already using those request header values in their logic in an unpredicted way.

I do care about this. And I especially care that we significantly reduce the risk of the headers containing interesting payloads if we block JavaScript access by prefixing them with Sec-. The CH- bit is just defense in depth/obscurity from my perspective.

[mnot]

Right. I can understand the Sec- prefix because that's defined behaviour (but I note @mikewest's comment with interest; I've never really liked that). CH- is just sugar here AIUI.

You could document that Sec- is required and CH- is just convention that doesn't actually change recipient behaviour -- just as Allow- Accept- Content- etc. are.

[arturjanc]

There seems to be concrete value in adding the Sec- prefix for client hints, primarily for the reason Yoav mentioned: it reduces the compatibility concerns associated with sending a new request header. Otherwise, adding a hint header of Foo would break applications that currently set a custom header with the same name in a way that's difficult to predict in advance or detect.

When it comes to CH-, a common prefix that identifies hints also appeals to me. It would make it slightly easier to see which headers carry hints, helping developers discover their presence, but also allowing middleware to reliably strip them (e.g. in privacy extensions which aim to reduce the amount of information sent by the browser).