Why Safari Partitions Storage and Caches to Stop Tracking

This article provides a comprehensive look at why Apple’s Safari web browser partitions third-party storage and HTTP caches by the top-level site origin. By isolating browser data based on the specific website a user is currently visiting, Safari prevents embedded third-party trackers from sharing information across different domains. Below, we explore how trackers historically exploited shared browser resources and how Safari's partitioning model neutralizes cross-site state tracking to protect user privacy.

The Problem of Unpartitioned Browser State

Historically, web browsers stored data—such as cookies, LocalStorage, IndexedDB, and cached files—using only the origin of the resource that created them. This is known as "single-keyed" storage.

If an advertising network (e.g., tracker.com) was embedded on both news-site.com and shopping-site.com, the browser gave tracker.com access to the exact same storage vault on both websites. The tracker could assign a unique identifier to a user on the news site, save it in LocalStorage, and immediately read that same identifier when the user visited the shopping site. This allowed third parties to build detailed browsing profiles without the user's knowledge or consent.

How Trackers Exploited the HTTP Cache

As browsers began restricting third-party cookies to stop tracking, surveillance companies turned to more covert methods, such as exploiting the HTTP cache. The HTTP cache is designed to speed up browsing by saving copies of website files (like images and scripts) on your device so they do not need to be downloaded again.

Trackers abused this performance feature for cross-site state tracking:

  1. When you visited Site A, an embedded tracker would load a tiny file with a unique identifier (like an ETag or a specific image) that the browser saved to its HTTP cache.
  2. When you visited Site B, the same embedded tracker would check if that specific file was already in your browser's cache.
  3. By measuring how fast the file loaded or checking server headers, the tracker could reconstruct your unique ID and link your activity across Site A and Site B, completely bypassing cookie restrictions.

The Solution: Partitioning by Top-Level Origin

To stop both storage-based and cache-based tracking, Safari implemented a concept known as storage and cache partitioning, often referred to as "double-keying."

Instead of organizing data solely by the third-party's origin, Safari organizes it using a combination of two keys:

  1. The Top-Level Site Origin: The actual website address shown in the user's URL bar.
  2. The Resource Origin: The third-party domain requesting the storage or cache.

How Partitioning Prevents Cross-Site Tracking

With partitioning active, third-party scripts are placed into isolated sandboxes for every individual website you visit.

If tracker.com is embedded on news-site.com, Safari assigns it a storage and cache bucket labeled (news-site.com, tracker.com). When you navigate to shopping-site.com, Safari assigns the exact same tracker a completely different bucket labeled (shopping-site.com, tracker.com).

Because the buckets are separated by the top-level site origin, the tracker cannot access the LocalStorage, IndexedDB, or HTTP cache files it created on the previous website. If tracker.com tries to load a cached script on the shopping site that you already downloaded on the news site, Safari ignores the existing file and forces a brand-new download.

Privacy Over Micro-Performance

Partitioning the HTTP cache means the browser occasionally has to download the same third-party file multiple times across different websites, slightly increasing bandwidth usage. However, Safari prioritizes user privacy over these minor performance gains. By tying all third-party state directly to the top-level site origin, Safari ensures that your data cannot be weaponized to follow you across the web.