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

From: HTTP issue updates <[email-masked]>
Date: Thu, 10 Aug 2017 14:07:46 +0000 (UTC)

Apologies for the late reply (was exploring the Canadian wilderness...)

I don't see a particular problem with double keying but I also don't to see the privacy advantages of it. As @igrigorik said earlier, all third parties will add an automatic ACHL and will get the hints as soon as the main document opts-in, meaning the situation will not be different from today.

I think the concerns that @arturjanc raises are real and ACHL will expose new information regarding origins that are not capable of running scripts in the context of the page, new info regarding viewport, DPR and network conditions that they don't currently have. 

Maybe we need `Accept-CH-Lifetime` to be able to define a list of hosts that will get subresource hints? I vaguely remember us discussing a proposal in that spirit in the past, but failing to find references to such a discussion.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 14 Aug 2017 14:08:19 -0700

*not chair hat*

Could we please stop calling this use case "CDN"? Most CDNs take all traffic for an origin, not just images, etc. (that's very 1999). It's true that some sites direct images.* to a CDN (for example), but that's not great practice.

We should really be talking about this as 3rd party content -- e.g., widgets and ads. Given the history there, it's entirely reasonable to be concerned about increasing fingerprinting exposure.

Requiring the origin to opt-in to any 3rd party CHs is an improvement, but not a huge one; it'll just give an incentive to 3rd parties to instruct the origin to set whatever policy we require.

I think that at a minimum, we should warn (Security Considerations) specifically about the new vector for 3rd party content fingerprinting here, and allow implementations to decide whether they send it to 3rd parties (at all, or when they're in private browsing mode, or...).

I'd like to also see at least consideration of making this 1st party only. Given that the use case for CH is mostly to allow intermediaries to do content optimisation -- and remembering that origins already have other techniques available to them -- I'm wondering if allowing third party origins to do intermediary-imposed optimisations is worth the potential privacy tradeoff here. After all, widgets and ads are usually served by `script` tags, so there's an opportunity for script running and URL rewriting by them before the requests are made. 

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 17 Aug 2017 07:24:19 -0700

> Could we please stop calling this use case "CDN"? Most CDNs take all traffic for an origin, not just images, etc. (that's very 1999). It's true that some sites direct images.* to a CDN (for example…

While we can argue that in an H2 world this is not the best practice, having a separate domain for images is not uncommon. e.g. looking at https://www.nytimes.com/ its images are served from https://static01.nyt.com. All served from the same CDN (and covered by a single cert AFAICT), but still considered a third party from a SOP perspective. It's also not uncommon to have separate certs to such "static domains" as an infosec requirement.

So I don't think we can consider sending CH to third parties as something that will only benefit 3rd party content.

> Requiring the origin to opt-in to any 3rd party CHs is an improvement, but not a huge one; it'll just give an incentive to 3rd parties to instruct the origin to set whatever policy we require.

They can similarly add requirements for the origin to include their JS that will beacon up that data to them. There's very little we can do about that other than trust the first party's judgement (and make them aware of what they're enabling).

> I'd like to also see at least consideration of making this 1st party only.

That would exclude many legitimate use cases, as discussed above.

> After all, widgets and ads are usually served by script tags, so there's an opportunity for script running and URL rewriting by them before the requests are made.

If they run a script in the context of the main page, they can easily exfiltrate that data, which is available through JS APIs.

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 17 Aug 2017 11:25:14 -0700

Hey Yoav. Absolutely, but the Web security model doesn't have any concept of CDN; images.* is a third-party host as far as same-origin is concerned.

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 18 Aug 2017 08:14:30 +0000 (UTC)

> Absolutely, but the Web security model doesn't have any concept of CDN; images.* is a third-party host as far as same-origin is concerned.

Indeed. All I'm saying is that exposing CH to such "first party owned third parties" is a legitimate and very common use-case. I'd prefer we'd find ways to address that use-case (with appropriate means to maintain user-privacy), rather than block 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-323290110

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 22 Aug 2017 04:56:30 -0700

I agree. If subresources can use CH then it is bound to be misused. The trend is to further restrict access to third-party cookies e.g. Safari’s ITB, so there will be more incentive to find other ways to track. CH headers allow that to be done much more efficiently as there is no need for an extra roundtrip.

From: Mark Nottingham [mailto:[email-masked]] 
Sent: 14 August 2017 22:08
To: httpwg/http-extensions <[email-masked]>
Cc: Subscribed <[email-masked]>
Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372)

not chair hat

I'd like to also see at least consideration of making this 1st party only. Given that the use case for CH is mostly to allow intermediaries to do content optimisation -- and remembering that origins already have other techniques available to them -- I'm wondering if allowing third party origins to do intermediary-imposed optimisations is worth the potential privacy tradeoff here. After all, widgets and ads are usually served by script tags, so there's an opportunity for script running and URL rewriting by them before the requests are made.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://github.com/httpwg/http-extensions/issues/372#issuecomment-322310307> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBCIiiv1BMQTWukQ1wp7quM0rkBOSPIks5sYLdDgaJpZM4Oc7TI> .  <https://github.com/notifications/beacon/AEBCIlrrWLn9EzxuNg8YL3AMZpCG-Yemks5sYLdDgaJpZM4Oc7TI.gif> 

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 13:26:53 -0700

Thanks everyone for the feedback. 

Nomenclature discussions on "CDN" vs.  "widget" vs "3P" aside, I agree with Yoav that subresource optimization is a _critical_ use case for CH and not something we can omit. It may be the case that some particular hints make sense to be scoped to first-party only, but that's a discussion we should have in the context of individual hints; as a general mechanism, CH must support delivery of hints to all origins, possibly with knobs for 1P origin to control which 3P origins are allowed to receive hints. 

**Current proposal for `Accept-CH-Lifetime` is to allow hint preferences to be registered by any origin.** The limitation, as pointed out in discussion above, is that it doesn't provide any distinction between 1P or 3P opt-in. To that end, we discussed a few options:

1. We can add double-keying to scope 3P registrations to within 1P origin — i.e. 3P registration on foo.com does not propagate to same 3P origin on bar.com.
1. We can further restrict 3P ability to register for hints by requiring that 1P opts in for receiving CH hints — i.e. what @arturjanc proposed above.

FWIW, I think (1) is the right behavior, from a user perspective. However, what it doesn't address is the 1P -> 3P delegation case where 1P origin may want to control if (and which) 3P is allowed to request CH. @arturjanc's proposal (b) is an attempt at this, but a fairly blunt one: 3P is allowed to receive hints if 1P opt's in, but this is a blanket policy for all 3P origins and it similarly doesn't provide any fine grained control for which hints are allowed to be requested. If we all agree that the "1P -> 3P hint delegation" use case is an important one, I think we need to explore mechanisms beyond (b). 

To that end, squinting at this space, I see close parallels to Feature Policy: we have features (hints) that we want to selectively enable/disable, and we may want to scope them to a list of origins — e.g. enable them for "self" / 1P only, selectively enable them for some set of origins, or disable them outright. And so, here's my crazy proposal of the day: 

1. ACL registrations should be double keyed -- see (1).
1. Control over which hints are enabled, plus delegation, should (?) be addressed via Feature Policy. 

```
Feature-Policy: {
   "ch-dpr": ["self"],  // DPR hint is 1P only
   "ch-ex1": ["self", "foo.com", "bar.com"],  // ex1 hint is 1P + select 3P
   "ch-ex2": [] // ex2 hint is disabled for everyone
} 
```

The other benefit here is that this opens a well-defined way to think about a "default FP policy" for each hint. For example, some hints may be restricted by the UA to be 1P only, other may be on-by-default for everyone (e.g. save-data), and others may be off by default.

WDYT? Crazy talk? :)

/cc @clelland @rbyers

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 21:45:26 +0000 (UTC)

It's not the craziest thing I've read today :)

It's a bit mind-stretching to think of these as features, but it definitely is a kind of power or trust that is being delegated to other origins by the embedding page, so it's not *too far* from the goals of feature policy.

One question I would bring up would be regarding the inheritance of ACL in deeply-nested frame trees -- Feature Policy's model is that once disabled in an frame, a feature can never be reenabled by any subcontent; I wouldn't want to break that invariant without a real compelling case.

With the FP model, if `a.com` embeds `b.com`, and does not grant it the ability to receive hints, then it is not possible for `b.com` to embed a fourth-party, `c.com`, and have hints sent to *that* domain instead. That sounds like desirable behavior to me, but I don't think it's been brought up on this thread yet.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 21:51:40 +0000 (UTC)

I think FP's current inheritance behavior makes perfect sense in this context as well. If I disable use of a particular hint on my site, I expect this policy to propagate to all nested frames.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 15:52:41 -0700

> If we all agree that the "1P -> 3P hint delegation" use case is an important one

Naive question: IIUC, any information that can be obtained by an origin via client hints can also be obtained by that origin using a combination of Javascript and cookies. Is it currently possible for 1P origins to control Javascript/cookies behavior of 3P origins?

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 23:12:09 +0000 (UTC)

At a high level, I am not sure why the client hints permission for foo.com is not the same as (permission for foo.com to run Javascript AND permission for foo.com to store cookies)?

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 30 Aug 2017 23:19:57 +0000 (UTC)

@tarunban the key difference here is passive content (e.g. images, audio, video, etc): today such resources/origins cannot obtain data that we expose with CH, unless there is active content executing in top level page and scheduling their fetches. I think it's reasonable for origins to have control over whether such passive content providers should be able to request data exposed by CH.

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 31 Aug 2017 04:20:15 +0000 (UTC)

Really interesting, Ilya. It *is* a big change :)

On the face of it, it seems workable. Feature Policy doesn't have a concept similar to `Accept-CH-Lifetime`; would that move into FP, or remain CH-specific?

I'm not crazy about the verbosity of `Feature-Policy`, nor the (relative) complexity. Also a bit concerned about making such a prominent part of CH an external dependency -- especially since FP is effectively browser-specific, whereas I suspect at least some people want CH to be applicable to other HTTP clients.

Still digesting...

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 31 Aug 2017 07:34:00 +0000 (UTC)

Interesting indeed!
a few thoughts:
* FP's inheritance model makes some sense, but *is* more restrictive than info that iframes currently have (as iframes are *not* passive content). Would've been great if we could limit exposure of privacy sensitive info to 3rd party passive content while enabling it for active content (by allowing new contexts to override). One use case I can think of is an ad iframe that wants to do the right thing in terms of DPR/viewport based image compression will now require all embedding sites to opt-in, which most won't.
* This will obsolete `Accept-CH` entirely, correct?

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