Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

Hey Mike!

> On 24 Nov. 2016, at 8:33 pm, Mike West <mkwst@google.com> wrote:
> 
> On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <mnot@mnot.net> wrote:
> FYI, updated draft.
> 
> Prettier (and latest) version available at:
>   https://mnot.github.io/I-D/site-wide-headers/
> 
> Thanks for the update, Mark! It seems like we agree on broad strokes: a well-known resource defines a set of things for an origin. Clients can preemptively grab that resource, or a server can push it down. I'm confident in that model, and I expect we'll be able to work out the details. :)
>  
> I talked to a number of folks about this in Seoul, and it seems like some potential implementers have a preference for a header-based approach, rather than creating a JSON data structure with semantics that diverge from headers.
> 
> This is my gut feeling too, but it could be that they were agreeing with me because I was there. Another approach is suggested by Mike West here:
>   https://wicg.github.io/origin-policy/
> 
> The differences between our proposals seems to boil down to how we wish to model the "things" that are defined for an origin. The "site-wide headers" proposal runs with the status quo, HTTP-based approach of response headers that have origin-wide impact, and standardizes a mechanism of distinguishing those headers in the future. The "origin policy" proposal seems like a superset of that approach, allowing legacy headers to be pinned origin-wide, while also making room for policy definition in a non-resource-specific way. That seems like a better long-term model to me.

Agreed. There are smaller differences around things like syntax and how change is handled, but this is the big one.

The feedback I've had in side conversations so far is that doing it both ways is adding complexity to the platform; it's more clean if there's just one mechanism at work. As a result, I previously suggested changing your proposal so that it's *just* JSON-based policy definition, without any reference to HTTP headers. Sorry I haven't gotten around to making that pull request.

However, more recently I've heard from a number of folks that having HTTP header capability is preferable, which is why I revved my proposal (OK, I also did that to try to kick start this discussion :)

Doing it in a headers-based fashion also has the bonus that proposals like Emily's don't have to block on having this defined.

I'm happy to have my mind changed on all of this. I'm especially happy if there's clear consensus in the community on one end of the spectrum or the other.

Personally, I'd be slightly unhappy if we adopted your current proposal (because it tries to do both things, and that seems overly complex), but would be just fine if we decided to do JSON-based policy definition without reference to HTTP headers (presumably finding a non-generic way to map existing site-wide headers into it, maybe even by just nominating them, rather than putting them in a generic 'headers' bag). 

I would be really really really happy if we decided *anything* relatively quickly, because there are a few opportunities coming up to use such a beast, and I've been gently pushing various proposals along these lines for years.

> Historically, response headers have been the most convenient way of establishing origin-wide policy, because they exist and developers can easily poke at them. It's easier to alter application code to send a new `Strict-Transport-Security` header rather than, for instance, altering an HTTP server to send new data as part of a TLS handshake. The mental model, however, is muddled at best, elevating any arbitrary resource to govern the entire origin.

Agreed. That's where we're at. One of the side benefits of the recent changes I made was that it identifies new site-wide headers with a prefix.

> The site-wide headers proposal extends this pattern, envisioning a future where we have a few legacy site-wide headers with strange names, and more modern site-wide headers with a `site-` prefix. Any arbitrary response may still exercise control over the site, and each new feature must be modeled as a response header. I'd prefer to avoid both of these implications.

I don't know that we can ever get away from an arbitrary response exercising control over the site, when you consider the entire stack; so many features are on a per-origin (or with cookies, greater) scope. 

WRT the latter; HTTP headers aren't a great model, but we're working to make them better. What they have now is developer familiarity. I'd really prefer to avoid making things conceptually more complex if we can.

> In fact, I'd suggest that both of our proposals implicitly recognize this as folly, and choose instead to endow _only_ a particular resource with origin-wide authority. Neither proposal uses that resource's response headers to set the policy, but instead the resource's content. I think we're only talking about headers at all because of historical precedent, and I'd be pretty happy limiting origin-policy's header-based mechanism to something like the list in https://mnot.github.io/I-D/site-wide-headers/#rfc.section.1.1 (probably with some additions for headers whose ship has sailed, like Emily's `Referrer-Policy`).

I think we're thinking along the same lines here...

> I'm happy with that legacy behavior for things like CSP, because `Content-Security-Policy` is quite explicitly a resource-specific header with resource-specific implications. Modeling it as part of a particular response (even if it's set on an origin-wide basis) seems reasonable: the developer is claiming "Each of the resources on this origin will have a policy something like this, but they might differ a bit." `Referrer-Policy` and `Access-Control-Allow-Origin` are similarly resource-specific. The origin policy proposal tries to recognize this by giving explicit "baseline" or "fallback" options for overrides (https://wicg.github.io/origin-policy/#dom-httpheader-type (regardless of the approach we take to headers, this bit seems critical to me)).
> 
> I'd contrast that legacy behavior with something like the `cors-preflight` controls sketched out in https://wicg.github.io/origin-policy/#cors-preflight-member. Things like this don't make much sense to me as an HTTP response header for any particular resource, nor could they reasonably differ between resources. The origin's owner is making declarations about the way Fetch ought to work for the origin at large, independent of any particular response. I'd very much prefer not being forced to model it as a `site-cors-preflight: whatever` header. Likewise, I'd much prefer to suggest to Future Emily that she define a new `certificate-transparency` member in an origin's policy manifest rather than a new `Site-CT` header.

Understood. What do others think?


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 24 November 2016 09:52:09 UTC