This content originally appeared on text/plain and was authored by ericlaw
Background: What Does “3rd-Party” Mean?
A 3rd-party cookie is one that is set or sent from a 3rd-party context on a web page.
A 3rd-party context is a frame or resource whose registrable domain (sometimes called eTLD+1) differs from that of the top-level page. This is sometimes called “cross-site.” In this example:
domain3.com are cross-site 3rd-parties to the parent page served by
domain1.com. (In contrast, a resource from
sub.domain1.com is cross-origin, but same-site/1st Party to
Importantly, frames or images from
domain3.com cannot see or modify the cookies in
domain1.com‘s cookie jar, and script running at
domain1.com cannot see or set cookies for the embedded
Background: Existing Restrictions
Q: Why do privacy advocates worry about 3rd-party cookies?
A: Because they are a simple way to track a given user’s browsing across the web.
Say a bunch of unrelated sites include ads from an advertising server. A 3rd-party cookie set on the content from the ad will allow that ad server to identify the set of sites that the user has visited. For example, consider three pages the user visits:
The advertiser, instead of simply knowing that their ad is running on Star Trek’s website, is also able to know that this specific user has previously visited sites related to running and a medication, and can thus target its advertisements in a way that the visitor may deem a violation of their privacy.
For this reason, browsers have supported controls on 3rd-party cookies for decades, but they were typically off-by-default or trivially bypassed.
However, none of these restrictions will go as far as browsers will go in the future.
A Full Menu of Replacements
In order to support scenarios that have been built atop 3rd-party cookies for multiple decades, new patterns and technologies will be needed.
The Easy Recipe: CHIPS
In 2020, cookies were made SameSite=Lax by default blocking cookies from being set and sent in 3rd-party contexts by default. The workaround for Web Developers who still needed cookies in 3rd-party contexts was simple: when a cookie is set, adding the attribute
SameSite=none will disable the new behavior and allow the cookie to be set and sent freely. Over the course of the last two years, most sites that cared about their cookies began sending the attribute.
The CHIPS proposal (“Cookies having independent partitioned state”) offers a new but more limited escape hatch– a developer may opt-in to partitioning their cookie so that it’s no longer a “3rd party cookie”, it’s instead a partitioned cookie. A partitioned cookie set in the context of
domain3.com embedded inside runnersworld.com will not be visible in the context
domain3.com embedded inside startrek.com. Similarly, setting the cookie in the context
domain3.com embedded inside gas-x.com will have no impact on the cookie’s value in the other two pages. If the user visits
domain3.com as a top-level browser navigation, the cookies that were set on that origin’s subframes in the context of other top-level pages remain inaccessible.
Using the new
Partitioned attribute is simple; just add it to your
Set-Cookie header like so:
Set-Cookie: __Host-id=4d5e6;Partitioned;SameSite=None; Secure;Path=/;
Support for CHIPS is expected to be broad, across all major browsers.
I was initially a bit skeptical about requiring authors to explicitly specify the new attribute– why not just treat all cookies in 3rd-party contexts as partitioned? I eventually came around to the arguments that an explicit declaration is desirable. As it stands, legacy applications already needed to be updated with a
SameSite=None declaration, so we probably wouldn’t keep any unmaintained legacy apps working if we didn’t require the attribute.
The Explicit Recipe: The Storage Access API
The Storage Access API allows a website to request permission to use storage in a 3rd party context. Microsoft Edge joined Safari and Firefox with support for this API in 2020 as a mechanism for mitigating the impact of the browser’s Tracking Prevention feature.
A Niche Recipe: First Party Sets
In some cases, the fact that cookies are treated as “3rd-party” represents a technical limitation rather than a legal or organizational one. For example, Microsoft owns
teams.microsoft.com, but these origins do not today share a common eTLD+1, meaning that pages from these sites are treated as cross-site 3rd-parties to one another. The First Party Sets proposal would allow sites owned and operated by a single-entity to be treated as first-party when it comes to privacy features.
Originally, a new cookie attribute,
SameParty, would allow a site to request inclusion of a cookie when the cross-origin sub-resource’s context is in the same First Party Set as the top-level origin, but a recent proposal removes that attribute.
The Authentication Recipe: FedCM API
As I explained three years ago, authentication is an important use-case for 3rd-party cookies, but it’s hampered by browser restrictions on 3P cookies. The Federated Credential Management API proposes that browsers and websites work together to imbue the browser with awareness and control of the user’s login state on participating websites. As noted in Google’s explainer:
We expect FedCM to be useful to you only if all these conditions apply:
- You’re an identity provider (IdP).
- You’re affected by the third-party cookie phase out.
- Your Relying Parties are third-parties.
FedCM is a big, complex, and important specification that aims to solve exclusively authentication scenarios.
The move away from supporting 3rd-party cookies has huge implications for how websites are built. Maintaining compatibility for desirable scenarios while meaningfully breaking support for undesirable scenarios (trackers) is inherently extremely challenging– I equate it to trying to swap out an airliner’s engines while the plane is full of passengers and in-flight.
As we add multiple new approaches to address the removal of 3P cookies, we must carefully reason about how they all interact. Specifications need to define how the behavior of CHIPS, First-Party-Sets, and the Storage Access API all intersect, for example, and web developers must account for cases where a browser may support only some of the new features.
Cookies Aren’t The Only Type of Storage
Another compexity is that cookies aren’t the only form of storage– IndexedDB, localStorage, sessionStorage, and various other cookie-like storages all exist in the web platform. Limiting only cookies without accounting for other forms of storage wouldn’t get us to where we want to be on privacy.
That said, cookies are one of the more interesting forms of storage when it comes to privacy, as they
- are sent to the server before the page loads,
- operate in cases like
<img>elements where no script-execution context exists
Cookies Are Special
Another interesting aspect of migrating scenarios away from cookies is that we lose some of the neat features that have been added over the years.
One such feature is the
Another cookie feature is TLS Token Binding, an obscure capability that attempts to prevent token theft attacks from compromised PCs. If malware or a malicious insider steals Token-bound cookie data directly from a PC, that cookie data will not work from another device because the private key material used to authenticate the cookies cannot be exported off of the compromised client device. (This non-exportability property is typically enforced by security hardware like a TPM.) While Token binding provides a powerful and unique capability for cookies, for various reasons the feature is not broadly supported.
Deprecating 3rd-Party Cookies is Not a Panacea
Unfortunately, getting rid of 3rd-party cookies doesn’t mean that we’ll be rid of tracking. There are many different ways to track a user, ranging from the obvious (they’re logged in to your site, they have a unique IP address) to the obscure (various fingerprinting mechanisms). But getting rid of 3rd-party cookies is a valuable step as browser makers work to engineer a privacy sandbox into the platform.
It’s a fascinating time in the web platform privacy space, and I can’t wait to see how this all works out.
 Interestingly, if
domain1.com includes a
<script> element pointed at a resource from
domain3.com, that script will run inside
domain1.com‘s context, such that calls to the
document.cookie DOM property will return the cookies for
domain1.com, not the domain that served the script. But that’s not important for our discussion here.
This content originally appeared on text/plain and was authored by ericlaw