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

[Mike West <[e-mail]>]

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