Re: [w3ctag/design-reviews] `Accept-CH` header is weird (#206)

Hey all,

Thanks for all of the thoughtful discussion.

After talking at some length with both @igrigorik and @mnot, the TAG wanted to close this issue. We're happy to see the `Accept-CH` system go forward _with the following caveats_:

 - Developers clearly want `Client-Hints` to be sent for top-level navigations, and there are clear use cases for it.  We should acknowledge that this is a goal of Client Hints.
 - It is punitive to introduce the need for a redirect to negotiate alternative top-level content for data and latency and data-sensitive users and the sites that serve them. This potentially undermines the utility of URLs for these sites and introduces even *more* latency. This is only partially addressed by the addition of [`Accept-CH-Lifetime`](http://httpwg.org/http-extensions/client-hints.html#accept-ch-lifetime) header at the cost of high complexity for both developers and implementers.
 - It seems odd to need to send both `Accept-CH` and `Accept-CH-Lifetime`. Can these be combined? It also further seems odd that the choice of terminology is inconsistent with other lifetime-defining header directives (e.g., `Cache-Control`, `Expect-CT`, etc.) which all use `max-age` sub-values.
 - It's also incongruous that the header is a _response_ value but is named "`Accept-`". No other header we're aware of uses this nomenclature in responses (vs requests).
 - We remain unconvinced by privacy arguments regarding opt-in-free `Client-Hints`. Perhaps for environments that aren't the web, this would be a meaningful distinction, but for HTML, the reality of CSS media queries, DOM APIs, and other side-channels for determining this information at runtime ensure that there's no net privacy benefit (aside from requiring that fingerprinting parties do so actively and thus visibly, a situation the can be re-created by removing support for `Client-Hints`). UAs that don't provide regular HTML processing could avoid sending specific hints. A unique case is reflection of data that's not trivially available otherwise (e.g. [`Save-Data`](http://httpwg.org/http-extensions/client-hints.html#iana-save-data)), but given that this information is available via origin opt-in under `Accept-CH`. We therefore recommend that UAs revisit the decision to require the opt-in at their earliest convenience (again, acknowledging that non-web environments or restricted contexts like a "private browsing" mode may choose to set defaults very differently, up to and including disabling `Client-Hints` entirely).
 - Without the privacy argument, the argument for the `Accept-CH` protocol seems to hinge on an argument about header bloat. This is a question for data to resolve and we're looking forward to learning more about the current state of request header contribution to packet fragmentation and latency. If the TAG should be discouraging the addition of new data to the default set of headers, we'd like to understand the case in detail so we might advise feature developers appropriately (perhaps via our [Design Principles](https://w3ctag.github.io/design-principles/), which we request feature designers consult).

We'd love to hear back from `Accept-CH` implementers regarding the impact of the feature when deployed and how they weigh on the various questions we've raised here. As a step towards a future where this information is available to developers more cheaply, `Accept-CH` is a reasonable short-term compromise. We'd like to avoid it being a long-term end-state.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/206#issuecomment-379422513