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

From: HTTP issue updates <[email-masked]>
Date: Wed, 04 Apr 2018 20:47:19 +0000 (UTC)

I'm not sure I understand. In your non-browser app example, will the opt-in origin not delegate permission to another origin but the app will choose to send Client Hints to that other origin anyway? Is there a reason that behavior needs to be considered conformant? Or just that delegated permission will be communicated in a different way than Feature Policy for non-browser clients?

Re-reading this thread, it seems like maybe "some or all" is here because `Save-Data` is considered a special case where first-party opt-in won't be required. That seems like something that could be explicitly stated, rather than needing to dig through issue threads to discover.

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

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 10 Apr 2018 16:20:59 +0000 (UTC)

https://github.com/httpwg/http-extensions/issues/372#issuecomment-350352022

> I'm not sure I understand. In your non-browser app example, will the opt-in origin not delegate permission to another origin but the app will choose to send Client Hints to that other origin anyway…

The latter. Let's say I'm building a native game app, with assets living on one or multiple CDNs which I know and trust upfront. I may encode my "delegation decision" directly into my code (by appending appropriate CH hints on outbound requests) that's responsible for initiating the fetches; all of this work lives outside of a webview/browser. Which is to say, CH is not browser specific and we should allow for non-FP delegation mechanisms. 

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Apr 2018 20:37:28 +0000 (UTC)

Gotcha. So it sounds like there is agreement that non-browser clients should restrict delivery unless there is explicitly delegated permission, and just that in the non-Web case that permission might be delegated through means other than Feature Policy, e.g. internal policy implemented through server/client code.

Can we remove "some or all" or explicitly note the hints that aren't restricted to particular origins? Do we want this to be SHOULD even if it applies to all kinds of servers/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-380587682

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Apr 2018 21:53:24 +0000 (UTC)

> Can we remove "some or all" or explicitly note the hints that aren't restricted to particular origins? 

As outlined in https://github.com/WICG/feature-policy/issues/129, in some cases the default "delegation policy" can be "*" — i.e. deliver to all. Concrete example today is Save-Data, where Chrome decided to deliver this hint on all requests when Data Saver feature is enabled. As such, I think we need to keep the "some or all".

> Do we want this to be SHOULD even if it applies to all kinds of servers/clients?

"MUST ... some or all" doesn't seem right? In fact, I'm wondering if I ought to convert all the capital terms in that sections to non-normative.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Apr 2018 23:13:39 +0000 (UTC)

Generally, 2119 requirements in Security Considerations are a bit weird / frowned upon. Requirements are to improve interop; general advice to specifications and implementations aren't what they're for. 

Also, the W3C TAG has expressed some sadness about these requirements. So personally I think that turning this text into prose is appropriate, FWIW.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Apr 2018 17:20:27 -0700

Can the TAG have written comments somewhere so we can understand that better?

I agree that 2119 language is intended for interop. Sometimes knowing which things require permission and which don't is both a security consideration and important for interoperability of implementations.

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

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 11 Apr 2018 17:23:19 -0700

TAG discussion is here: https://github.com/w3ctag/design-reviews/issues/206

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