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

Mike West <> Thu, 24 November 2016 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17F5B1296DA for <>; Thu, 24 Nov 2016 01:38:52 -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 A_9SuVmSLZN8 for <>; Thu, 24 Nov 2016 01:38:50 -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 D8A3B129417 for <>; Thu, 24 Nov 2016 01:38:49 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9qQm-00028O-Hc for; Thu, 24 Nov 2016 09:35:00 +0000
Resent-Date: Thu, 24 Nov 2016 09:35:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9qQf-00027B-17 for; Thu, 24 Nov 2016 09:34:53 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c9qQY-0003qd-JI for; Thu, 24 Nov 2016 09:34:47 +0000
Received: by with SMTP id t196so24056747lff.3 for <>; Thu, 24 Nov 2016 01:34:25 -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=HBcUnIMGZaMf6zGzGN6/uFOfqPJTUr9Tefai+epj86Q=; b=N4ne9Iu8bks6a99nEB/wTcRJluuKLu2DwelfvJb8r5fB8BIX6jT/GnrZ2itF7zQgtv PdMwm8LfUu/C4ID5WVQXuov1Amf2vCexVx/zJFrz6Z1ESzoAUFJsQCw2L+mFis77fUYv VCVX19oaEd6i3C1icPioA1XKWVmvLIn6s/iurvbMXfKYY4uUmBDHLc5PiXstLo8wGzys gpSTnj0SzH7JZwud8XDn/DmdDUdQaACmsgSIhYzHA4sHBXpJsGJXXN2MI758HxG0sMvQ loZYy6b8o5hCLmjqvYOWs+d8UM/gGbJ0hN7PF2zAdv9Njj9qu3z/bRWQIgVFR0ITrv2x qkhQ==
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=HBcUnIMGZaMf6zGzGN6/uFOfqPJTUr9Tefai+epj86Q=; b=gNU8pDGMSnSSXmxgfOZfENBuUeQ+buUO/dmyxU1YFrNjG5o+riXy1N/HGaPvzvHNEZ dJkKPbK+hEYxBIIDQWeNzogOK9+40Cpl7nbkHM3yi15M5imRUJb8UJFyCYjd7Fy2ykxo Y+FdvGC0d4vGacnOShOeoC8DGAt1vqfYXZeTTaIKvtBdG6VVluQFc8+NKfTvOYGrK9og x4gnT1KLdNeLJf0hjJMJbhPKzQJoVEC5LIXRwGeUFS0q0fPvB5MezmAfYwIxsdDxVryW AZdHOh1xt4+2ApDWvkuArOm2qLGt68a1LEB1Gwl+qQKkVj4h/iv3YGNClfSUGjLfSKyd 2JLg==
X-Gm-Message-State: AKaTC02xnYeWzKfbYUnIev6NWcUTCah6qcxqDngaypB+5Gis2+xBiXJmlvVPZsdfPfp80ioraNdMox1EO+v5cJrx
X-Received: by with SMTP id 68mr599874lfu.111.1479980059353; Thu, 24 Nov 2016 01:34:19 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Nov 2016 01:33:58 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Mike West <>
Date: Thu, 24 Nov 2016 10:33:58 +0100
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>, "Emily Stark (Dunn)" <>
Content-Type: multipart/alternative; boundary="001a113fbe0eb6ba72054208b5b7"
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: 1c9qQY-0003qd-JI 1c608c29e3c15db4a547d01739a67b4a
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32991
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 (probably
with some additions for headers whose ship has sailed, like Emily's

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