Integrate latest Client Hints updates

[igrigorik]

Consolidating the tasks into a meta bug, so we can track progress..

Update list of hints

• Add RTT, ECT, Downlink, and Device-Memory headers to the CORS-safelisted list, Client Hints list, and processing (step 6).
  • Covered by Add device-memory and network quality client hints to the list #725

Integrate Accept-CH-Lifetime / opt-in logic

• Add a step after step 10 in Main Fetch, which reads Accept-CH-Lifetime and adds it to some CH-opt-in cache
  • Add definition of said cache
  • Covered by Define the ACHL cache and ACHL/ACH processing html#3774
• Change steps 6-7 in Fetching to take Accept-CH and/or CH-opt-in cache into consideration.
  • Limit above steps to secure origins
  • Limit above steps to same-origin - unless the origin is on some list of allowed origins
  • Covered by Align CH processing model with implementation and HTML#3774 #773
• Update HTML spec to support <meta http-equiv> opt-in
  • Also covered by Define the ACHL cache and ACHL/ACH processing html#3774
• Add WPT tests for opt-in logic
  • Covered by https://wpt.fyi/results/client-hints

Integrate Feature-Policy + Client Hints hooks

• Hook up Feature Policy and Feature Proposal: Client Hints delegation w3c/webappsec-permissions-policy#129 to said list of allowed origins
• Add WPT tests for FP opt-in

@tarunban @yoavweiss @annevk anything missing?

[yoavweiss]

I started working on the "CH opt-in" cache part at #729, but following an IRC discussion with @annevk I'm now wondering what's the right way forward.

The above PR adds that infrastructure to Fetch, but it was suggested that HTML might be a more appropriate place. Among other considerations, it depends if the response header handling is limited to navigation responses (which are also handled in HTML) or also cover subresource responses (handled only in Fetch AFAICT).

Talking to @igrigorik, the use case for handling the Accept-CH-Lifetime headers on subresources is to enable double-keying them for hints sent to third party resources, for improved privacy protections. However, with the upcoming Feature Policy client hints opt-in to specific hosts, I'm not sure double keying is still necessary from a privacy perspective.

Opinions?

/cc @arturjanc @tarunban

[igrigorik]

For context, we introduced requirement for double-keying before the discussion towards delegation, and that's where FP got introduced into the mix. Stepping back, I think FP-only solution could work and would simplify the processing: given that 1P explicitly delegates permission to send hints to a specified 3P via FP, the 3P opt-in on top of that is redundant.

@arturjanc @npdoty would love to hear your thoughts.

Assuming we all agree on this, shifting the logic into HTML spec makes a lot of sense.

[npdoty]

I don't think the third-party indication that it will make use of Client Hints is redundant even if the first party indicates that it trusts the third party to receive that data. The purpose of the opt-in request was for servers to indicate what data they will make use of (which improves transparency on practices like fingerprinting) and to only send the necessary data (data minimization). If a first party site just says, "all of my embedded parties are cool", that may not provide the user or researcher with much indication that the third party wants or needs the data.

(Not sure we should call this "double-keying", as it's not like the case of cookies/storage that is different for different pairs of origins, but rather that data is transmitted only if both sides of the origin pair allow it. What do we call the practice of allow* attributes on iframes?)

[yoavweiss]

@npdoty Thanks for the feedback!
The thing that is important to understand about third-party opt-in is that it will add an extra RTT to the time in which such third party get the required Client-Hints. In practice, it may mean that for the first page load, Client Hints will not be in effect, which is strictly worse than what we have today.

I understand that this will adds some transparency to the CH-based fingerprinting, but couldn't we treat the first-party opt-in to the same purpose? After all, third party accepting CH does not mean that it uses them for fingerprinting.

If a first party site just says, "all of my embedded parties are cool", that may not provide the user or researcher with much indication that the third party wants or needs the data.

Maybe we can limit that by banning "*" as a viable allow_list_value in the related Feature-Policy.

[igrigorik]

FWIW, I agree with Yoav that first-party delegation offers a strong signal, while allowing for easy and performance deployment.

Maybe we can limit that by banning "*" as a viable allow_list_value in the related Feature-Policy.

I'm reluctant to go down this path. From a developer ergonomics perspective it would be completely non-intuitive for why this wouldn't or shouldn't work in this case, but work for other policies.

One of the other purposes of double keying was so that the UA can remember the opt-ins for third party resources when loaded in the context of first-party. I believe that feature policies are not cached by UA. Is that correct? If so, removing double keying implies that the 1p has to provide FP for third-parties for every page load. I believe that should be fine, but just wanted to point that out.

[igrigorik]

@tarunban that's correct, FP is not cached. For purposes of CH, I think this is fine and wouldn't break any use cases. If Origin-Policy ever becomes a thing, it could provide a way for a site to avoid specifying FP headers on each response, but I haven't see much recent activity on that front.

[foolip]

I haven't read through this thread, but came here from https://chromium-review.googlesource.com/c/chromium/src/+/1066919 and just want to make sure one facet ends up being covered. There, window.open is used after receiving the Accept-CH-Lifetime header, on the assumption that the requests for that new browsing contexts wouldn't get any client hint headers if not for the Accept-CH-Lifetime header. But as discussed in that review, it seems like there are only examples in the specs to go by, no normative requirements.

So hopefully this issue will make it clear precisely which fetches get the headers :)

[yoavweiss]

@foolip - thanks for catching that. This should indeed be better defined. It's probably cleanest to apply Accept-CH only to the browsing context on which it was received.

[foolip]

Yep. Perhaps that'll involve adding an internal slot to store stuff in HTML, and consulting that state in Fetch, that kind of thing.

[arturjanc]

The Feature Policy integration which requires explicit opt-in for sending hints on third-party requests, and the associated Accept-CH-Lifetime behavior sound good to me.

On an unrelated note, where can I find a discussion of Device-Memory? Is the data it exposes already available via other means?