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

From: HTTP issue updates <[email-masked]>
Date: Thu, 07 Dec 2017 20:24:05 +0000 (UTC)

How important it is to expose client hints to third party domains? It seems that even now (without Accept-CH header) first party can provide client hints to the third party domains as URL parameters. In that case, I wonder if it is worth the effort to tie Accept-CH for third-party with Feature Policy, or we should just: (i) Restrict Accept-CH to only first part domains; and, (ii) Let first party use URL parameters to pass on the client hints to third parties.

The goal of Accept-CH was to provide client hints to the first parties in the very first HTTP request itself. Restricting third party access by default does not affect that goal, so I am in support of it.

-- 
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-350083775

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 08 Dec 2017 19:33:54 +0000 (UTC)

> How important it is to expose client hints to third party domains? It seems that even now (without Accept-CH header) first party can provide client hints to the third party domains as URL parameter…

That's precisely the problem we're trying to solve, you shouldn't have to jump through these hoops as it doesn't play well with caching, and doesn't work for dynamic preferences (e.g. save-data, memory, etc) where the URLs would have to be dynamically generated for each request and enumerate all the hints. This _is_ what some sites already do today, but it's gnarly and complicated solution that doesn't play well with edge delivery / hinders automation of this space.

> My main outstanding worry is indeed the "hint delegation" issue you mentioned above: specifically, the fact that opting an origin into receiving hints still results in sending hints on subresources by default if the 3p also opts in, potentially giving it information about the referring page that it wouldn't currently receive. Similarly, such 3p origins hosting subresources used by an Accept-CH-enabled origin would start getting hints which disclose a few bits of information about the user and could be used for opportunistic linking across 1p visits to different Accept-CH-enabled origins.

Can you elaborate on a particular use case or example that you're worried about here? I hear your concern, but I'm not convinced that the real risk is any more significant than what is already exposed by most sites to 3P's through active content (or CSS even). 

> What do you think about flipping this around and only sending hints on 3p subresource requests if the origin is explicitly whitelisted via Feature Policy? 

On a tactical (spec language) level, FP is a UA-specific concept and I don't think we can couple it here with CH; FP does not apply to non-UA clients. On the other hand, a UA may choose to define a "default off" FP policy for CH for 3P origins and that's totally fine: that's an implementation decision of the UA, and different UAs may even chose different policies for different hints, instead of applying a blanket policy for all CH hints - e.g. Chrome communicates Save-Data hint to all origins today if data saver feature is enabled.

As such, I think we can add some language in CH to explain and allow for above implementation options, but I don't think we can dictate a default FP policy in this spec. 

Spec language bits aside, and with respect to UA implementation: I think we should have a more detailed conversation, on a hint-by-hint basis, to determine default on/off policies, and I'd suggest that we move that discussion to FP forum. 

Does that sound reasonable to you guys?

-- 
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-350352022

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 11 Dec 2017 17:53:32 +0000 (UTC)

> Can you elaborate on a particular use case or example that you're worried about here? I hear your concern, but I'm not convinced that the real risk is any more significant than what is already expo…

I'd set aside the case of fully active content and focus on 3p resources that do not allow the hosting party to get information that would be exposed in hints (i.e. loading content such as images, fonts, audio/video, or even JS/CSS pinned to a specific version via Subresource Integrity). If a website loads such resources -- which is very common -- and it enables hints, *and* the 3p separately also enables hints, it has two consequences:

- The user will start sending hint information to the third party, which may allow the 3p to correlate requests from that user across different 1p sites which use hints, even if third-party cookies are disabled. The hints will also be sent automatically, rather than require active probing, which will result in potentially fingerprintable information being sent out to third parties which either couldn't obtain it, or which likely wouldn't resort to actively detecting it and sending it out.
- The user will start sending hint information which might tell the 3p which website/page the user is on, even if the website uses Referrer Policy to remove the Referer header (e.g. in the case where the 3p knows their resource is being loaded by 10 other sites, and only 1 of them enables the set of hints they see in the request).

This behavior is arguably worse privacy-wise than the status quo for users of sites which enable hints. I like being able to control 3p hints via FP, but developers won't understand why they might want to do it (partly because the third-parties they load data from might not enable hints until later, so the developer would not see them in 3p requests while testing on their sites).

FWIW I do think this is strictly better than the original proposal, so "3p hints should be off by default unless enabled by Feature Policy" is not a hill I'd want to die on. Solving this with safe defaults at the FP level sounds okay; I'm a little wary about relying on a completely independent mechanism to enforce good privacy properties of client hints, but it's probably workable -- we'd just need to have the FP-focused discussion about this.

-- 
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-350803441