idnits 2.17.1 

draft-ietf-httpbis-cookie-same-site-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a Security Considerations section.

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (June 20, 2016) is 2867 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'PSL'

  ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SERVICE-WORKERS'


     Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	HTTP Working Group                                               M. West
3	Internet-Draft                                               Google, Inc
4	Updates: 6265 (if approved)                                   M. Goodwin
5	Intended status: Standards Track                                 Mozilla
6	Expires: December 22, 2016                                 June 20, 2016

8	                           Same-Site Cookies
9	                 draft-ietf-httpbis-cookie-same-site-00

11	Abstract

13	   This document updates RFC6265 by defining a "SameSite" attribute
14	   which allows servers to assert that a cookie ought not to be sent
15	   along with cross-site requests.  This assertion allows user agents to
16	   mitigate the risk of cross-origin information leakage, and provides
17	   some protection against cross-site request forgery attacks.

19	Note to Readers

21	   Discussion of this draft takes place on the HTTP working group
22	   mailing list (ietf-http-wg@w3.org), which is archived at
23	   https://lists.w3.org/Archives/Public/ietf-http-wg/ .

25	   Working Group information can be found at http://httpwg.github.io/ ;
26	   source code and issues list for this draft can be found at
27	   https://github.com/httpwg/http-extensions/labels/cookie-same-site .

29	Status of This Memo

31	   This Internet-Draft is submitted in full conformance with the
32	   provisions of BCP 78 and BCP 79.

34	   Internet-Drafts are working documents of the Internet Engineering
35	   Task Force (IETF).  Note that other groups may also distribute
36	   working documents as Internet-Drafts.  The list of current Internet-
37	   Drafts is at http://datatracker.ietf.org/drafts/current/.

39	   Internet-Drafts are draft documents valid for a maximum of six months
40	   and may be updated, replaced, or obsoleted by other documents at any
41	   time.  It is inappropriate to use Internet-Drafts as reference
42	   material or to cite them other than as "work in progress."

44	   This Internet-Draft will expire on December 22, 2016.

46	Copyright Notice

48	   Copyright (c) 2016 IETF Trust and the persons identified as the
49	   document authors.  All rights reserved.

51	   This document is subject to BCP 78 and the IETF Trust's Legal
52	   Provisions Relating to IETF Documents
53	   (http://trustee.ietf.org/license-info) in effect on the date of
54	   publication of this document.  Please review these documents
55	   carefully, as they describe your rights and restrictions with respect
56	   to this document.  Code Components extracted from this document must
57	   include Simplified BSD License text as described in Section 4.e of
58	   the Trust Legal Provisions and are provided without warranty as
59	   described in the Simplified BSD License.

61	Table of Contents

63	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
64	     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
65	     1.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
66	   2.  Terminology and notation  . . . . . . . . . . . . . . . . . .   4
67	     2.1.  "Same-site" and "cross-site" Requests . . . . . . . . . .   5
68	       2.1.1.  Document-based requests . . . . . . . . . . . . . . .   5
69	       2.1.2.  Worker-based requests . . . . . . . . . . . . . . . .   6
70	   3.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   7
71	     3.1.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . .   7
72	     3.2.  Semantics of the "SameSite" Attribute (Non-Normative) . .   8
73	   4.  User Agent Requirements . . . . . . . . . . . . . . . . . . .   8
74	     4.1.  The "SameSite" attribute  . . . . . . . . . . . . . . . .   8
75	       4.1.1.  "Strict" and "Lax" enforcement  . . . . . . . . . . .   9
76	     4.2.  Monkey-patching the Storage Model . . . . . . . . . . . .   9
77	     4.3.  Monkey-patching the "Cookie" header . . . . . . . . . . .  10
78	   5.  Authoring Considerations  . . . . . . . . . . . . . . . . . .  10
79	     5.1.  Defense in depth  . . . . . . . . . . . . . . . . . . . .  10
80	     5.2.  Top-level Navigations . . . . . . . . . . . . . . . . . .  10
81	     5.3.  Mashups and Widgets . . . . . . . . . . . . . . . . . . .  11
82	   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
83	     6.1.  Server-controlled . . . . . . . . . . . . . . . . . . . .  11
84	     6.2.  Pervasive Monitoring  . . . . . . . . . . . . . . . . . .  12
85	   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
86	     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
87	     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
88	   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  14
89	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

91	1.  Introduction

93	   Section 8.2 of [RFC6265] eloquently notes that cookies are a form of
94	   ambient authority, attached by default to requests the user agent
95	   sends on a user's behalf.  Even when an attacker doesn't know the
96	   contents of a user's cookies, she can still execute commands on the
97	   user's behalf (and with the user's authority) by asking the user
98	   agent to send HTTP requests to unwary servers.

100	   Here, we update [RFC6265] with a simple mitigation strategy that
101	   allows servers to declare certain cookies as "same-site", meaning
102	   they should not be attached to "cross-site" requests (as defined in
103	   section 2.1).

105	   Note that the mechanism outlined here is backwards compatible with
106	   the existing cookie syntax.  Servers may serve these cookies to all
107	   user agents; those that do not support the "SameSite" attribute will
108	   simply store a cookie which is attached to all relevant requests,
109	   just as they do today.

111	1.1.  Goals

113	   These cookies are intended to provide a solid layer of defense-in-
114	   depth against attacks which require embedding an authenticated
115	   request into an attacker-controlled context:

117	   1.  Timing attacks which yield cross-origin information leakage (such
118	       as those detailed in [pixel-perfect]) can be substantially
119	       mitigated by setting the "SameSite" attribute on authentication
120	       cookies.  The attacker will only be able to embed unauthenticated
121	       resources, as embedding mechanisms such as "<iframe>" will yield
122	       cross-site requests.
123	   2.  Cross-site script inclusion (XSSI) attacks are likewise mitigated
124	       by setting the "SameSite" attribute on authentication cookies.
125	       The attacker will not be able to include authenticated resources
126	       via "<script>" or "<link>", as these embedding mechanisms will
127	       likewise yield cross-site requests.
128	   3.  Cross-site request forgery (CSRF) attacks which rely on top-level
129	       navigation (HTML "<form>" POSTs, for instance) can also be
130	       mitigated by treating these navigational requests as "cross-
131	       site".
132	   4.  Same-site cookies have some marginal value for policy or
133	       regulatory purposes, as cookies which are not delivered with
134	       cross-site requests cannot be directly used for tracking
135	       purposes.  It may be valuable for an origin to assert that its
136	       cookies should not be sent along with cross-site requests in
137	       order to limit its exposure to non-technical risk.

139	1.2.  Examples

141	   Same-site cookies are set via the "SameSite" attribute in the "Set-
142	   Cookie" header field.  That is, given a server's response to a user
143	   agent which contains the following header field:

145	   Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict

147	   Subsequent requests from that user agent can be expected to contain
148	   the following header field if and only if both the requested resource
149	   and the resource in the top-level browsing context match the cookie.

151	2.  Terminology and notation

153	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155	   document are to be interpreted as described in [RFC2119].

157	   This specification uses the Augmented Backus-Naur Form (ABNF)
158	   notation of [RFC5234].

160	   Two sequences of octets are said to case-insensitively match each
161	   other if and only if they are equivalent under the "i;ascii-casemap"
162	   collation defined in [RFC4790].

164	   The terms "active document", "ancestor browsing context", "browsing
165	   context", "document", "WorkerGlobalScope", "sandboxed origin browsing
166	   context flag", "parent browsing context", "the worker's Documents",
167	   "nested browsing context", and "top-level browsing context" are
168	   defined in [HTML].

170	   "Service Workers" are defined in the Service Workers specification
171	   [SERVICE-WORKERS].

173	   The term "origin", the mechanism of deriving an origin from a URI,
174	   and the "the same" matching algorithm for origins are defined in
175	   [RFC6454].

177	   "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
178	   defined in Section 4.2.1 of [RFC7231].

180	   The term "public suffix" is defined in a note in Section 5.3 of
181	   [RFC6265] as "a domain that is controlled by a public registry".  For
182	   example, "example.com"'s public suffix is "com".  User agents SHOULD
183	   use an up-to-date public suffix list, such as the one maintained by
184	   Mozilla at [PSL].

186	   An origin's "registrable domain" is the origin's host's public suffix
187	   plus the label to its left.  That is, "https://www.example.com"'s
188	   registrable domain is "example.com".  This concept is defined more
189	   rigorously in [PSL].

191	   The term "request", as well as a request's "client", "current url",
192	   "method", and "target browsing context", are defined in [FETCH].

194	2.1.  "Same-site" and "cross-site" Requests

196	   A request is "same-site" if its target's URI's origin's registrable
197	   domain is an exact match for the request's initiator's "site for
198	   cookies", and "cross-site" otherwise.  To be more precise, for a
199	   given request ("request"), the following algorithm returns "same-
200	   site" or "cross-site":

202	   1.  If "request"'s client is "null", return "same-site".
203	   2.  Let "site" be "request"'s client's "site for cookies" (as defined
204	       in the following sections).
205	   3.  Let "target" be the registrable domain of "request"'s current
206	       url.
207	   4.  If "site" is an exact match for "target", return "same-site".
208	   5.  Return "cross-site".

210	2.1.1.  Document-based requests

212	   The URI displayed in a user agent's address bar is the only security
213	   context directly exposed to users, and therefore the only signal
214	   users can reasonably rely upon to determine whether or not they trust
215	   a particular website.  The registrable domain of that URI's origin
216	   represents the context in which a user most likely believes
217	   themselves to be interacting.  We'll label this domain the "top-level
218	   site".

220	   For a document displayed in a top-level browsing context, we can stop
221	   here: the document's "site for cookies" is the top-level site.

223	   For documents which are displayed in nested browsing contexts, we
224	   need to audit the origins of each of a document's ancestor browsing
225	   contexts' active documents in order to account for the "multiple-
226	   nested scenarios" described in Section 4 of [RFC7034].  These
227	   document's "site for cookies" is the top-level site if and only if
228	   the document and each of its ancestor documents' origins have the
229	   same registrable domain as the top-level site.  Otherwise its "site
230	   for cookies" is the empty string.

232	   Given a Document ("document"), the following algorithm returns its
233	   "site for cookies" (either a registrable domain, or the empty
234	   string):

236	   1.  Let "top-document" be the active document in "document"'s
237	       browsing context's top-level browsing context.
238	   2.  Let "top-origin" be the origin of "top-document"'s URI if "top-
239	       document"'s sandboxed origin browsing context flag is set, and
240	       "top-document"'s origin otherwise.
241	   3.  Let "documents" be a list containing "document" and each of
242	       "document"'s ancestor browsing contexts' active documents.
243	   4.  For each "item" in "documents":

245	       1.  Let "origin" be the origin of "item"'s URI if "item"'s
246	           sandboxed origin browsing context flag is set, and "item"'s
247	           origin otherwise.
248	       2.  If "origin"'s host's registrable domain is not an exact match
249	           for "top-origin"'s host's registrable domain, return the
250	           empty string.
251	   5.  Return "top-site".

253	2.1.2.  Worker-based requests

255	   Worker-driven requests aren't as clear-cut as document-driven
256	   requests, as there isn't a clear link between a top-level browsing
257	   context and a worker.  This is especially true for Service Workers
258	   [SERVICE-WORKERS], which may execute code in the background, without
259	   any document visible at all.

261	   Note: The descriptions below assume that workers must be same-origin
262	   with the documents that instantiate them.  If this invariant changes,
263	   we'll need to take the worker's script's URI into account when
264	   determining their status.

266	2.1.2.1.  Dedicated and Shared Workers

268	   Dedicated workers are simple, as each dedicated worker is bound to
269	   one and only one document.  Requests generated from a dedicated
270	   worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
271	   their "site for cookies" as that document's "site for cookies".

273	   Shared workers may be bound to multiple documents at once.  As it is
274	   quite possible for those documents to have distinct "site for cookie"
275	   values, the worker's "site for cookies" will be the empty string in
276	   cases where the values diverge, and the shared value in cases where
277	   the values agree.

279	   Given a WorkerGlobalScope ("worker"), the following algorithm returns
280	   its "site for cookies" (either a registrable domain, or the empty
281	   string):

283	   1.  Let "site" be "worker"'s origin's host's registrable domain.
284	   2.  For each "document" in "worker"'s Documents:

286	       1.  Let "document-site" be "document"'s "site for cookies" (as
287	           defined in Section 2.1.1).
288	       2.  If "document-site" is not an exact match for "site", return
289	           the empty string.
290	   3.  Return "site".

292	2.1.2.2.  Service Workers

294	   Service Workers are more complicated, as they act as a completely
295	   separate execution context with only tangential relationship to the
296	   Document which registered them.

298	   Requests which simply pass through a service worker will be handled
299	   as described above: the request's client will be the Document or
300	   Worker which initiated the request, and its "site for cookies" will
301	   be those defined in Section 2.1.1 and Section 2.1.2.1

303	   Requests which are initiated by the Service Worker itself (via a
304	   direct call to "fetch()", for instance), on the other hand, will have
305	   a client which is a ServiceWorkerGlobalScope.  Its "site for cookies"
306	   will be the registrable domain of the Service Worker's URI.

308	   Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
309	   returns its "site for cookies" (either a registrable domain, or the
310	   empty string):

312	   1.  Return "worker"'s origin's host's registrable domain.

314	3.  Server Requirements

316	   This section describes extensions to [RFC6265] necessary to implement
317	   the server-side requirements of the "SameSite" attribute.

319	3.1.  Grammar

321	   Add "SameSite" to the list of accepted attributes in the "Set-Cookie"
322	   header field's value by replacing the "cookie-av" token definition in
323	   Section 4.1.1 of [RFC6265] with the following ABNF grammar:

325	   cookie-av      = expires-av / max-age-av / domain-av /
326	                    path-av / secure-av / httponly-av /
327	                    samesite-av / extension-av
328	   samesite-av    = "SameSite" / "SameSite=" samesite-value
329	   samesite-value = "Strict" / "Lax"

331	3.2.  Semantics of the "SameSite" Attribute (Non-Normative)

333	   The "SameSite" attribute limits the scope of the cookie such that it
334	   will only be attached to requests if those requests are "same-site",
335	   as defined by the algorithm in Section 2.1.  For example, requests
336	   for "https://example.com/sekrit-image" will attach same-site cookies
337	   if and only if initiated from a context whose "site for cookies" is
338	   "example.com".

340	   If the "SameSite" attribute's value is "Strict", or if the value is
341	   invalid, the cookie will only be sent along with "same-site"
342	   requests.  If the value is "Lax", the cookie will be sent with "same-
343	   site" requests, and with "cross-site" top-level navigations, as
344	   described in Section 4.1.1.

346	   The changes to the "Cookie" header field suggested in Section 4.3
347	   provide additional detail.

349	4.  User Agent Requirements

351	   This section describes extensions to [RFC6265] necessary in order to
352	   implement the client-side requirements of the "SameSite" attribute.

354	4.1.  The "SameSite" attribute

356	   The following attribute definition should be considered part of the
357	   the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]:

359	   If the "attribute-name" case-insensitively matches the string
360	   "SameSite", the user agent MUST process the "cookie-av" as follows:

362	   1.  If "cookie-av"'s "attribute-value" is not a case-insensitive
363	       match for "Strict" or "Lax", ignore the "cookie-av".
364	   2.  Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is
365	       a case-insensitive match for "Lax", and "Strict" otherwise.
366	   3.  Append an attribute to the "cookie-attribute-list" with an
367	       "attribute-name" of "SameSite" and an "attribute-value" of
368	       "enforcement".

370	4.1.1.  "Strict" and "Lax" enforcement

372	   By default, same-site cookies will not be sent along with top-level
373	   navigations.  As discussed in Section 5.2, this might or might not be
374	   compatible with existing session management systems.  In the
375	   interests of providing a drop-in mechanism that mitigates the risk of
376	   CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
377	   enforcement mode that carves out an exception which sends same-site
378	   cookies along with cross-site requests if and only if they are top-
379	   level navigations which use a "safe" (in the [RFC7231] sense) HTTP
380	   method.

382	   Lax enforcement provides reasonable defense in depth against CSRF
383	   attacks that rely on unsafe HTTP methods (like "POST"), but do not
384	   offer a robust defense against CSRF as a general category of attack:

386	   1.  Attackers can still pop up new windows or trigger top-level
387	       navigations in order to create a "same-site" request (as
388	       described in section 2.1), which is only a speedbump along the
389	       road to exploitation.
390	   2.  Features like "<link rel='prerender'>" [prerendering] can be
391	       exploited to create "same-site" requests without the risk of user
392	       detection.

394	   When possible, developers should use a session management mechanism
395	   such as that described in Section 5.2 to mitigate the risk of CSRF
396	   more completely.

398	4.2.  Monkey-patching the Storage Model

400	   Note: There's got to be a better way to specify this.  Until I figure
401	   out what that is, monkey-patching!

403	   Alter Section 5.3 of [RFC6265] as follows:

405	   1.  Add "samesite-flag" to the list of fields stored for each cookie.
406	       This field's value is one of "None", "Strict", or "Lax".
407	   2.  Before step 11 of the current algorithm, add the following:

409	       1.  If the "cookie-attribute-list" contains an attribute with an
410	           "attribute-name" of "SameSite", set the cookie's "samesite-
411	           flag" to "attribute-value" ("Strict" or "Lax").  Otherwise,
412	           set the cookie's "samesite-flag" to "None".
413	       2.  If the cookie's "samesite-flag" is not "None", and the
414	           request which generated the cookie's client's "site for
415	           cookies" is not an exact match for "request-uri"'s host's
416	           registrable domain, then abort these steps and ignore the
417	           newly created cookie entirely.

419	4.3.  Monkey-patching the "Cookie" header

421	   Note: There's got to be a better way to specify this.  Until I figure
422	   out what that is, monkey-patching!

424	   Alter Section 5.4 of [RFC6265] as follows:

426	   1.  Add the following requirement to the list in step 1:

428	       *  If the cookie's "samesite-flag" is not "None", and the HTTP
429	          request is cross-site (as defined in Section 2.1 then exclude
430	          the cookie unless all of the following statements hold:

432	          1.  "samesite-flag" is "Lax"
433	          2.  The HTTP request's method is "safe".
434	          3.  The HTTP request's target browsing context is a top-level
435	              browsing context.

437	   Note that the modifications suggested here concern themselves only
438	   with the "site for cookies" of the request's client, and the
439	   registrable domain of the resource being requested.  The cookie's
440	   "domain", "path", and "secure" attributes do not come into play for
441	   these comparisons.

443	5.  Authoring Considerations

445	5.1.  Defense in depth

447	   "SameSite" cookies offer a robust defense against CSRF attack when
448	   deployed in strict mode, and when supported by the client.  It is,
449	   however, prudent to ensure that this designation is not the extent of
450	   a site's defense against CSRF, as same-site navigations and
451	   submissions can certainly be executed in conjunction with other
452	   attack vectors such as cross-site scripting.

454	   Developers are strongly encouraged to deploy the usual server-side
455	   defenses (CSRF tokens, ensuring that "safe" HTTP methods are
456	   idempotent, etc) to mitigate the risk more fully.

458	   Additionally, client-side techniques such as those described in
459	   [app-isolation] may also prove effective against CSRF, and are
460	   certainly worth exploring in combination with "SameSite" cookies.

462	5.2.  Top-level Navigations

464	   Setting the "SameSite" attribute in "strict" mode provides robust
465	   defense in depth against CSRF attacks, but has the potential to
466	   confuse users unless sites' developers carefully ensure that their
467	   session management systems deal reasonably well with top-level
468	   navigations.

470	   Consider the scenario in which a user reads their email at MegaCorp
471	   Inc's webmail provider "https://example.com/".  They might expect
472	   that clicking on an emailed link to "https://projects.com/secret/
473	   project" would show them the secret project that they're authorized
474	   to see, but if "projects.com" has marked their session cookies as
475	   "SameSite", then this cross-site navigation won't send them along
476	   with the request. "projects.com" will render a 404 error to avoid
477	   leaking secret information, and the user will be quite confused.

479	   Developers can avoid this confusion by adopting a session management
480	   system that relies on not one, but two cookies: one conceptualy
481	   granting "read" access, another granting "write" access.  The latter
482	   could be marked as "SameSite", and its absence would provide a
483	   reauthentication step before executing any non-idempotent action.
484	   The former could drop the "SameSite" attribute entirely, or choose
485	   the "Lax" version of enforcement, in order to allow users access to
486	   data via top-level navigation.

488	5.3.  Mashups and Widgets

490	   The "SameSite" attribute is inappropriate for some important use-
491	   cases.  In particular, note that content intended for embedding in a
492	   cross-site contexts (social networking widgets or commenting
493	   services, for instance) will not have access to such cookies.  Cross-
494	   site cookies may be required in order to provide seamless
495	   functionality that relies on a user's state.

497	   Likewise, some forms of Single-Sign-On might require authentication
498	   in a cross-site context; these mechanisms will not function as
499	   intended with same-site cookies.

501	6.  Privacy Considerations

503	6.1.  Server-controlled

505	   Same-site cookies in and of themselves don't do anything to address
506	   the general privacy concerns outlined in Section 7.1 of [RFC6265].
507	   The attribute is set by the server, and serves to mitigate the risk
508	   of certain kinds of attacks that the server is worried about.  The
509	   user is not involved in this decision.  Moreover, a number of side-
510	   channels exist which could allow a server to link distinct requests
511	   even in the absence of cookies.  Connection and/or socket pooling,
512	   Token Binding, and Channel ID all offer explicit methods of
513	   identification that servers could take advantage of.

515	6.2.  Pervasive Monitoring

517	   As outlined in [RFC7258], pervasive monitoring is an attack.  Cookies
518	   play a large part in enabling such monitoring, as they are
519	   responsible for maintaining state in HTTP connections.  We considered
520	   restricting same-site cookies to secure contexts [secure-contexts] as
521	   a mitigation but decided against doing so, as this feature should
522	   result in a strict reduction in the number of cookies floating around
523	   in cross-site contexts.  That is, even if "http://not-example.com"
524	   embeds a resource from "http://example.com/", that resource will not
525	   be "same-site", and "http://example.com"'s cookies simply cannot be
526	   used to correlate user behavior across distinct origins.

528	7.  References

530	7.1.  Normative References

532	   [FETCH]    van Kesteren, A., "Fetch", n.d.,
533	              <https://fetch.spec.whatwg.org/>.

535	   [HTML]     Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
536	              P., and D. Denicola, "HTML", n.d.,
537	              <https://html.spec.whatwg.org/>.

539	   [PSL]      "Public Suffix List", n.d., <https://publicsuffix.org/
540	              list/>.

542	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
543	              Requirement Levels", BCP 14, RFC 2119,
544	              DOI 10.17487/RFC2119, March 1997,
545	              <http://www.rfc-editor.org/info/rfc2119>.

547	   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
548	              Application Protocol Collation Registry", RFC 4790,
549	              DOI 10.17487/RFC4790, March 2007,
550	              <http://www.rfc-editor.org/info/rfc4790>.

552	   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
553	              Specifications: ABNF", STD 68, RFC 5234,
554	              DOI 10.17487/RFC5234, January 2008,
555	              <http://www.rfc-editor.org/info/rfc5234>.

557	   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
558	              DOI 10.17487/RFC6265, April 2011,
559	              <http://www.rfc-editor.org/info/rfc6265>.

561	   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
562	              DOI 10.17487/RFC6454, December 2011,
563	              <http://www.rfc-editor.org/info/rfc6454>.

565	   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
566	              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
567	              DOI 10.17487/RFC7231, June 2014,
568	              <http://www.rfc-editor.org/info/rfc7231>.

570	   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
571	              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
572	              2014, <http://www.rfc-editor.org/info/rfc7258>.

574	   [SERVICE-WORKERS]
575	              Russell, A., Song, J., and J. Archibald, "Service
576	              Workers", n.d., <http://www.w3.org/TR/service-workers/>.

578	7.2.  Informative References

580	   [app-isolation]
581	              Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
582	              "App Isolation - Get the Security of Multiple Browsers
583	              with Just One", n.d.,
584	              <http://www.collinjackson.com/research/papers/
585	              appisolation.pdf>.

587	   [pixel-perfect]
588	              Stone, P., "Pixel Perfect Timing Attacks with HTML5",
589	              n.d., <http://www.contextis.com/documents/2/
590	              Browser_Timing_Attacks.pdf>.

592	   [prerendering]
593	              Bentzel, C., "Chrome Prerendering", n.d.,
594	              <https://www.chromium.org/developers/design-documents/
595	              prerender>.

597	   [RFC7034]  Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
598	              Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
599	              <http://www.rfc-editor.org/info/rfc7034>.

601	   [samedomain-cookies]
602	              Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,
603	              <http://people.mozilla.org/~mgoodwin/SameDomain/
604	              samedomain-latest.txt>.

606	   [secure-contexts]
607	              West, M., "Secure Contexts", n.d., <https://w3c.github.io/
608	              webappsec-secure-contexts/>.

610	Appendix A.  Acknowledgements

612	   The same-site cookie concept documented here is indebited to Mark
613	   Goodwin's and Joe Walker's [samedomain-cookies].  Michal Zalewski,
614	   Artur Janc, Ryan Sleevi, and Adam Barth provided particularly
615	   valuable feedback on this document.

617	Authors' Addresses

619	   Mike West
620	   Google, Inc

622	   Email: mkwst@google.com
623	   URI:   https://mikewest.org/

625	   Mark Goodwin
626	   Mozilla

628	   Email: mgoodwin@mozilla.com
629	   URI:   https://www.computerist.org/