Allow servers to specify max-age in the client hints header

The Accept-CH header is currently included by origin servers in HTTP responses if they are interested in receiving client hints from the browser (e.g., DPR). The spec currently does not require browsers to persist the opt-in across browser restarts. This means that if the origins are interested in receiving hints on all requests, then they need to include the Accept-CH header on all responses. This has two disadvantages: (i) Browsers currently fail to include the hints on the first request after the browser restart; and, (ii) It may not be possible for the origin servers to include the Accept-CH header on all responses due to responses being served out of different endpoints (CDNs etc.).

To fix this: The Accept-CH header should also support a max-age header value which indicates for how long should the browser remember this opt-in (including across browser restarts). A value of max-age set to 0 should cause the browser to stop sending client-hints to the origin. As an example,

Accept-CH: feature1, feature2, max-age=86400

would imply that the browser should include hints feature1 and feature2 for next 86400 seconds for that origin.

[michael-oneill]

It crossed my mind also that the response determines a future request, so how long in the future?

Why not create a well-known named cookie, similar to the cookie prefix idea in RFC6265bis, then use that to convey Accept-CH. Then you get the potential fingerprinting showing up in the cook,ie store where the user (or privacy extensions) can see it. You also get the expiry functionality for free.

And the SameSite attribute to help with privacy.

@michael-oneill I am not sure if cookies are the best place to store this information given that cookies are used by servers for state management, and this does not seem to fit that use case.

[michael-oneill]

Accept-CH makes the UA retain the state on what Client Hints are to be sent in future requests. The problem with Client Hints is that they can (will) be used to identify users by fingerprinting their UAs.

Users know to some extent that cookies are used to identify them, so why not hold this identifying styate their also.

It increases transparency,, enables user control and does not re-invent the wheel.

[mnot]

Making this a new directive in Accept-CH is a bit problematic, since that header field is defined as a list of header field names. It's technically possible, you just would get into situations where you have to switch your parser based upon the format of the directive, and reserve keywords that now can't be used as headers (and thus, have to register them as headers -- see Connection).

You could do it as a new header, though -- e.g.,

Accept-CH-Lifetime: 3600

or similar.

That has the additional benefit that it can be introduced later if there's need for it, and we decide not to do it now.

@igrigorik, what do you think? Keeping in mind that we're doing this spec primarily to document what one (albeit big) implementation is doing, hence its Experimental status, is Chrome interested in implementing this?

If not, I'd suggest we close this issue; if it's interesting in the future, it's relatively easy to add that new header.

All of that said -- I do think there's a bit of an issue remaining with how the applicability of Accept-CH is scoped. I'll open a separate issue for that.

[igrigorik]

My long-term hope is that this entire discussion is a no-op and origin policy will give us the right primitives (see WICG/origin-policy#12) to solve this in a generic way for all opt-in behaviors. That said, there is interest in implementing this in Chrome— tarunban@ is driving that work—and we need an alternative mechanism until OP is a thing.

I agree with Mark that Accept-CH-Lifetime is better solution. The secondary benefit, as I see it, is that we can also no-op it later once Origin Policy becomes available. More details in #307 (comment).

[filex]

Disclaimer: I'm new here, so please forgive possible naivety :)

Thinking about this issue and other kinds of scoping mechanisms (max-age directives in Cache Control, Cookies or HSTS, well-known Origin Policy files etc.), I was wondering whether we could try to attach directives to manage site properties (such as CH scope) in both time "and space" to the TLS scope.

A TLS certificate is a necessary prerequisite for many HTTP/Web extensions. E.g. HSTS headers are ignored without a validated certificate. We could limit the possible lifespan of any time-bound directive to the remaining TTL of the certificate. Say my LE certificate expires in 30 days; the user agent could store the CH settings for exactly this time span. Usually certificates are renewed before the expire. This should allow user agents to revalidate and reschedule the property expiry well before they expire. The same could apply to HSTS or other properties. A user agent may use this site/origin property until the certificate expires, and it must be revalidated at the next contact thereafter.

The spatial scope of the certificate is somewhat boring, because it usually covers a whole origin in sense of / on a certain domain name. However, wildcard certificates or ones with more than one common name could be used to tie together a bunch of hostnames. We could use that as an outer bound for origin properties.

More generally, could we transfer properties such as Origin Policies or HSTS directives as part of the TLS handshake in an ALPN-like fashion? This would enable the server to communicate transfer rules to the user agent before the first request on HTTP level is carried out.

[igrigorik]

@filex interesting idea, but I don't think we want to couple certificate lifetime to other settings.. there is no reason why cert lifetime is representative of the content lifetime transported over the TLS tunnel.

[martinthomson]

@filex, you will find that there is a great deal of reluctance to do that sort of thing. If we were to start doing that, then we would create another reason to lengthen the validity period of certificates. That's bad for security.

In other words, is an advantage to have a logical separation of details of the authentication mechanism from the management of state.