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

Emily Stark <> Thu, 24 November 2016 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3683129554 for <>; Thu, 24 Nov 2016 08:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.997
X-Spam-Status: No, score=-7.997 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, RCVD_IN_SORBS_SPAM=0.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 WhBwo04L6BdB for <>; Thu, 24 Nov 2016 08:12:48 -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 A879B12989C for <>; Thu, 24 Nov 2016 08:12:48 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9waG-00007q-Ri for; Thu, 24 Nov 2016 16:09:12 +0000
Resent-Date: Thu, 24 Nov 2016 16:09:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9wa9-00006s-Nk for; Thu, 24 Nov 2016 16:09:05 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c9wa3-0001HW-CE for; Thu, 24 Nov 2016 16:09:00 +0000
Received: by with SMTP id x94so85892683ioi.3 for <>; Thu, 24 Nov 2016 08:08:39 -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=TpiR2MAU7g2WDi6z1w0MJXkNOmF562rFDVHJre/r3vU=; b=JjdHD0yhzlrSwqdXR7mmnbmcKovidOR0Kwt2ZA+V/wHtP/AxqdmotE30R1UqrGp37U ll78YTk8AEHBI85+nsZwCR7tz0H5pMQG2CG86knYsRUu1cDq+5s9ixylfffMIL0uwlBC GDi5k3by4plGanwNRdctmvIgYSTHXlP46rnjAOJYveiT+I2wzIL8QATZjvWiuMgU0Hqx +5W2zd+yT0W7LhB9R1EeVrlkC1X8h7p0wecIIC3vCxVlgkTHGrYbO4JTWUU26hyTvRKH rPbpSCEcM3Uc7PkFThDXB8yJLkvgfpEAe63qab6IugtsBioaoU203yWV/KXS1/9+p1Gr XT3w==
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=TpiR2MAU7g2WDi6z1w0MJXkNOmF562rFDVHJre/r3vU=; b=YNxOrNxPcuIXR8FFzm8B7UK0cMFULHWXizABs3/Vj2cRTrPXk8y0SAY2bDQ6H3RJOb W7cPHcI1aoaKubbGiHyGObmWRwl6jozXEO+L08xk8cLlwt2KDRVux9imyjqe+Ns68wD8 iTXBDKWIEfT6s2B8cKa1+Ftpy3NGehsFlgkXltDe1edMoZtA69W8KnHciPv0X20jK1AJ NRpqIvlpfZS9TF+wPIG/hKzmjOIzBSoSJIQVkZayRbhPKdShNMVxUKRQxMWk+QIR371C 01Y4gstPKI+iETiCvsDER1MGB+dZGgENz25EcUZsKOIQqN6WaZgw7t42kejEyUNbIeJW rIaw==
X-Gm-Message-State: AKaTC02mi/2XdgS5Hfv5es5U90u1gedrIXTgftP4gy9+vhjKgI8vkk8ho9zRQjQ79rFxehhdupmne3IIoZcp2h4O
X-Received: by with SMTP id j205mr2812920ita.33.1480003713263; Thu, 24 Nov 2016 08:08:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Nov 2016 08:08:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Emily Stark <>
Date: Thu, 24 Nov 2016 08:08:12 -0800
Message-ID: <>
To: Mark Nottingham <>
Cc: Mike West <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a114aab8c98b19c05420e37a7"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=1.473, 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_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c9wa3-0001HW-CE 51a28891f0dd10f3c564ffee0c1040f1
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32996
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Nov 24, 2016 at 2:10 AM, Mark Nottingham <> 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 <> wrote:
> >
> > On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <> wrote:
> > FYI, updated draft.
> >
> > Prettier (and latest) version available at:
> >
> >
> > 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:
> >
> >
> > 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
> 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 (
> 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
> 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