Safari Intelligent Tracking Prevention: How It Works and What It Misses

Safari’s Intelligent Tracking Prevention arrived in 2017 as the first significant browser-side counter-measure to cross-site tracking that operated by default without requiring user configuration or extensions. In the years since, ITP has gone through multiple major versions, each closing loopholes that the ad industry and publishers found in the previous one. Understanding what ITP actually does — and the battle it represents between Apple’s privacy posture and the behavioral advertising ecosystem — requires understanding both the technical implementation and the context of who’s fighting to keep tracking working.

What ITP Is Trying to Prevent

Cross-site tracking works by associating the same user across multiple unrelated sites. The canonical mechanism: an advertising network places its script (or an image pixel) on Site A and Site B. When you visit Site A, the ad network sets a cookie identifying you. When you visit Site B, the same ad network reads that cookie and knows it’s you. Repeat across hundreds of sites and the network builds a detailed behavioral profile.

ITP’s goal is to prevent that cookie from being readable across sites. The approach isn’t simply blocking all third-party cookies — that would break a lot of legitimate functionality (SSO, embedded payment flows, cross-site authentication). ITP uses machine learning to classify which domains are “tracking domains” and applies restrictions specifically to those, while leaving other third-party cookie uses intact.

How ITP Classifies Trackers

Safari’s WebKit team has documented the ITP algorithm in the WebKit blog. The classifier is trained on data about how domains load across the web. A domain that appears as a third-party sub-resource on many different first-party domains — but is rarely visited directly as a first party — is classified as a tracker.

The classifier runs locally on your device. Apple doesn’t send your browsing history to train it. The model is updated with Safari/iOS updates.

Once a domain is classified as a tracker, Safari applies restrictions:

  • Third-party cookies from that domain are blocked by default
  • Scripts from that domain cannot access document.cookie
  • Partitioned storage (where any storage that domain sets is keyed to the top-level site, not shared across sites)

The restrictions have strengthened with each ITP version. In current versions, third-party cookies from classified trackers are blocked unconditionally — there is no “visited recently” exception that existed in early ITP versions.

The 7-Day and 24-Hour Storage Rules

ITP’s storage limits are more aggressive than the cookie-blocking headline:

First-party bounce tracking. If a domain is classified as a tracker and you reach it only through a redirect (a “bounce”) without navigating to it directly as a first party, any storage that domain sets during the bounce is purged within 24 hours. This closes the redirect-tracking loophole where ad networks would route you through their domain in a URL chain before delivering you to the destination, using the milliseconds of first-party context to set a persistent cookie.

First-party storage capping. If you’ve visited a site but then don’t interact with it for 7 days, ITP caps the storage it can maintain in the context of other sites. Specifically, cross-site cookies for that domain expire after 7 days without direct user interaction.

These rules don’t affect first-party cookies on sites you actively visit — if you go to news.com regularly, news.com’s first-party cookies persist normally. The restrictions target the embedded-third-party use case.

What ITP Does and Doesn’t Stop

ITP stops:

  • Third-party cookie syncing through embedded resources from classified tracking domains
  • Bounce tracking (redirect-then-set-cookie flows)
  • Some CNAME cloaking approaches (where a tracker hides behind a first-party subdomain), though this is an ongoing arms race
  • Link decoration (URL parameters used to pass user identifiers) in some contexts — ITP strips query parameters from domains classified as trackers in navigations

ITP doesn’t stop:

  • First-party tracking by the site you’re visiting
  • Fingerprinting (canvas, WebGL, font enumeration, etc.)
  • IP-based tracking
  • Federated Login SSO flows from major providers (Apple has special handling for legitimate SSO scenarios)
  • GA4 in first-party mode (where the measurement script acts as a first party)
  • Server-side tracking that doesn’t use cookies at all

The email open tracking question: Image pixel tracking in email doesn’t go through the browser in the way ITP affects — email clients have their own tracking protection, not ITP.

The Ad Industry Response

The advertising and publishing industries have been in an arms race with ITP since 2017. Each version closed loopholes that emerged from the previous one:

  • ITP 1.0 blocked third-party cookies from classified trackers but allowed them with “user interaction.” Ad networks responded by adding buttons that caused user interaction to maintain cookie access.
  • ITP 2.0 closed the user-interaction loophole. Ad networks moved to first-party CNAME cloaking — routing tracking scripts through a first-party subdomain (e.g., metrics.yoursite.com pointing to the tracker’s servers).
  • ITP 2.1 and later added storage capping and CNAME tracking detection.

The current battleground: link decoration (passing user identifiers in URL parameters like ?fbclid= and ?gclid=) and server-side tracking that reconstructs tracking without cookies.

Google’s Privacy Sandbox and its replacement identifiers were partly a response to cookie blocking. Apple has explicitly declined to implement Google’s Privacy Sandbox APIs in Safari. The resulting ecosystem fragmentation — where cross-site measurement works differently in Chrome, Firefox, and Safari — is a real consequence of these diverging approaches.

ITP vs. Firefox and Chrome

Firefox’s Total Cookie Protection (in Strict ETP mode) takes a different approach: rather than classifying tracking domains, it partitions all third-party storage by top-level site. No classifier is needed — every site’s cookies are siloed per context. This is arguably more complete (no false negatives from the classifier) but also means some legitimate cross-site use cases break without per-site exceptions.

Chrome’s Privacy Sandbox uses the Privacy Topics API and Attribution Reporting API to provide interest-based targeting and conversion measurement without third-party cookies. Chrome intends to maintain these APIs as replacements, which is a fundamentally different philosophy than Safari’s approach of restricting the tracking surface rather than replacing it.

Developer Implications

If you’re building a web application that uses cross-site authentication, embedded analytics, or any cross-site state, ITP has implications:

  • Third-party login widgets (Facebook Login, Google Sign-In) require using their official SDKs that implement the Storage Access API, which prompts users for permission.
  • Embedded analytics on a domain you control need to be implemented as first-party (same domain or subdomain), not loaded from the analytics provider’s domain.
  • Cross-site embeds that need user state (comment systems, shopping carts accessible from partner sites) need to implement the Storage Access API and handle the case where access is denied.

Apple’s WebKit Privacy Updates page is the authoritative source for current ITP behavior, and reading it chronologically tells the story of what closed when.

FAQ

Does Private Browsing in Safari use ITP? Yes. ITP is active in Private Browsing mode. Additionally, in Safari 17+, each private tab is isolated — cookies from one private tab are not visible to another private tab in the same window.

Does ITP affect Google Analytics? Classic Google Analytics running through google-analytics.com as a third party is affected. GA4 in first-party mode (measurements routed through your own domain) is less affected — it acts as a first party for cookie purposes. The effectiveness of ITP against GA4 depends entirely on how it’s implemented.

Can I disable ITP? In Safari on Mac: Safari → Settings → Privacy → uncheck “Prevent cross-site tracking.” This disables ITP. On iOS, there is no UI toggle — ITP is always active in Safari on iOS.

Does ITP protect against fingerprinting? ITP specifically is not a fingerprinting protection. Safari has separate mitigations for canvas and other fingerprinting APIs, but they’re less aggressive than Firefox’s privacy.resistFingerprinting. Fingerprinting remains effective against Safari users.