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

One other thing --

If we take an approach that doesn't allow fallback to headers for new features, it's going to be important to get broad buy-in from implementers. Otherwise, it'll raise the friction for those new features.

For example, if Expect-CT were to adopt it, and browsers were now required to make an extra fetch to implement the spec, some might not like that, and resist implementing it.

This has been the case when we've discussed similar approaches in the past; the extra fetch -- even when not on the critical path -- adds friction. If that's changed, it's great news -- but we should verify that.

Cheers,


> 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.
> 
> 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.
> 
> 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.
> 
> 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'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.
> 
> -mike

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

Received on Thursday, 24 November 2016 10:10:47 UTC