Resent-Date: Thu, 24 Nov 2016 09:52:16 +0000
Resent-Message-Id: <E1c9qhU-0006y4-Qw@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAKXHy=d18Zy-khibw78iC5i=8iOu2v_M2VS_aKV2jOexp8=gBg@mail.gmail.com>
Date: Thu, 24 Nov 2016 20:51:36 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>,
 "Emily Stark (Dunn)" <estark@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB8DEE1D-0BDA-4737-B957-92EC9CDAC2FA@mnot.net>
References: <147995400666.32746.15867339667353417986.idtracker@ietfa.amsl.com>
 <FCDFC352-5D68-456F-AFF4-39E9E1697AF2@mnot.net>
 <CAKXHy=d18Zy-khibw78iC5i=8iOu2v_M2VS_aKV2jOexp8=gBg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net;
 helo=mxout-07.mxes.net
Subject: Re: New Version Notification for
 draft-nottingham-site-wide-headers-01.txt
Archived-At: <http://www.w3.org/mid/BB8DEE1D-0BDA-4737-B957-92EC9CDAC2FA@mnot.net>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hey Mike!

> On 24 Nov. 2016, at 8:33 pm, Mike West <mkwst@google.com> wrote:
>=20
> On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <mnot@mnot.net> =
wrote:
> FYI, updated draft.
>=20
> Prettier (and latest) version available at:
>   https://mnot.github.io/I-D/site-wide-headers/
>=20
> 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. :)
> =20
> 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.
>=20
> 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/
>=20
> 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).=20

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.=20

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)).
>=20
> 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/