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

From: HTTP issue updates <[email-masked]>
Date: Fri, 06 Oct 2017 10:36:51 -0700

@mnot @yoav I'm _not_ suggesting we rebase the entire opt-in mechanism against FP — it's also not sufficient on its own because, as you pointed out, it's missing ACHL semantics amongst other things. Rather, I'm suggesting that we should separate these concerns: 

- Accept-CH + Accept-CH-Lifetime define a mechanism for origins to advertise their hint and hint lifetime preferences for subsequent visits; these two primitives are used to negotiate what hints will be made available to the origin.
- With above in place, delegation is — I claim — a separate and complex enough problem that deserves its own treatment. As it happens, that's what FP is solving, and we should leverage that. 
  - We _can_ still make a default double-keyed recommendation for 3P opt-in.
  - We _can_ define default hint policies in terms of FP primitives.

Yes, we are coupling two mechanisms here, but delegation is not an easy problem and I'd much rather we reuse mechanisms than try to blaze yet another trail here. Also, it's true that FP is designed with browser in mind, but there is no reason why it can't or shouldn't work with other types of clients.

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 06 Oct 2017 18:56:43 +0000 (UTC)

Updated https://github.com/httpwg/http-extensions/pull/373 with outstanding feedback — ptal. 

As a quick recap, with #373 we have:
 - Accept-CH and Accept-CH-Lifetime are the mechanisms to advertise support and lifetime prefs.
  - Both are scoped to secure transports.
  - Preference is bound to the origin / double-keyed.

Current update does _not_ address delegation. As proposed above, I'm suggesting we solve that part of the problem via Feature Policy. If that sounds reasonable, I can add some language in #373 to outline how/where this should be defined.

WDYT?

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 13 Oct 2017 14:30:57 -0700

@arturjanc @mnot @yoavweiss friendly bump.. :bowtie: 

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 25 Oct 2017 16:32:15 +0000 (UTC)

Is this fixed?

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 26 Oct 2017 00:25:41 +0000 (UTC)

I think it'd be good to see #373 in situ; from what I see in the patch, I think it's strictly better. No guarantees that there aren't other issues, or that this isn't completely covered, but personally I think it's better.

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

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 27 Oct 2017 19:21:37 +0000 (UTC)

I've landed #373. As a tl;dr on substantive changes: 
- Accept-{CH,CH-Lifetime} opt-in is scoped to secure transports
- Opt-in preference is bound to opt-in origin

In effect, this update makes Client Hints HTTPS-only and opt-in preference is double keyed against opt-in origin. We've also updated [security considerations section](http://httpwg.org/http-extensions/client-hints.html#security-considerations) to reflect these updates.

---

The one remaining thread raised in this issue is around "hint delegation": if origin A is loading a subresource from origin B, can A control if B is allowed to opt-in to receive hints? As it stands today, the answer is "yes", and CH does not define a mechanism to control this.

I do think this is a valid use case, but I don't think we should be solving it within CH directly. Rather, we should be reusing client specific infrastructure to address this.. e.g. in a context of a browser that's [Feature Policy](https://wicg.github.io/feature-policy/), which provides a mechanism to selective enable/disable features and defines relevant delegation mechanisms — e.g. policy based, frame-level control, cascading logic, etc.

So, my proposal here is:
 - @arturjanc I believe we addressed your original concerns via #373. 
    - We can resolve this thread
    - Publish new 05 draft with updates in #373
 - Pursue delegation discussions in context of Feature Policy.

@arturjanc @mnot does that sound reasonable?

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