Safari Tracking Prevention reality check 2026: ITP, Hide IP, Storage Partitioning

Apple's privacy marketing is among the best in consumer tech. "Privacy. That's iPhone." campaigns have shaped how people see Safari. Many view it as the browser that protects you. The reality, as shown in this PrivSec Lab technical audit, is more mixed. Safari's anti-tracking stack is truly strong in some areas. In other areas it is far from complete. You need to see the gap between the marketing claim and the real engineering. That is the only way to make a sound choice about your browsing privacy in 2026.

1. The Safari privacy narrative

Apple joined the browser privacy debate in 2017. It announced Intelligent Tracking Prevention at WWDC. The framing was clear. Ad networks were tracking users across the web. Apple's on-device machine learning classifier would spot them and hold them back. The message landed for two reasons. First, it was true: at the time, cross-site third-party cookie tracking was the main method. Second, Apple's business model does not lean on ad revenue the way Google's does.

By 2026, Apple has grown the privacy story. It now spans iCloud Private Relay, Privacy-Preserving Ad Click Attribution (PPACA, also called Private Click Measurement), Hide My Email, and App Privacy Report. Each feature is sold as a privacy step forward. Each is real to some degree. Each also carries limits that are rarely named in the same breath.

The gap matters. Users who think Safari gives full cover may skip extra defenses. Those defenses include a privacy-first DNS resolver, a tracker-blocking add-on, or a harder browser. They would close the gaps ITP leaves open. Leaning too much on a branded privacy feature is a threat model failure.

2. ITP deep-dive — history, mechanism, and 24-hour cookie caps

Intelligent Tracking Prevention shipped in Safari 11 (2017). It has been revised in every major Safari release since. The core mechanism is a machine-learning classifier. It is trained on known tracker domains. When a domain is tagged as a tracker, ITP applies a graded set of limits.

Threshold 1 — cross-site resource load restriction. A domain may have cross-site tracking power, as judged by the classifier. If the user has not visited that domain's own site in the past 30 days, Safari blocks cookies for cross-site requests from it.

Threshold 2 — 24-hour client-side cookie cap. A classified tracker domain may redirect the user through its own domain. This common ad-tech trick is called a "bounce redirect." ITP then caps any client-side cookies made via document.cookie on the tracker's domain at 24 hours. The cap holds even in a first-party context. The 24-hour window is the most cited ITP limit. It breaks lasting login and session tracking for tagged domains.

Threshold 3 — 7-day server-set cookie cap. Cross-site navigations (link clicks) may pass through a classified tracker domain. ITP then caps server-set Set-Cookie headers at 7 days. This limit targets link decoration. There, tracking parameters in URLs are read by the destination server and stored as long-lived server cookies.

ITP's machine learning classifier runs fully on-device. It scores domains from browsing history, subresource load patterns, and redirect chains. The catch: its training data and decision logic are not open to outside review. Apple runs a WebKit blog that describes ITP's design. But the classifier itself is a black box. That is a real limit for security researchers who try to check its behavior.

CNAME cloaking. One of the biggest ITP evasion tricks is CNAME cloaking. A first-party subdomain (e.g., analytics.example.com) is set with a CNAME DNS record. That record points to a third-party tracker (data.tracker-network.com). To the browser, the request looks first-party. ITP 2.3 added CNAME cloaking detection. It uses DNS resolution during page load. But the check must resolve the CNAME chain, which adds latency. It is also evaded by multi-level CNAME chains. It is evaded too by rotating infrastructure faster than ITP's classifier updates.

Storage API restrictions. ITP also applies storage caps to tagged domains. localStorage and sessionStorage are partitioned. IndexedDB made by classified cross-site iframes is not kept across page loads. And document.cookie caps apply to first-party access, as noted above.

3. Hide IP Address / iCloud Private Relay

Private Relay launched in 2021 as part of iCloud+. It is Apple's most advanced privacy feature by design. It follows a two-hop proxy model drawn from mix-network research:

Hop 1 — Apple ingress relay. The user's device sends DNS queries and HTTP/HTTPS requests through an Apple-run ingress proxy. Apple knows the user's real IP address and Apple ID. But it does not see the destination URL (for HTTPS) or the DNS query plaintext.

Hop 2 — third-party egress relay. The ingress relay sends traffic to one of several third-party egress relays. These are run by Akamai, Fastly, Cloudflare, and others. The egress relay assigns an IP address from a regional pool. It then sends traffic to the destination. It sees the destination URL but does not know the user's real IP.

What this achieves: Neither Apple nor the egress provider holds both the user's identity and the destination at once. This is a clear gain over a normal VPN. There, the VPN provider sees both.

What this does not achieve:

• Scope: Private Relay only handles Safari traffic and some system-level DNS queries on iOS/macOS. Other apps are not routed through it. That includes third-party browsers, email clients, and background processes.
• IP leakage: The exit IP comes from a broad regional pool ("Europe / Paris area" rather than your exact ISP). But the destination server still gets an IP address. Sites that use IP geolocation for content or fraud checks see a valid IP from your region.
• HTTPS only: Private Relay does not encrypt HTTP connections beyond whatever TLS the origin gives. Cleartext HTTP requests are relayed but not upgraded.
• Jurisdiction gaps: Private Relay is off by default or unavailable in China, Russia, Belarus, Kazakhstan, Saudi Arabia, Egypt, South Africa, Turkmenistan, Kyrgyzstan, Tajikistan, Uganda, the Philippines, and Colombia (as of mid-2026). Users in those places are left out without notice.
• Not anonymity: Private Relay does not stop sites from tying your identity together via login sessions, cookies, or device fingerprints. It covers IP-based tracking only.

4. Storage Partitioning 2026

Storage Partitioning is the browser mechanism that stops embedded third-party resources from reading storage state set in a different top-level context. Without it, an iframe from ad-network.com embedded on news.com can read cookies and localStorage. Those were set when the user visited ad-network.com directly. That enables cross-site user recognition.

Safari led the way on storage partitioning via ITP's storage separation. It then made it formal with the Storage Partitioning specification:

Cache partitioning. Since Safari 15, the HTTP cache is keyed by the top-level site and the requesting origin. A cached resource from cdn.example.com fetched on site-a.com is stored apart from the same resource fetched on site-b.com. This stops cache-timing attacks that infer cross-site resource loads.

BroadcastChannel partitioning. BroadcastChannel lets script talk to script across tabs. In Safari 17 it is partitioned by top-level origin. An embedded iframe cannot use BroadcastChannel to signal its embedding state across different top-level sites.

ServiceWorker scope isolation. ServiceWorkers registered by a third-party origin inside an iframe are scoped to the partition. They are not scoped to the worker's registration origin. This stops ServiceWorkers from pooling cross-site navigation data.

IndexedDB and localStorage. Both are partitioned by the (top-level site, embedded origin) double key. A tracker embedded on many sites keeps separate storage buckets per embedding site. That blocks cross-site linking.

Known gaps in 2026:

• Link decoration. URL parameters added by ad platforms (?gclid=, ?fbclid=, ?ttclid=) are not stripped by Safari by default. Firefox does strip known tracking parameters. Link decoration is the main ITP evasion vector. Campaigns use it to track across sites without third-party cookies.
• First-party data unions. Safari does not stop JavaScript in a first-party context (the main page domain). That code can gather all device signals it can reach. It can then send them to a server-side analytics endpoint. First-party tracking is fully open.
• CHIPS compatibility. The Cookies Having Independent Partitioned State (CHIPS) standard handles cross-site cookies in embeds. Chrome adopted it. Safari 17.2+ supports it too, but the server must opt in via the Partitioned cookie attribute. Sites that have not adopted CHIPS fall back to Safari's ITP-based cookie blocking.

5. What ITP does NOT block

The list of threats ITP handles is shorter than the list it leaves open.

Browser fingerprinting. Safari does not randomize canvas rendering output, WebGL renderer strings, AudioContext output, or font metrics. Because those signals are exposed, the combination of canvas, GPU, and font data is generally enough to identify a browser uniquely — Safari's frozen User-Agent string only shrinks one of several contributing vectors and does not offset the exposed canvas and GPU signals. See the browser fingerprinting state of the art guide for how fingerprint entropy is measured, and test your current Safari session directly with our browser fingerprint test tool or with EFF's Cover Your Tracks.

First-party tracking scripts. Any JavaScript loaded from the visited site's own domain sits fully outside ITP's scope. This is by design: ITP limits cross-site tracking resources. A news publisher may load its own analytics bundle (/js/analytics.js). It can then gather full behavioral data: scroll depth, session duration, article completion, and click sequences. It can send all of that to its data warehouse without limit.

Apple's own attribution APIs. Privacy-Preserving Ad Click Attribution (PPACA) and SKAdNetwork (for App Store apps) are Apple-built ad attribution frameworks. They allow click-to-install and click-to-conversion measurement without cross-site cookies. These frameworks are real privacy gains over cookie-based attribution. But they are also Apple-run ad infrastructure. They gather user interaction data under Apple's privacy policy. That design helps Apple's own ad business.

Login-based tracking. Some identity providers require login, including Apple's "Sign in with Apple." They create lasting first-party identifiers that ITP does not touch. If you are logged into a site, the site has a stable identifier for you. That holds whatever ITP's cookie limits do.

Behavioral fingerprinting. ITP does not limit APIs that expose behavioral timing. Those include requestAnimationFrame jitter, JavaScript execution timing, and user interaction timing via PointerEvent timestamps. Advanced fingerprinting systems use behavioral biometrics. They are drawn from typing rhythm and scroll inertia. These survive all browser-level limits short of API removal.

6. Comparison vs Brave and Firefox RFP

Eight criteria evaluated across Safari 17.4, Brave 1.66 (desktop), and Firefox 126 with uBlock Origin + Resist Fingerprinting (RFP) enabled.

Safari leads on OS-level integration (Private Relay, Lockdown Mode, App Privacy Report). It is the default browser for 1.9 billion Apple device users. Its ITP classifier handles unknown trackers with no list updates, which is a neat design win. But it lags on fingerprint resistance. It also lacks a user-set tracker blocklist.

Brave is the strongest anti-tracking browser here for technical breadth. Shields pairs list-based blocking with fingerprint noise, query-parameter stripping, and forceful HTTPS upgrading. Brave's business model (Brave Ads, BAT token) brings its own incentive structure. Some privacy researchers view it with care.

Firefox with RFP gives the strongest fingerprint resistance. It uses the Tor Browser-derived Resist Fingerprinting mode. That mode standardizes canvas output, letterboxes the viewport, and spoofs timezone and locale. Paired with uBlock Origin on the medium or hard mode, Firefox + RFP blocks more tracking scripts than Safari or Brave in controlled tests.

For a deeper look at browser privacy mechanisms, see the state of browser privacy 2026 guide and the privacy browsers comparison.

7. Should you trust Safari for privacy? Decision matrix

The answer depends entirely on your threat model.

Safari is enough if:

• Your threat is ad-network cross-site behavioral profiling via third-party cookies
• You are on iOS (where Brave and Firefox cannot use their own rendering engine and must use WebKit anyway)
• You use iCloud Private Relay and grasp its IP-only scope
• You are not targeted by state-level foes or advanced fingerprinting operations

Safari is not enough if:

• Your threat includes browser fingerprinting (government surveillance, high-value targets, journalists)
• You need cover against first-party tracking (no browser gives this by default)
• You need tracker blocking beyond ITP's classifier (content-heavy sites with uBlock Origin are out of reach for Safari alone)
• You are in a place where Private Relay is unavailable and you rely on it to hide your IP

Recommended configurations:

• iOS (Apple ecosystem): Safari + iCloud Private Relay + privacy-focused DNS (NextDNS or Cloudflare 1.1.1.1 with WARP for non-Safari traffic)
• macOS (moderate threat): Safari with Lockdown Mode weighed, or Brave as primary with Safari for Apple-specific sites
• macOS (high threat): Firefox with RFP + uBlock Origin (hard mode) + a privacy-respecting VPN; read the Lockdown Mode JSC analysis for Safari hardening options
• Cross-platform (high threat): Mullvad Browser (Tor Browser without Tor) + Mullvad VPN for the strongest fingerprint anonymity set

Apple's privacy engineering team has shipped real advances. ITP shook up the third-party cookie economy. It forced the whole industry to adapt. Storage Partitioning closes real attack surfaces. Private Relay is a careful two-hop design. These are not marketing fictions. But the gap between "better than Chrome" and "private browser" is wide. To make any real privacy choice, you first have to see where that gap lies.

Related guides: WebKit JIT benchmarks.