idnits 2.17.1 

draft-west-first-party-cookies-07.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 (April 6, 2016) is 2934 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	HTTPbis                                                          M. West
3	Internet-Draft                                               Google, Inc
4	Updates: 6265 (if approved)                                   M. Goodwin
5	Intended status: Standards Track                                 Mozilla
6	Expires: October 8, 2016                                   April 6, 2016

8	                           Same-site Cookies
9	                   draft-west-first-party-cookies-07

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	Status of This Memo

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

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

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

34	   This Internet-Draft will expire on October 8, 2016.

36	Copyright Notice

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

41	   This document is subject to BCP 78 and the IETF Trust's Legal
42	   Provisions Relating to IETF Documents
43	   (http://trustee.ietf.org/license-info) in effect on the date of
44	   publication of this document.  Please review these documents
45	   carefully, as they describe your rights and restrictions with respect
46	   to this document.  Code Components extracted from this document must
47	   include Simplified BSD License text as described in Section 4.e of
48	   the Trust Legal Provisions and are provided without warranty as
49	   described in the Simplified BSD License.

51	Table of Contents

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

81	1.  Introduction

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

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

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

101	1.1.  Goals

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

107	   1.  Timing attacks which yield cross-origin information leakage (such
108	       as those detailed in [pixel-perfect]) can be substantially
109	       mitigated by setting the "SameSite" attribute on authentication
110	       cookies.  The attacker will only be able to embed unauthenticated
111	       resources, as embedding mechanisms such as "<iframe>" will yield
112	       cross-site requests.

114	   2.  Cross-site script inclusion (XSSI) attacks are likewise mitigated
115	       by setting the "SameSite" attribute on authentication cookies.
116	       The attacker will not be able to include authenticated resources
117	       via "<script>" or "<link>", as these embedding mechanisms will
118	       likewise yield cross-site requests.

120	   3.  Cross-site request forgery (CSRF) attacks which rely on top-level
121	       navigation (HTML "<form>" POSTs, for instance) can also be
122	       mitigated by treating these navigational requests as "cross-
123	       site".

125	   4.  Same-site cookies have some marginal value for policy or
126	       regulatory purposes, as cookies which are not delivered with
127	       cross-site requests cannot be directly used for tracking
128	       purposes.  It may be valuable for an origin to assert that its
129	       cookies should not be sent along with cross-site requests in
130	       order to limit its exposure to non-technical risk.

132	1.2.  Examples

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

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

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

144	2.  Terminology and notation

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

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

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

157	   The terms "active document", "ancestor browsing context", "browsing
158	   context", "document", "WorkerGlobalScope", "sandboxed origin browsing
159	   context flag", "parent browsing context", "the worker's Documents",
160	   "nested browsing context", and "top-level browsing context" are
161	   defined in [HTML].

163	   "Service Workers" are defined in the Service Workers specification
164	   [SERVICE-WORKERS].

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

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

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

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

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

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

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

195	   1.  If "request"'s client is "null", return "same-site".

197	   2.  Let "site" be "request"'s client's "site for cookies" (as defined
198	       in the following sections).

200	   3.  Let "target" be the registrable domain of "request"'s current
201	       url.

203	   4.  If "site" is an exact match for "target", return "same-site".

205	   5.  Return "cross-site".

207	2.1.1.  Document-based requests

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

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

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

229	   Given a Document ("document"), the following algorithm returns its
230	   "site for cookies" (either a registrable domain, or the empty
231	   string):

233	   1.  Let "top-document" be the active document in "document"'s
234	       browsing context's top-level browsing context.

236	   2.  Let "top-origin" be the origin of "top-document"'s URI if "top-
237	       document"'s sandboxed origin browsing context flag is set, and
238	       "top-document"'s origin otherwise.

240	   3.  Let "documents" be a list containing "document" and each of
241	       "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.

249	       2.  If "origin"'s host's registrable domain is not an exact match
250	           for "top-origin"'s host's registrable domain, return the
251	           empty string.

253	   5.  Return "top-site".

255	2.1.2.  Worker-based requests

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

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

268	2.1.2.1.  Dedicated and Shared Workers

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

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

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

285	   1.  Let "site" be "worker"'s origin's host's registrable domain.

287	   2.  For each "document" in "worker"'s Documents:

289	       1.  Let "document-site" be "document"'s "site for cookies" (as
290	           defined in Section 2.1.1).

292	       2.  If "document-site" is not an exact match for "site", return
293	           the empty string.

295	   3.  Return "site".

297	2.1.2.2.  Service Workers

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

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

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

313	   Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
314	   returns its "site for cookies" (either a registrable domain, or the
315	   empty string):

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

319	3.  Server Requirements

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

324	3.1.  Grammar

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

330	   cookie-av      = expires-av / max-age-av / domain-av /
331	                    path-av / secure-av / httponly-av /
332	                    samesite-av / extension-av
333	   samesite-av    = "SameSite" / "SameSite=" samesite-value
334	   samesite-value = "Strict" / "Lax"

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

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

345	   If the "SameSite" attribute's value is "Strict", or if the value is
346	   invalid, the cookie will only be sent along with "same-site"
347	   requests.  If the value is "Lax", the cookie will be sent with "same-
348	   site" requests, and with "cross-site" top-level navigations, as
349	   described in Section 4.1.1.

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

354	4.  User Agent Requirements

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

359	4.1.  The "SameSite" attribute

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

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

367	   1.  If "cookie-av"'s "attribute-value" is not a case-sensitive match
368	       for "Strict" or "Lax", ignore the "cookie-av".

370	   2.  Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is
371	       a case-insensitive match for "Lax", and "Strict" otherwise.

373	   3.  Append an attribute to the "cookie-attribute-list" with an
374	       "attribute-name" of "SameSite" and an "attribute-value" of
375	       "enforcement".

377	4.1.1.  "Strict" and "Lax" enforcement

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

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

393	   1.  Attackers can still pop up new windows or trigger top-level
394	       navigations in order to create a "same-site" request (as
395	       described in section 2.1), which is only a speedbump along the
396	       road to exploitation.

398	   2.  Features like "<link rel='prerender'>" [prerendering] can be
399	       exploited to create "same-site" requests without the risk of user
400	       detection.

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

406	4.2.  Monkey-patching the Storage Model

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

411	   Alter Section 5.3 of [RFC6265] as follows:

413	   1.  Add "samesite-flag" to the list of fields stored for each cookie.
414	       This field's value is one of "None", "Strict", or "Lax".

416	   2.  Before step 11 of the current algorithm, add the following:

418	       1.  If the "cookie-attribute-list" contains an attribute with an
419	           "attribute-name" of "SameSite", set the cookie's "samesite-
420	           flag" to "attribute-value" ("Strict" or "Lax").  Otherwise,
421	           set the cookie's "samesite-flag" to "None".

423	       2.  If the cookie's "samesite-flag" is not "None", and the
424	           request which generated the cookie's client's "site for
425	           cookies" is not an exact match for "request-uri"'s host's
426	           registrable domain, then abort these steps and ignore the
427	           newly created cookie entirely.

429	4.3.  Monkey-patching the "Cookie" header

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

434	   Alter Section 5.4 of [RFC6265] as follows:

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

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

442	          1.  "samesite-flag" is "Lax"

444	          2.  The HTTP request's method is "safe".

446	          3.  The HTTP request's target browsing context is a top-level
447	              browsing context.

449	   Note that the modifications suggested here concern themselves only
450	   with the "site for cookies" of the request's client, and the
451	   registrable domain of the resource being requested.  The cookie's
452	   "domain", "path", and "secure" attributes do not come into play for
453	   these comparisons.

455	5.  Authoring Considerations

457	5.1.  Defense in depth

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

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

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

474	5.2.  Top-level Navigations

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

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

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

500	5.3.  Mashups and Widgets

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

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

513	6.  Privacy Considerations

515	6.1.  Server-controlled

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

527	6.2.  Pervasive Monitoring

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

540	7.  References

542	7.1.  Normative References

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

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

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

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

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

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

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

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

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

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

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

590	7.2.  Informative References

592	   [app-isolation]
593	              Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
594	              "App Isolation - Get the Security of Multiple Browsers
595	              with Just One", n.d.,
596	              <http://www.collinjackson.com/research/papers/
597	              appisolation.pdf>.

599	   [pixel-perfect]
600	              Stone, P., "Pixel Perfect Timing Attacks with HTML5",
601	              n.d., <http://www.contextis.com/documents/2/
602	              Browser_Timing_Attacks.pdf>.

604	   [prerendering]
605	              Bentzel, C., "Chrome Prerendering", n.d.,
606	              <https://www.chromium.org/developers/design-documents/
607	              prerender>.

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

613	   [samedomain-cookies]
614	              Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,
615	              <http://people.mozilla.org/~mgoodwin/SameDomain/
616	              samedomain-latest.txt>.

618	   [secure-contexts]
619	              West, M., "Secure Contexts", n.d., <https://w3c.github.io/
620	              webappsec-secure-contexts/>.

622	Appendix A.  Acknowledgements

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

629	Authors' Addresses

631	   Mike West
632	   Google, Inc

634	   Email: mkwst@google.com
635	   URI:   https://mikewest.org/

637	   Mark Goodwin
638	   Mozilla

640	   Email: mgoodwin@mozilla.com
641	   URI:   https://www.computerist.org/