[FYI] Clear Client Hints via Clear-Site-Data header

[arichiv]

こんにちは 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):
  • https://chromestatus.com/feature/5105030738214912
  • https://groups.google.com/a/chromium.org/g/blink-dev/c/lJY86eTPQ0s/
  • https://crbug.com/1458394

Further details:

• [x] 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

[torgo]

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.

[arichiv]

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.

[arichiv]

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

[torgo]

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.