How Firefox Total Cookie Protection Isolates Cookies

This article explains the technical mechanism behind Mozilla Firefox’s Total Cookie Protection feature. It covers the traditional problem of cross-site tracking, how Firefox implements state partitioning to create isolated "cookie jars" for every website, what types of data are included in these jars, and how the browser handles exceptions for legitimate website functionality without sacrificing user privacy.

Before Total Cookie Protection, web browsers stored all cookies in a single, shared location based solely on the domain that created the cookie. If an advertising or analytics company embedded its code on thousands of different websites, it could read the exact same cookie every time you visited any of those sites. This allowed third-party trackers to build a comprehensive profile of your browsing history across the entire web.

Firefox solves the cross-site tracking problem through a technique known as Dynamic State Partitioning. Instead of storing cookies in one big shared space, Firefox changes the way it indexes and retrieves them in the browser's database.

When you visit a website, Firefox looks at the URL in your address bar—known as the "top-level site." It then creates a unique storage partition (a virtual cookie jar) assigned specifically to that top-level domain.

Technically, Firefox achieves this by attaching a "partition key" to every cookie. Previously, a cookie was only identified by its creator's domain (e.g., tracker.com). With Total Cookie Protection, Firefox identifies the cookie using two pieces of information:

  1. The domain of the website you are actively visiting (the top-level site).
  2. The domain of the entity creating the cookie (the third-party tracker).

A Practical Example

Imagine you visit news-site.com and shopping-site.com, and both websites use an embedded tracker from ad-network.com.

  1. When you visit news-site.com, Firefox creates a dedicated cookie jar for it. When ad-network.com drops a cookie, Firefox locks it inside the news-site.com jar.
  2. Later, when you visit shopping-site.com, Firefox creates a completely separate cookie jar for this new domain.
  3. When ad-network.com tries to read the cookie it created earlier, Firefox blocks access to the news-site.com jar. Instead, it forces ad-network.com to drop a brand-new cookie into the shopping-site.com jar.

Because the two cookies are stored in separate partitions with different keys, ad-network.com cannot link your activity between the two websites. To the tracker, you appear to be two entirely different users.

Isolating More Than Just Cookies

Trackers often use alternative browser features to track users if cookies are blocked. To prevent this, Firefox's "cookie jars" actually isolate all forms of browser storage and communication channels. Every individual website partition isolates:

  • Standard HTTP cookies and JavaScript cookies
  • LocalStorage and SessionStorage
  • IndexedDB databases
  • HTTP cache and image caches
  • Service Workers and Web Workers
  • TLS session identifiers

By partitioning all of these state mechanisms alongside cookies, Firefox ensures trackers cannot use hidden workarounds to bypass the isolated jars.

Managing Exceptions for Login Services

Total isolation can sometimes break legitimate website features, such as third-party single sign-on (SSO) providers, payment gateways, or embedded comment systems that require knowing who you are across multiple sites.

Firefox handles this without breaking the cookie jar model in two ways:

  1. The Storage Access API: A third-party service can explicitly request permission from the browser to access its unpartitioned (first-party) cookies. This usually requires you to actively interact with the embedded element, such as clicking a "Log in" button.
  2. SmartBlock and Heuristics: Firefox automatically detects common authentication flows. If it sees you intentionally logging into a site using a third-party provider, it grants temporary, tightly scoped access between the two specific jars just long enough to complete the login process, keeping all other trackers locked in their respective jars.