Design Review #871

#871: [FYI] Clear Client Hints via Clear-Site-Data header

Opened Jul 17, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Clear Client Hints via Clear-Site-Data header.

Websites will now be able to clear the client hints cache using Clear-Site-Data: “clientHints”. Client hints will also now be cleared when “cookies”, “cache”, or “*” are targeted by the same header. This is because if the user clears cookies in the UI client hints are already cleared as well, the client hints cache is a cache, and to be consistent with wildcard targets respectively.

Specification URL: https://w3c.github.io/webappsec-clear-site-data/
Tests: https://wpt.fyi/results/client-hints/clear-site-data?label=experimental&label=master&aligned
GitHub repo (if you prefer feedback filed there): https://github.com/w3c/webappsec-clear-site-data/issues/new
Primary contacts (and their relationship to the specification):
- @arichiv, Google
Organization(s)/project(s) driving the specification: Chromium
Key pieces of existing multi-stakeholder review or discussion of this specification:
- https://github.com/mozilla/standards-positions/issues/848
- https://github.com/WebKit/standards-positions/issues/230
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: Chrome M117 branch cut is August 8, 2023

You should also know that...

The only current way for a website to force the client hint cache to be cleared is to send a single header like Accept-CH: with no content. If any other Accept-CH: headers are sent at all (empty or not) this will cause all of them to be ignored. If the Accept-CH header is injected into an HTTP response at multiple points, it can be difficult to silence them all when one part of the server wishes to clear all hints. This header provides a way to do that, as the Clear-Site-Data: “clientHints” header clears the cache and causes all other Accept-Ch or Critical-CH headers to be ignored.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Jul 1, 2023 (See Github)

Tess: all things being equal it seens like clear site data header... user feedback of building on quicksand.. proposals that don't have consensus built on top of proposals that also don't have consensus..

Hi – the proposal itself seems fine, when taken in the context of client hints.

A meta comment regarding client hints:  In 2018, the TAG gave an initially positive review to the [client hints design](https://github.com/w3ctag/design-reviews/issues/320).  However subseuqntly client hints has failed to garner multi-stakeholder support, specifically from other browsers.  In more recent reviews, we have been flagging this and trying to advocate for multi-browser support (multiple implementations) as a key aspect of new features we want to add to the web.  The TAG remains concerned that we are building new features and technologies on top of other features that do not enjoy multiple implementations and are not supported across multiple platforms.

Dan: Satisfied with concerns?

Tess: OK.

Lea: OK.

closed and commented

Comment by @torgo Jul 19, 2023 (See Github)

Hi @arichiv we're seeing in Chromestatus no signals from Firefox or Safari. Is there any multi-stakeholder support? There's no explainer provided so we're not sure what the documented user need is. We're also wondering if alternative mechanisms were explored? Given that this is a new http header, it seems like maybe a little more than an FYI would be appropriate here.

Comment by @arichiv Jul 19, 2023 (See Github)

Fair enough, I figured it was more of an extension of https://github.com/w3ctag/design-reviews/issues/62.

There isn't multi-stakeholder support AFAIK as only Blink currently implements client hints.

Comment by @arichiv Jul 19, 2023 (See Github)

Oh, and as for other approaches, the main existing one is sending an empty Accept-CH header like: Accept-CH: in the HTTP response. This violates the sf-list standard though, and gets confused if multiple Accept-CH headers are sent, so this replacement was proposed after discussion on https://github.com/WICG/client-hints-infrastructure/issues/155#issuecomment-1638741230

Comment by @torgo Aug 3, 2023 (See Github)

Hi @arichiv – the proposal itself seems fine, when taken in the context of client hints.

A meta comment regarding client hints: in 2018, the TAG gave an initially positive review to the client hints design. However subsequently client hints has failed to garner multi-stakeholder support, specifically from other browsers. In more recent reviews, we have been flagging this and trying to advocate for multi-browser support (multiple implementations) as a key aspect of new features we want to add to the web. The TAG remains concerned that we are building new features and technologies on top of other features that do not enjoy multiple implementations and are not supported across multiple platforms.