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

Mike West <> Thu, 24 November 2016 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 209C51294E0 for <>; Thu, 24 Nov 2016 07:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Hzn2__SW778 for <>; Thu, 24 Nov 2016 07:36:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FAD11294E4 for <>; Thu, 24 Nov 2016 07:36:27 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9w17-0008L9-Av for; Thu, 24 Nov 2016 15:32:53 +0000
Resent-Date: Thu, 24 Nov 2016 15:32:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9w0w-0008Iq-LA for; Thu, 24 Nov 2016 15:32:42 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c9w0p-0001g6-V1 for; Thu, 24 Nov 2016 15:32:37 +0000
Received: by with SMTP id c13so31281578lfg.0 for <>; Thu, 24 Nov 2016 07:32:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tTaNbIi1cx/gC05zFRjS3uBr33+6gnYlr+TPxJoGzYI=; b=LYZ0wlV8v43DjsSOkA886cCUK/0XdSi3H/1LlEKBlG4IrhVsG06tkeg+ePNXX45ORO rOBRryDTnjgDK6AdQuM6FILZtJdMFoSY2Hwm9YSfqzFPGMhRq8ROkocYwDbz/7cJ3n0t 06WvXyKzQRinPB/kQRls/mimLeG4ZWA/fa2lQC/D2el8yBAGf1xZiO2qeAbF6fxAMxr5 G2y9BGAI9Y/Z9TKdWG2L8/QGbOUjrkYy2s7MADvi9s1bRtDhAUy9WveaKSnrDjdjlyYs glrpOTBoCyQlf8fwNE0/61RuZP2H7wC4OefTLI6tA0ZEo7kSD1ZN9p1U/AYlBakBvNM0 xAAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tTaNbIi1cx/gC05zFRjS3uBr33+6gnYlr+TPxJoGzYI=; b=K0qHOVkD+eB4RzcR2s/7A+oYqWM2EmD3rIqaxer+j7YPhB7ddmnbTGim/0ojuhA8bg QC16qFW3W6pQwZ/hns9QJ5apVvGAc1n7+rOrqj4Nu38MtAyHbnuhqBQs2TE9GTmoJmu/ UVwWbFqIYKx8hu8O23NDQVq4I4m1f/sf9Mqi8O9359/5Hm9MIcaZ0FgWt8FUYAE81+59 FeS/ZbJoHx2DSH6MzUR0yOwbPK2ZoYCDtTcW2o8dpaeBZor06FTMxLS6k8sFBh1PH1Gk wKNTA6BxY1JvqQXnyVYfosAXMVXUPzeLH7x8wRVNb4fStpbjvfNaaWYc0qSLQPQlHD54 ztWQ==
X-Gm-Message-State: AKaTC00B1rAe3ih/ND2QKcsNzvKYpPcp4gmu+24SH7a/Y7VAidPSy6NT26jxRiEq78fG0P94OqpAJvLEVE+wyJGk
X-Received: by with SMTP id 5mr1577878ljj.23.1480001529021; Thu, 24 Nov 2016 07:32:09 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Nov 2016 07:31:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Mike West <>
Date: Thu, 24 Nov 2016 16:31:48 +0100
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>, "Emily Stark (Dunn)" <>
Content-Type: multipart/alternative; boundary="001a114b14c667d5d805420db547"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.0
X-W3C-Hub-Spam-Report: AWL=2.947, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1c9w0p-0001g6-V1 52825ef9b25b3a731b1c3be1ead3b5c7
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32994
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Nov 24, 2016 at 10:51 AM, Mark Nottingham <> 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

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