Internet-Draft | CHIPS spec | November 2022 |
Cutler | Expires 13 May 2023 | [Page] |
This document updates RFC6265bis, defining a new attribute, Partitioned, which restricts the contexts in which a cookie is available to only those whose top-level document is same-site with the top-level document that initiated the request that created the cookie. These cookies are referred to as "partitioned cookies" and allow embedded sites which are cross-site with the top-level frame to have access to HTTP state which cannot be used for tracking across multiple top-level sites.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://DCtheTall.github.io/CHIPS-spec/draft-cutler-httpbis-partitioned-cookies.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/.¶
Discussion of this document takes place on the HTTP Working Group mailing list (mailto:ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group information can be found at https://httpwg.org/.¶
Source for this draft and an issue tracker can be found at https://github.com/DCtheTall/CHIPS-spec.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 May 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In order to increase privacy on the web, browser vendors are either planning or already shipping restrictions on cross-site tracking. This includes phasing out support for third-party cookies, as defined in Section 7.1 of [RFC6265bis].¶
Although third-party cookies can enable third-party sites to track user behavior across different top-level sites, there are some cookie use cases on the web today where cross-domain subresources require some notion of session or persistent state that is scoped to a user's activity on a single top-level site.¶
In order to meet these use cases, this document proposes changes to RFC6265bis to support a new cookie attribute, Partitioned, which restricts the contexts that a cookie is available to only those whose top-level document is same-site with the top-level document that the cookie was created in. This attribute will allow embedded sites to use HTTP state without giving them the capability to link user behavior across distinct top-level sites.¶
Below is the definition of the Partitioned attribute. This could be added as a new subsection of Section 4.1.2 (Semantics (Non-Normative)) of [RFC6265bis]:¶
The Partitioned attribute limits the scope of the cookie such that it will only be sent when the site of the top-document (defined in section 5.2) is same-site with the top-document when the > cookie was created. Cookies set with this attribute are referred to as "partitioned cookies".¶
This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols.¶
Partitioning cross-site cookies inevitably will lead to more state proliferation on user's machines, so there is a possible DoS risk from partitioning cross-site cookies where a malicious embedded site could set many cookies across different partitions to take up memory on clients' machines. To help mitigate this, we suggest limiting the number of cookies a domain can set on a particular top-level site in the section below.¶
One important privacy consideration is that partitioned cookies must not be subject to the 180 global per-domain cookie limit, otherwise they risk introducing a side channel for cross-site tracking. Instead, partitioned cookie limits should be counted separately across different top-level sites to not leak any information about a user's activity on each respective site.¶
Another privacy consideration is that when a site sends the Clear-Site-Data header that contains "cookies", the user agent should only clear partitioned cookies whose partition key is same-site with the current top-level site. This will prevent abuse of partitioned cookies and the Clear-Site-Data header to establish identifiers that persist across different top-level sites.¶
Another privacy consideration is that the privacy guarantees of partitioned cookies can be circumvented by browser extensions with host permissions. Extensions' background contexts can query and store cookies across partitions, meaning they could store a cross-site identifier across partitions. Unfortunately, this type of attack is unavoidable due to the nature of extensions. Even if we block partitioned cookies (or even all cookies) from extensions' background contexts, an extension could still use content scripts to write cross-site identifiers to the DOM which the site's own script could copy to the site's partitioned cookie jar.¶
Finally, sites should be able to set partitioned cookies with the same name, domain, and path in different partitions. Otherwise, the presence or absence of a cookie with a particular name/domain/path would allow sites to learn about that user's activity on different top-level sites that make subresource requests to the cookie's domain.¶
This document has no IANA actions.¶
The editors would also like to thank the following individuals for feedback, insight, and implementation of this draft and its predecessors (in alphabetical order): Kaustubha Govind, Johann Hofmann, Jeffrey Yasskin,¶