My opinion doesn't carry a lot of weight here, but I like both MUST and Sec-CH (or potentially some other namespace-like thing, e.g. Sec-Hint) -- this mirrors what @mikewest did for Sec-Fetch-*.

Ilya's suggestion also LGTM.

Apologies for my slowness on this. Adopted Ilya's suggestion.
I know that @reschke was wary of adding more namespace like things though.
@reschke - can you repeat your concerns around this?

Well, the discussion is in #716 - maybe this is a good topic for the WG meetings in Montreal?

OK, I'll revive the discussion there

Fixes #767 and #716

@igrigorik - integrated your suggestions and then suggestions from @sleevi. PTAL?

mnot@ - Friendly ping :) Do you think the "CH-" bit is required?

Friendly ping! :)

The Sec- prefix guarantees that application developers are not currently sending requests with that header to their server (i.e. they're not adding it in XHR/Fetch because it's a forbidden header name.) If a browser starts sending a new header without the prefix, it can result in unexpected behavior if the header name clashes with a custom header already in use by an application. In some cases this can create a security issue, e.g. if an application uses the presence of such a header to identify trusted requests -- this approach is a relatively common CSRF protection because the server can be sure that requests with a custom header were sent same-origin, or the server had opted into them in response to a CORS preflight.

I don't feel very strongly about this particular case, but in general I'm worried about browsers sending new unprefixed headers by default for this reason.

I believe @annevk had some comments about similar situations in the past.

@arturjanc that basically means we can't define any new request HTTP headers, which is pretty demonstrably untrue. What we shouldn't do is choose especially generic names, like HTTPS. Don't generalise from one bad experience.

Also, the establishment of the convention to use a "CH-" prefix would seem to avoid that problem amply. But @mnot's point is the stronger one. I realize that having a standard bulldoze your established use of "My-Header" is an experience people are reluctant to be exposed to the possibility of, but they could always register header field names.

Each new request header that a browser is to transmit cross-origin and is not prefixed with Sec- (or subject to a CORS preflight) would be another enshrined exception to the same-origin policy and a possible security issue until servers are updated to expect it.

Furthermore, some new request headers are not supposed to be spoofable same-origin and for those the prefix is important too. We have not had to update https://fetch.spec.whatwg.org/#forbidden-header-name for about a decade now and it would be nice to keep it that way.

(There's also a problem if an attacker can control these fields somehow. We've had to impose length restrictions on Referer and the CORS-safelisted request-headers. I suspect that's not applicable to client hints.)

(OK, disclaimer: I'm not 100% clear on the model for cross-origin use of client hints then, but this is my operating model. If this model is incorrect somehow, I think that the fetch changes here are what needs adjusting...)

Given that these aren't sent unless the server specifically requests them, I think that the cross-origin concern isn't that significant. Rather than insisting on a one-by-one exception, a systemic exception for client hints would be preferable.

The way that this draft models CH header fields is that the site collects the information and injects the header field in every request as it leaves for the server (as if by service worker fetch interception). The browser is just helping out. If we are able to adhere to that model, then allowing insertion is different than header fields like User-Agent or Origin or other security-critical fields.

If this model is correct, then it doesn't make sense for these to be forbidden or for them to require special processing for exemption. Note that this changes how the information needs to be generated (it can't access privileged information; that's already in this doc), and it means that these are treated like any other header field.

As for concerns about interaction with ambient authority that a server might associate with the request, I think that I will point back at the bit where the server explicitly asked for the hint to be provided. I concede that cross-resource concerns might be a problem (resource A asks, resource B is unprepared), but the set of fields will be small, carefully groomed by browser makers, mostly prefixed with CH-, and carrying information that is not obviously useful in security-critical decisions.

Agreed that if the server asks for the browser to set these headers on subsequent requests the cross-origin concern does not apply. However, that does assume these headers are not attacker-controlled and depending on when they are set (and the ask has been that they are set early to expose them to service workers as normal headers) they would also have to bypass CORS and we'd have to ensure they cannot be manipulated, etc.

And writing that down I realize there's a security problem there as now A can figure out that B requested client hints (and see what hints B will get).

Also, does the spoofing concern not apply?

It's also not entirely clear if server opt-in is tenable as we've seen requests for client hint like data to be available on the first request.

Given that these aren't sent unless the server specifically requests

That is true for the same origin case, but not for the cross-origin one. For privacy purposes, we've limited the Client Hints opt-in to top-level documents, so a cross-origin resource cannot opt-in to client hints. And with Feature Policy, the top-level document can delegate hints to certain origins.

That means that those origins will get the hints without opting into them, which increases the risk.

At the same time, we want to avoid Client Hints request headers from triggering preflights, while being sure that it's indeed safe to do so.

A can figure out that B requested client hints (and see what hints B will get).

A seeing the values isn't an issue as it is A that put the hints there (and A sees the same values).

I don't see A having influence over values (viewport width maybe...).

B being unprepared for the hints does seem to be a problem. I know that avoiding preflight is appealing from a performance perspective, but that's how we've decided to operate for these things. Because A is essentially forcing the inclusion of header fields into cross-origin requests, I think that we have a few options:

1. perform some sort of analysis for each client hint to verify that no server conditions behaviour on the newly introduced header field in a way that would expose security-critical information

2. preflight always

3. find a better alternative to preflights (origin policy, the TLS extension, etc...)

4. pretend that Sec--prefixed header fields aren't subject to these same concerns

5. require the use of CH- prefixes and perform generic analysis

FWIW, for the first reason, we can't remember that B was OK with hints when it was top-level or framed in C because that lets A observe that B has been visited elsewhere.

• pretend that Sec--prefixed header fields aren't subject to these same concerns

I'm not sure we need to do a lot of pretending here ;-) We know that applications can't get Sec-prefixed headers with ambient authority, so developers don't use them in their applications (unlike other headers which may be set same-origin or allowed via a response to a preflight). I believe delivering hints with a Sec- prefix would indeed avoid the class of problems discussed above; is there a specific issue that you're still worried about in this case?

@martinthomson - does @arturjanc's response answer concerns you had around option (4)?
As I'm not sure how to go about either (1) or (5), (2) would be a significant performance regression and (3) seems somewhat orthogonal, (4) seems like the best path forward.

At IETF 106, we agreed that it might be better to modify this so that the infrastructure draft indicates that features need to make sure that adding new request headers would be safe for servers. Individual features would then be able to decide if they enforce Sec-, live with a preflight and its performance regressions, or otherwise add their request headers to the CORS safe list. An alternative PR outlining that will follow.

At IETF 106, we agreed that it might be better to modify this so that the infrastructure draft indicates that features need to make sure that adding new request headers would be safe for servers. Individual features would then be able to decide if they enforce Sec-, live with a preflight and its performance regressions, or otherwise add their request headers to the CORS safe list. An alternative PR outlining that will follow.

@martinthomson - looking at the current language, it seems to well-align with that decision without much modification. Can you take a look and let me know if you agree?

@martinthomson - friendly ping! :)

Post holidays ping! :)