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

[Emily Stark <[e-mail]>]

On Thu, Nov 24, 2016 at 2:10 AM, Mark Nottingham <[e-mail]> wrote:

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

A feature could always define its own fallback to headers, couldn't 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 <[e-mail]> wrote:
> >
> > On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <[e-mail]> 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/
>
>
>
>
>