Subject: Re: [httpwg/http-extensions] Scoping of Accept-CH (#307)

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Mar 2017 17:13:30 -0800

> The primary use case for CH as I understand it is serving appropriate subresources, NOT dynamically modifying HTML, so that should do the trick.

With the benefit of few years of experience, absence of hints on the initial request has proven to be a major limitation that prevented wider adoption. In practice, many of the most critical decisions about page format are made when the HTML is generated -- e.g. whether you should serve "light" version of the page, picking resource density, ..., and feature-detecting support for CH to begin with. In short, we do need to allow hints on navigation responses.

> "Send CH headers on subrequests generated by this content, please."

I think that's a reasonable definition for `Accept-CH`, iff we also combine it with `Accept-CH-Lifetime` proposed in https://github.com/httpwg/http-extensions/issues/306 to cover the case for initial navigation. Concretely, the proposal here would be: 

- Scope down `Accept-CH` to "subsequent requests generated by this content"
- Define `Accept-CH-Lifetime` to allow opt-in to be remembered for specified period of time. 
  - When this is present, opt-in applies for all content that belongs to the origin.

-- 
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/307#issuecomment-284113236

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 04 Mar 2017 03:50:31 -0800

DNT has a mechanism for determining if the DNT:0 header sent to subresources, a JS API for specifying "site-specific" consent. This also can specify lifetime by having an "expires" or "maxAge" property in the parameter dictionary for the call.  

The TPWG has discussed using cookies as a more generic method, but the SOP gets in the way (you cannot limit the state to a top level context).

The Accept-CH header is similarly determining stateful site-specific behaviour for subresources, perhaps this points to a generalised solution? Especially as there are privacy/user control issues in common?

I am thinking about a well-known cookie prefix (as proposed for RFC6265bis) that would cause the cookie to be sent to subresources in the cookie header, but only within the context of the parent that placed it. The existence of particular forms of this well-known cookie could then determine UA behaviour (such as sending Client Hints to subresources).

Implementation would be simpler because the expiry procedures are already in place.

A further advantage would then be that the state is automatically contained in the UAs cookie store, accessible to existing privacy oriented UA UIs and extensions, increasing transparency.

For example:

Set-Cookie: __SRAccept-CH=DPR;expires=Sat, 05 Mar 2017 00:00:00 GMT

-- 
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/307#issuecomment-284146721

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 05 Mar 2017 21:40:35 -0800

@igrigorik - Just thinking through doing this, a couple of questions --

It seems like there are a lot of potential dimensions that the server's preferences for sending CH could vary -- e.g., same-origin vs. third-party, navigation vs. subresource, etc. Are we offering the right capability (all requests from a given origin) here?

Will having one `Accept-CH` policy for an entire origin work? What if different resources need different headers? How should clients behave when they get conflicting lists of headers and/or lifetimes for a given origin?

Using a cache to determine whether to sent hint headers means that the initial navigation request to a given origin won't have them, so any behaviour that depends on them will need a fallback. Is that just going to be "serve the heavier page", or something more complex?

-- 
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/307#issuecomment-284307644

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Mar 2017 04:51:14 -0800

> It seems like there are a lot of potential dimensions that the server's preferences for sending CH could vary -- e.g., same-origin vs. third-party, navigation vs. subresource, etc. Are we offering…

Based on the experience and feedback so far.. yes. It's the simplest strategy that covers all the use cases, and everything else just adds more configuration and implementation complexity.

> Will having one Accept-CH policy for an entire origin work? What if different resources need different headers? How should clients behave when they get conflicting lists of headers and/or lifetimes for a given origin?

Last registration wins, similar to HSTS.

> Using a cache to determine whether to sent hint headers means that the initial navigation request to a given origin won't have them, so any behaviour that depends on them will need a fallback. Is t…

The former. Practically speaking, sites can't rely on CH hints being available from every browser in any case, so they need a fallback strategy regardless.

-- 
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/307#issuecomment-284387675

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 17 Mar 2017 10:43:55 -0700

@mnot @mikewest would love to hear your thoughts on the cookie opt-in idea floated above.

`Set-Cookie: __Secure-Accept-CH=DPR; Secure; Path=/images; Expires=<date>`

- It does provides more flexibility than the origin wide opt-in -- e.g. customizable by path, etc.
- It's visible to the user and subject to all other cookie policies and workflows.

Do we have any other precedents that use cookies for feature opt-ins? Any gotchas with going down this path, spec/layering and implementation wise? It's also unclear to me whether we'd really need to invent new prefixes.. hoping the answer is "no". 

-- 
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/307#issuecomment-287423778

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 17 Mar 2017 12:07:12 -0700

>From a practical perspective, this sounds expensive if we need to consult the cookie monster for every request. I suspect that we'd internally need to turn this into something like HSTS where we store the pins distinctly from cookies, at which point we lose much of the elegance of the proposal, I think.

>From a theoretical perspective, this is breaking new ground. We don't have any other special-purpose cookies that I know of. We'd need to reserve the name in some way (which is absolutely doable, if odd). Also, cookies have terrible scoping rules. The less eTLD+1 we have, the better, from my perspective.

>From a pinning perspective, spelling the pin as `Set-Cookie` vs `Set-CH-Disposition` or something is not terribly concerning. The server is expressing a preference, and we're caching it locally. The general idea of pinning that kind of preference seems fine to me. I'd prefer to see it done via origin policy, but I still haven't found anyone to implement that (nor have I addressed @mnot's feedback on the spec... :( ).

-- 
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/307#issuecomment-287445118

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 17 Mar 2017 14:21:56 -0700

> From a practical perspective, this sounds expensive if we need to consult the cookie monster for every request. I suspect that we'd internally need to turn this into something like HSTS where we st…

Right, you confirmed my main worry. Solving this problem via cookies is doable, but brings a lot of unrelated complexity that I'd much rather avoid. I'm inclined to keep things simple and...

- Define a standalone `Accept-CH-Lifetime`, as proposed in https://github.com/httpwg/http-extensions/issues/306#issuecomment-283549512
  - Give it origin-wide scope -- no subpaths, etc.
  - Pin expires based on specified lifetime, or whenever cookies are cleared.
- When we ship Origin Policy developers can just move the pin into their policy and everything will continue working as before.

I'll take a run at a PR for the above.

-- 
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/307#issuecomment-287474419

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 17 Mar 2017 15:28:51 -0700

First run at `Accept-CH-Lifetime`: https://github.com/httpwg/http-extensions/pull/313 - 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/307#issuecomment-287486957

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 18 Mar 2017 02:14:30 -0700

Doesn't "the cookie monster" have to be consulted anyway for every request? If only to work out what to put in the Cookie header?

My idea was  mainly to give  users (and privacy protection extensions) the ability to detect the existence of the CH state by keeping it in the same place as cookies, where there already exist UIs etc. for seeing/dealing with them.

If a parallel system is implemented to manage CH state (with expiry etc.) then there would also be a need for similar UIs, API to support extensions etc. For cookies that already exists.

It is true the scoping rules are horrible, but they do not need to be used for these special prefixes. The "secure" attribute already restricts scoping for some 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/307#issuecomment-287528345

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Mar 2017 10:31:01 -0700

Closed #307 via #313.

-- 
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/307#event-1015747970