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

[Mike West <[e-mail]>]

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

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

I'm fine with changing origin policy to just a JSON-based policy
definition. That said, I'm not sure it gains us much if we agree that it's
important to deal with the existing headers that developers are using
today. That is, spelling things `{ "headers": [ { "name":
"referrer-policy", "value": "origin", "type": "fallback" } ] }` is more or
less the same as spelling the same intent `{ "referrer-policy": { "value":
"origin", "override-policy": "something" } }` If anything, I think
pretending that we're not talking about a header in these resource-specific
cases is actually more confusing when it comes to the fallback/baseline
distinction.

I think I'd agree, though, that it makes more sense for the existing
site-wide headers: `{ "transport-security": { "max-age": 10886400,
"subdomains": "include" } }` is simpler to understand than the existing
header-based syntax.


> 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 :)
>

I think having a header-based system for response-specific headers like CSP
makes a lot of sense. I'm less enthusiastic about forcing ourselves into
headers for everything going forward.


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

Honestly, Emily is not going to block on this regardless. Even if everyone
shook hands and agreed to implement exactly the -01 site-wide headers
today, it wouldn't be stable in time to be useful.

I'm interested in getting the framework right going forward, but I'm
pragmatic about how long that's going to take, and what short term
tradeoffs might be reasonable in the face of that timeline.


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

It would indeed be helpful for more browser vendors to weigh in, as well as
other clients that might be affected.


> 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'm not heavily invested in the existing syntax, but I do think the
featureset the current origin policy draft offers is important. In
particular, the override bits for resource-specific headers like CSP.


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

Just to set expectations, I don't have any running code (nor do I have any
idle hands). This is going to take time to implement in Chrome, regardless
of what we decide. :)

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

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

It would indeed be helpful for more browser vendors to weigh in, as well as
other clients that might be affected.


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

It's certainly a tradeoff. My hope is that we'll more than make up for any
impact with things the feature will enable, like dropping CORS preflights.


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

In my mind, H2 push is the relevant primitive that makes this possible. I
think it would have bad performance implications on the initial fetch if
the client had to issue a separate request in the middle of processing the
main page.

-mike