Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372)

From: HTTP issue updates <[email-masked]>
Date: Wed, 19 Jul 2017 16:14:32 +0000 (UTC)

> The introduction of Accept-CH-Lifetime will extend this problem to all resources on a given origin -- if one page sets the header, then subresource requests from all pages in that origin will start carrying hint information. 

IIUC, this is not correct. If the origin includes `Accept-CH-Lifetime` header, then the user agent is expected to send the client hints for requests to only that origin.

> Similarly, hints should probably also be stripped on HTTPS -> HTTP transitions.

The Chromium implementation (currently underway) processes `Accept-CH-Lifetime` header from only HTTPS origins. So, the client hints sent because the user agent received `Accept-CH-Lifetime` in the past would be sent to only HTTPS origins. Quoting the spec:

> Implementers ought to provide mechanisms and policies to control how
   and when such hints are advertised. 

cc'ing @igrigorik to comment on if any spec changes are needed here to make this more explicit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-316434821

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 19 Jul 2017 13:07:39 -0700

> If the origin includes Accept-CH-Lifetime header, then the user agent is expected to send the client hints for requests to only that origin.

Hmm, I'm getting a different impression from the text in the [spec](https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-2.2.2): 

> if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR and Viewport-Width in this example) to the request **and any subresource requests initiated as a result of processing a response from same origin**.

If hints are supposed to be sent only on same-origin subresource requests it would address my main concern. In general, it would be great if the current _non-lifetime_ Accept-CH behavior was also limited to same-origin subresources -- I don't think requiring developers who want to use client hints to also leak this information to owners of third-party subresources loaded on their pages is particularly great.

> The Chromium implementation (currently underway) processes Accept-CH-Lifetime header from only HTTPS origins.

What about HTTPS pages which have HTTP subresources? The behavior I currently see for Accept-CH is that the HTTP subresource requests have client hints (but no Referer); I believe you're saying this behavior would change with Accept-CH-Lifetime? If so, this sounds good, though see above re: the broader concern about non-same-origin subresources.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-316501549

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 20 Jul 2017 03:29:44 +0000 (UTC)

@arturjanc thanks for the great feedback. Let me try to unpack...

Prior to introduction of `Accept-CH-Lifetime` (ACL) — which is very recent — there was no mechanism in place for an origin to persist a preference for hints across independent requests. As a result, navigation requests did not get any hints and only subrequests of the "opted-in document" were eligible. The extra complication here is that the initial set of core use cases (image optimization) frequently relies on use of CDN's and third-party services+origins, which means that prior to ACL there was no way for those origins to enable CH hints, since page origin != resource origin. As a result, the decision was to extend Accept-CH opt-in to all resources fetched by the page.

Now that we have ACL, it may be possible to revisit this setup. In particular, if we scope ACL to per-origin, then both the page origin and resource origin can advertise support separately and these preferences will be persisted across requests. In fact, I suspect that this is what will happen anyway, because for cases like image serving CDNs will advertise support for hints on their own origins, such that any site relying on their service can benefit by default.

@yoavweiss wdyt?

---

> What about HTTPS pages which have HTTP subresources? The behavior I currently see for Accept-CH is that the HTTP subresource requests have client hints (but no Referer);
> ...
> Obeying Referrer Policy and omitting hints if the referring page attempts to restrict data which is sent in the Referer header. Similarly, hints should probably also be stripped on HTTPS -> HTTP transitions.

I think this would naturally fall out of the origin-scoped model? As in, if opt-in is scoped to HTTPS then we wouldn't send hints to HTTP, unless the HTTP origin also explicitly opted-in. 

Re, Referer:  "I have third party resources on my site, which may have hints enabled, and I want to strip those alongside referrers", is that the use case? If so, that seems legitimate, but using Referer does feel a little action-at-a-distance to me. As in, I wouldn't expect Referrer to control hints? That said, I don't have a better suggestion either. @mikewest wdyt?

> A related issue is that based on the sets of headers sent in such subresource requests, the subresource owner might be able to identify the referring site even if it sets a Referrer Policy to prevent disclosing its URL or origin. For example, requests from a large site which sets Referrer-Policy: no-referrer; Accept-CH: DPR will be distinguishable from requests from sites with Accept-CH: DPR, Viewport-Width and from those without client hints. Depending on the chosen set of hints this can in practice uniquely identify the origin visited by the user.

Good points, we should flag this in the privacy & security section.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-316586505

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 20 Jul 2017 10:47:06 +0000 (UTC)

> Now that we have ACL, it may be possible to revisit this setup. In particular, if we scope ACL to per-origin, then both the page origin and resource origin can advertise support separately and these preferences will be persisted across requests.

This seems like a better model than the status quo because it limits the sending of hints to origins which opt into receiving them. However, it still has the issue of revealing new information to providers of third-party subresources which they can't obtain now. This seems fine to do with opt-in from the first party (which can already get the Viewport-Width, etc via client-side scripts and then provide it to the CDN in the URL), but seems less great if the CDN can decide to always get hints in all requests, because of the passive fingerprinting potential.

What do you think of double-keying the hints on both the first- and third-party? That is, if you set `Accept-CH(-Lifetime)`:
- Requests for same-origin subresources will carry client hints (up until the max-age if you specify the lifetime).
- Requests for non-same-origin subresources will not carry client hints if the other origin doesn't set `Accept-CH-Lifetime`.
- If you load third-party resources from an origin which sets `Accept-CH-Lifetime`, requests from your origin to the third party will carry client hints.
- Requests from other origins (which don't set `Accept-CH`) to the third party will not carry hints.

I realize this reduces the "on by default" benefit you mentioned, but it seems like a relatively simple opt-in for the first party (which is already a necessary condition in `Accept-CH`) and it mitigates the risk of enabling passive tracking of users based on client hints, which I assume will evolve to expose more interesting data. As you mentioned above, this would also make the Referrer discussion moot (and I agree that controlling client hints via Referrer Policy seems awkward).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-316667172

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 21 Jul 2017 08:12:17 -0700

Would double-keying have material effect on this though? Yes, implementing it this way reduces passive fingerprinting, but only for the very first visit. Nothing prevents every 3P origin from advertising a blanket opt-in policy (in fact, I expect that's exactly how image CDN's will implement it), which will result in same exposure for any repeat visit. Also, as a side effect, double-keying would expose first vs repeat visit bit?

I'm not ruling it out, but it's not clear to me that it would be a big win in this context?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-317027949

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 21 Jul 2017 16:31:10 +0000 (UTC)

@arturjanc started a branch @ https://github.com/httpwg/http-extensions/pull/373 - ptal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-317047991

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 22 Jul 2017 08:19:17 -0700

Re: double-keying, the point is that if you're visiting a first party _without_ Accept-CH then the browser wouldn't send client hints to a CDN even if it sets ACL. Essentially, if you have a first party which wants to use client hints they can opt into them and then their non-same-origin subresources can gets hints if their providers also set ACL (which is fine because the first party could manually pass the hints in the URLs anyway). This prevents CDNs and other origins from which subresources are loaded from getting hints during the user's visit to non-cooperating sites, but should still offer the benefits you're looking for in cases where both parties opt in.

I commented on https://github.com/httpwg/http-extensions/pull/373 -- it looks good to me in general, modulo the broader double-keying issue (which I believe is important).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-317190397

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 22 Jul 2017 15:33:33 +0000 (UTC)

Artur: makes sense, thanks. 

@yoavweiss @tarunban curious to hear your thoughts on double-keying. Any implementation gotchas here that we should think through?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-317191115

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 24 Jul 2017 16:02:43 +0000 (UTC)

No implementation gotchas wrt double-keying.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/372#issuecomment-317469814