search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.11k stars 328 forks source link

Integrate latest Client Hints updates #726

Closed igrigorik closed 4 years ago

igrigorik commented 6 years ago

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

Update list of hints

Integrate Accept-CH-Lifetime / opt-in logic

Integrate Feature-Policy + Client Hints hooks

@tarunban @yoavweiss @annevk anything missing?

yoavweiss commented 6 years ago

I started working on the "CH opt-in" cache part at https://github.com/whatwg/fetch/pull/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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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.

tarunban commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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?

tarunban commented 6 years ago

Device-Memory is exposed via JavaScript too: MDN docs

yoavweiss commented 6 years ago

I've updated the top comment on this issue with the open PRs that resolve it. AFAICT, all issues should be resolved, other than the Feature-Policy/3rd-party opt-in bits, which we don't aim to ship in the immediate future.

We may be able to benefit from a couple more tests, making sure that ACH and ACHL don't work on subresource responses. Otherwise, I think we're good to go (pending reviews and landing of the PRs).

igrigorik commented 6 years ago

Nice work, thank you Yoav! As a recap, we're waiting for the following to land:

Other than the Feature-Policy/3rd-party opt-in bits, which we don't aim to ship in the immediate future.

Yep, this is non-blocking.

tarunban commented 6 years ago

Yes, I have #725 covered, but I need to land some Chromium changes and WPT tests to conform to the updated spec.

npdoty commented 6 years ago

@arturjanc:

On an unrelated note, where can I find a discussion of Device-Memory?

I think the Web Performance Working Group is the place for discussing the Device Memory 1 Editor's Draft.

Is the data it exposes already available via other means?

As far as I can tell, that data is not already commonly exposed. The editor's draft, not yet published as a Working Draft and implemented only in Blink, adds access to that data in both HTTP headers and JavaScript.

yoavweiss commented 4 years ago

The work related to CH integration with Fetch and HTML was done as part of https://wicg.github.io/client-hints-infrastructure/ Once there's consensus on it, I'll happily integrate the algorithms there directly to the relevant specifications.

Closing this as obsolete

annevk commented 4 years ago

What's the upstream issue then to discuss the design and inform the Fetch/HTML community?

yoavweiss commented 4 years ago

Good point, opened https://github.com/whatwg/fetch/issues/1072