Browser Landscape
Edition 3.1.1
Storage Persistence Matrix
Section titled “Storage Persistence Matrix”Maximum cookie and storage lifetimes by browser and mechanism under normal (non-private) browsing:
| Mechanism | Safari 26+ | Firefox (Standard) | Firefox (Strict) | Brave | Chrome | Edge (Balanced) | Evidence (verified 2026-07-19) |
|---|---|---|---|---|---|---|---|
JS document.cookie | purged after 7 days of Safari use without recognized first-party interaction; 24h under the decorated-navigation rule | browser-enforced maximum (see note) | browser-enforced maximum (see note) | 6 months | 400 days | 400 days | A2, A3, B1, B8; Chrome/Edge: developer.chrome.com cookie-max-age blog (2022-08) |
HTTP Set-Cookie (first-party-aligned server) | no ITP-specific lifetime cap documented for aligned first-party server cookies; not a guaranteed lifetime | browser-enforced maximum (see note) | browser-enforced maximum (see note) | 6 months | 400 days | 400 days | A5, B1, B8 |
HTTP Set-Cookie (CNAME or cross-party IP prefix) | 7 days | browser-enforced maximum | browser-enforced maximum | — | 400 days | 400 days | A4 (Safari); Chrome/Edge per 400-day note |
| Third-party cookies (unpartitioned, default) | blocked by default (webkit.org “Full Third-Party Cookie Blocking”, 2020-03-24) | partitioned (TCP; classified trackers partitioned since Firefox 141) | blocked | blocked (Shields) | allowed | varies by tracker classification | Safari: dated primary above + A6/C4 for opt-in CHIPS; Firefox B11; Brave B2; Chrome B15; Edge B13 |
Opt-in Partitioned (CHIPS) cookies | supported since Safari 26.2 (shipped 18.4, removed 18.5) | supported since Firefox 141 | supported since Firefox 141 | — | supported (Chrome/Edge 114+) | supported (Chrome/Edge 114+) | A6, C4, B11 |
| localStorage | purged after 7 days of Safari use without recognized first-party interaction | — | — | — | — | — | A2, A3 (Safari) |
| sessionStorage | session (per-tab) | session (per-tab) | session (per-tab) | session (per-tab) | session (per-tab) | session (per-tab) | C6 (normal-mode sessionStorage is strictly per-tab) |
| IndexedDB | purged after 7 days of Safari use without recognized first-party interaction | — | — | — | — | — | A2, A3 (Safari) |
| Service Workers | purged after 7 days of Safari use without recognized first-party interaction | — | — | — | — | — | A2, A3 (Safari) |
Notes on the 400-day figure: it comes from the draft RFC 6265bis specification. Chromium enforces it since Chrome 104 (August 2022); cookies requesting a longer Max-Age or Expires are silently capped. No official Apple/WebKit source documents a Safari-specific 400-day maximum, and Firefox enforcement of the 400-day cap is unconfirmed. Treat 400 days as a Chromium-enforced ceiling and an RFC recommendation elsewhere, never a cross-browser guarantee (A5, B8; verified 2026-07-19).
A bare — cell makes no claim: the dimension has no applicable dated evidence and is omitted. “Persistent” means the data survives until explicit deletion by the user, programmatic clearing, or a browser-enforced maximum lifetime. It does not mean indefinite: all browsers reserve the right to evict storage under pressure. User-initiated deletion is another vector: Brave’s Shred per-site data-deletion feature reached Android with v1.89 (2026-04-22), erasing a site’s data on demand or optionally automatically on tab close (brave.com/privacy-updates/ post #37, accessed 2026-08-07).
For persistence strategy recommendations, see Identity Management.
Safari ITP (Intelligent Tracking Prevention)
Section titled “Safari ITP (Intelligent Tracking Prevention)”Safari’s ITP is not discretely versioned since ITP 2.3 (September 2019); Apple ships continuous improvements as part of WebKit releases (A8, verified 2026-07-19). The system operates entirely on-device with no centralized blocklist.
Classification Model
Section titled “Classification Model”ITP classifies domains as trackers using an on-device machine learning model. The classifier evaluates per-domain (eTLD+1) statistics:
- Number of unique top-level domains where the domain appears as a subresource.
- Number of unique top-level domains where the domain appears in an iframe.
- Number of unique domains the domain redirects to (bounce tracking detection).
- Tracker collusion: if domain A redirects to classified domain B, domain A inherits the classification. This propagates recursively through the redirect graph.
No blocklist is used. No data leaves the device. A domain is classified based solely on its behavioral patterns as observed by the individual user’s browser. Website data for classified domains is deleted when the user has not interacted with the site as a first party in the last 30 days. That rule is specific to classified domains, not a general first-party storage limit (A9).
Cookie Lifetime Rules
Section titled “Cookie Lifetime Rules”| How the cookie is set | Maximum lifetime | Conditions | Evidence (verified 2026-07-19) |
|---|---|---|---|
document.cookie (JavaScript) | governed by the 7-day script-writable-storage purge | All JS-set first-party cookies align with script-writable storage deletion. The standalone 7-day expiry cap was removed in WebKit commit a2db53cd97 (2022-06-08, bug 240248); WebKit published no contemporaneous blog post, so the source commit is the citation | A2 |
document.cookie after a decorated navigation | 24 hours | Navigation came from a domain classified with cross-site tracking capabilities and the landing URL carries any query string or fragment. WebKit does not inspect URLs or cookies for named click identifiers — parameters like gclid or fbclid are industry examples of link decoration, not WebKit’s predicate | A1 |
Set-Cookie HTTP header, first-party aligned server | no ITP-specific documented cap | Genuine first-party configuration; not a guaranteed lifetime (see the 400-day note above) | A5 |
Set-Cookie HTTP header, CNAME or cross-party IP prefix | 7 days | The first-party subdomain resolves via CNAME to a third-party host, or the resolved address is cross-party by prefix: fewer than 16 common leading bits (IPv4) or fewer than 64 (IPv6) versus the website’s address. The rule is prefix similarity, never exact address equality | A4 |
Script-Writable Storage Purge
Section titled “Script-Writable Storage Purge”ITP deletes all script-writable storage after 7 days of Safari use without recognized first-party interaction with the site. The affected mechanisms:
- localStorage.
- IndexedDB.
- Service Worker registrations and cache.
- Media keys.
- JavaScript-set cookies (aligned with this purge since late 2022, A2).
The 7-day clock resets only on recognized user interaction as a first party: a click, tap, keyboard input, or text entry. A full page navigation by itself does not reset it, and neither does scrolling or passive viewing (A3, A9; verified 2026-07-19). In third-party contexts, localStorage and IndexedDB are partitioned by the top-level domain.
CNAME and IP Cloaking Detection
Section titled “CNAME and IP Cloaking Detection”CNAME cloaking protection is official WebKit behavior. If a first-party subdomain resolves via CNAME to a third-party domain, Safari caps cookies set from that subdomain at 7 days. WebKit’s IP-cloaking heuristic compares address families and prefix similarity. A server whose address shares fewer than 16 leading bits (IPv4) or fewer than 64 (IPv6) with the website’s address is treated as cross-party (A4, WebKit documentation and source, verified 2026-07-19).
Safari 26 (September 2025)
Section titled “Safari 26 (September 2025)”- Advanced Fingerprinting Protection (AFP): Apple documents all-browsing protection in the 26-generation OS releases. WebKit’s shipped implementation targets known fingerprinting scripts, so it is not universal fingerprint resistance (A7, Apple June-2025 announcements + WebKit blog, verified 2026-07-19).
- Link Tracking Protection (LTP): officially documented for Mail, Messages, and Private Browsing. Apple does not name specific stripped parameters in the cited release material (A7).
Safari 26.3–26.6 and Safari 27 beta (2026)
Section titled “Safari 26.3–26.6 and Safari 27 beta (2026)”Safari 26.3 (2026-02-11), 26.4 (2026-03-24), and 26.6 (2026-07-27) shipped with no tracking-prevention changes; 26.6 carries one partitioned-cookie deletion fix via WKHTTPCookieStore (webkit.org/blog/17798, /17862, /18178, accessed 2026-08-07). Safari 27 beta (announced 2026-06-08 at WWDC26) announces no new tracking-prevention mechanisms in the primary WebKit post. Its privacy-relevant additions are Secure cookies on loopback hosts and Cookie Store API maxAge support (webkit.org/blog/17967, accessed 2026-08-07). Secondary-source claims circulating about Safari 27 (Link Tracking Protection expanded to all browsing with twclid/xmt/si stripping, and IP-range blocking) are not present in primary WebKit/Apple material. They are excluded from this specification unless a primary source documents them.
Cookie Lifetime Decision Tree
Section titled “Cookie Lifetime Decision Tree”Text equivalent: a JavaScript-set cookie is purged with script-writable storage after 7 days of Safari use without recognized first-party interaction. It expires in 24 hours instead when set after a navigation from a classified domain whose landing URL carries any query string or fragment. A server-set cookie from a first-party-aligned host has no ITP-specific documented cap (and no guarantee). A server-set cookie from a CNAME-cloaked or cross-party-prefix host is capped at 7 days. (A1, A2, A4, A5.)
Firefox Enhanced Tracking Protection (ETP)
Section titled “Firefox Enhanced Tracking Protection (ETP)”Firefox ships three ETP modes. The default is Standard. (B7, verified 2026-07-19.)
Standard Mode (Default)
Section titled “Standard Mode (Default)”| What is blocked | Details |
|---|---|
| Social media trackers | Blocked |
| Cross-site tracking cookies | Partitioned via Total Cookie Protection (TCP) — each top-level site gets its own cookie jar. Since Firefox 141 (2025-07-22), known trackers are partitioned rather than blocked in Standard mode (B11) |
| Cryptominers | Blocked |
| Known fingerprinters | Blocked |
| Tracking content | Blocked in Private Browsing only |
Strict Mode
Section titled “Strict Mode”Everything in Standard, plus:
| What is blocked | Details |
|---|---|
| Tracking content | Blocked in all windows |
| All cross-site cookies | Fully blocked (not just partitioned) |
| Bounce tracking | Storage purged for classified bounce trackers (Bounce Tracking Protection, Firefox 133+, November 2024; heuristic, hourly purges, 45-day direct-interaction exemption; Firefox 145 additionally enabled a stateless BTP mode by default in Strict) (B9) |
Tracker Lists
Section titled “Tracker Lists”Firefox uses the Disconnect.me tracker list: Level 1 (Standard) covers Advertising, Analytics, and Social categories and excludes “Content” to minimize breakage; Level 2 (Strict) includes Content. An entity list exempts same-company domains (B7).
Total Cookie Protection (TCP)
Section titled “Total Cookie Protection (TCP)”TCP shipped in Firefox 86 (February 2021) and became the default for all desktop users on 2022-06-14 (B8). Every website gets its own cookie jar: a third-party cookie set on site A cannot be read when that third party appears on site B. Third-party cookies still function within a single site’s context, partitioned by top-level site, with heuristic exceptions for cross-site login flows.
TCP does not restrict first-party cookie lifetimes. Firefox first-party cookies persist up to the browser-enforced maximum; whether Firefox enforces the RFC 6265bis 400-day recommendation is unconfirmed (B8, verified 2026-07-19).
Anti-Fingerprinting (Firefox 145, Firefox 151)
Section titled “Anti-Fingerprinting (Firefox 145, Firefox 151)”Firefox 145 (2025-11-11) shipped phase-2 anti-fingerprinting (font limits and hardware-detail limits: CPU cores, touch points, taskbar/dock dimensions) in Private Browsing and ETP Strict. Canvas protections date to phase 1 (since 2021), not this release (B12).
Firefox 151 (2026-05-19) moved a subset of fingerprinting protection into Standard (default) ETP: available screen resolution, touch points, and the Canvas API provide uniform results for all users by default. Mozilla reports this reduces the share of users uniquely identifiable by common fingerprinting techniques by an average of ~14%, and by ~49% on macOS (firefox.com/en-US/firefox/151.0/releasenotes; Mozilla Security & Privacy newsletter 2026 Q2, attackanddefense.dev, accessed 2026-08-07). The Firefox 145 phase-2 surfaces remain scoped to Private Browsing and ETP Strict; the Firefox 151 subset is what now applies to default-mode users.
First-Party Storage
Section titled “First-Party Storage”Firefox applies no general time-based restriction to first-party localStorage, IndexedDB, or Service Workers. Ordinary first-party storage persists until cleared by the user or by code, subject to normal browser eviction. The bounded exception is classified bounce trackers under Bounce Tracking Protection (ETP Strict; Firefox 133+, heuristic, hourly purge cycle, 45-day direct-interaction exemption; Firefox 145 also enabled a stateless BTP mode by default in Strict. B9, verified 2026-07-19). For a domain classified as a bounce tracker, BTP can purge storage and site data on its timed cycle, subject to those documented exemptions, mode, and version conditions. Ordinary first-party sites not classified as bounce trackers are outside that purge; no universal persistence guarantee is implied for any site.
Brave Shields
Section titled “Brave Shields”Brave Shields are on by default for all users. The default level is Standard.
Cookie and Storage Lifetimes
Section titled “Cookie and Storage Lifetimes”Brave caps the lifetime of first-party cookies at 6 months, whether set via JavaScript or HTTP. Until Brave v1.83 (late 2025), JavaScript-set cookies were capped at 7 days; that split no longer exists. The cap is universal: it does not depend on tracker classification. Brave’s own documentation phrases the cap as “6 months”. (B1, Brave wiki + issue #48063, verified 2026-07-19.) Re-verified 2026-08-07: the 6-month first-party cookie cap is unchanged. Brave’s latest privacy-update post is #37 (2026-04-22, Shred on Android), and no newer post exists (brave.com/privacy-updates/, accessed 2026-08-07).
| Mechanism | Lifetime | Evidence |
|---|---|---|
| First-party cookies (JS- or HTTP-set) | 6 months | B1 |
| Third-party cookies | Blocked by default | B1/B2 |
| Third-party storage in frames | Ephemeral: partitioned by top-level origin, destroyed when the last top-level frame for that origin closes or navigates away, with a ~30-second keep-alive grace | B2 |
Fingerprint Farbling
Section titled “Fingerprint Farbling”Brave uses session-level randomization (“farbling”) on fingerprinting surfaces. The verified farbled set: canvas readback, WebGL debug info, Web Audio serialization, user agent, plugins, hardwareConcurrency, deviceMemory, and enumerateDevices. Screen and window dimensions are not farbled (an acknowledged open item, Brave issue #720), and language-preference reduction is a separate opt-in Shields setting, not standard farbling (B3, verified 2026-07-19).
Each session produces a unique fingerprint per site, making cross-site fingerprint correlation unreliable. Brave sunset its “Strict” fingerprinting mode with v1.64 (announced January 2024) in favor of the farbling approach (B4).
Filter Lists
Section titled “Filter Lists”Brave maintains its own ad and tracker blocking lists in addition to EasyList/EasyPrivacy. Brave v1.85 (January 2026) shipped a FlatBuffers overhaul of its existing Rust adblock engine (Rust since 2019), cutting memory use by roughly 75% (B5). Cookiecrumbler is an open-source (April 2025) crawler that uses LLMs to detect cookie-consent notices and propose human-reviewed filter rules. Banner blocking inside the browser works via ordinary filter rules, not via any in-browser LLM agent (B6).
Chrome
Section titled “Chrome”Third-Party Cookie Status
Section titled “Third-Party Cookie Status”Third-party cookies remain enabled by default in Chrome. Google abandoned its deprecation plan in July 2024 and confirmed in April 2025 that no standalone opt-in prompt would roll out. This is vendor policy, subject to change (B15, privacysandbox.com posts of 2024-07-22 and 2025-04-22, verified 2026-07-19).
Bounce Tracking Mitigations (default since October 2023)
Section titled “Bounce Tracking Mitigations (default since October 2023)”Chrome’s Bounce Tracking Mitigations (BTM) launched by default in October 2023 for users who block third-party cookies, a population that includes Chrome Incognito by default (testing was available earlier, from Chrome 115, via a developer trial). BTM heuristically deletes site data (cookies and storage) for domains that perform stateful bounce redirects without a recent recorded site interaction (a 45-day site-interaction test) (privacysandbox.google.com/protections/bounce-tracking-mitigations; developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial, accessed 2026-08-07). Chrome’s documented out-of-scope flows are federated authentication, SSO, and payments: classes whose redirects involve direct user interaction. UIAF’s attribution-identity handoff is not one of those classes, and a gesture on the source site does not establish that Chrome recorded interaction on every target or redirect site. Each site Chrome may classify needs its own recorded interaction to avoid purge. A misclassified redirect domain in the 3PC-blocked population can lose storage, so deployments relying on the cross-domain handoff (Identity Resolution) treat Chrome BTM as a residual risk to monitor.
Privacy Sandbox
Section titled “Privacy Sandbox”Retired October 2025 (B16, privacysandbox.com 2025-10-17):
| Component | Status |
|---|---|
| Topics API | Retired |
| Protected Audience (PAAPI/FLEDGE) | Retired |
| Attribution Reporting API | Retired |
| Related Website Sets (RWS) | Retired |
| CHIPS (cookie partitioning) | Retained |
| FedCM (Federated Credential Management) | Retained |
| Private State Tokens | Retained |
CHIPS is now tri-engine, with a discontinuous Safari history: Chrome/Edge 114+; Safari 18.4 shipped CHIPS, Safari 18.5 temporarily removed it, and Safari 26.2 restored support; Firefox 141 re-enabled it (A6, C4, B11, verified 2026-07-19). Safari 26.2 (December 2025) shipped opt-in partitioned cookies (CHIPS-style, via the Partitioned attribute) per the primary WebKit release post (webkit.org/blog/17640/webkit-features-for-safari-26-2, accessed 2026-08-07). Partitioned cookies require Secure; cross-site use requires SameSite=None.
Adjacent Mechanisms
Section titled “Adjacent Mechanisms”Device Bound Session Credentials (DBSC) is available in Chrome 145 on Windows (Chrome’s announcement, dated/updated 2026-03-03; macOS announced for a later release). It binds session-authenticator cookies to a device key (short-lived bound cookies plus proof-of-key refresh) so exfiltrated cookies cannot be replayed from another machine (developer.chrome.com/blog/dbsc-windows-announcement; developer.chrome.com/docs/web-platform/device-bound-session-credentials, accessed 2026-08-07). UIAF’s uiaf_uid is deliberately a non-authenticator, script-readable attribution identity, so DBSC is an explicit non-goal: identity for attribution, not authentication. Separately, Firefox 147 added Storage Access headers, allowing servers to activate unpartitioned-cookie access via HTTP when Storage Access had already been granted (mozilla.org/en-US/firefox/147.0/releasenotes, accessed 2026-08-07); it is a third-party-embed convenience and changes nothing about UIAF’s first-party design.
First-Party Storage
Section titled “First-Party Storage”Chrome applies minimal first-party storage restrictions:
- Cookies: 400-day maximum (enforced since Chrome 104, August 2022).
- localStorage / IndexedDB / Service Workers: no time-based limit.
- No machine-learning tracker classification for first-party resources.
Tracking Prevention
Section titled “Tracking Prevention”Edge uses a three-tier tracking prevention system with the Disconnect.me tracker list (B13, Microsoft Learn, verified 2026-07-19):
| Level | What it blocks | Default |
|---|---|---|
| Basic | Known harmful trackers (cryptominers, fingerprinters) | No |
| Balanced | Trackers from unvisited sites + known harmful trackers | Yes |
| Strict | All trackers from all Disconnect.me categories including content trackers | No |
InPrivate windows use the same tracking-prevention settings as regular windows; applying Strict to InPrivate is an opt-in toggle, not a default (B13).
Cookie and Storage Behavior
Section titled “Cookie and Storage Behavior”Edge inherits Chromium’s cookie handling: the 400-day cap, and no first-party storage restrictions beyond tracker classification. For classified tracker domains, Edge blocks storage access in Balanced and Strict modes; other domains behave as in Chrome.
Private / Incognito Mode
Section titled “Private / Incognito Mode”Private-mode storage is session-scoped in all major browsers and wiped at session end; normal-profile storage is inaccessible from private windows and vice versa. Specifics differ by engine (C6, B14, verified 2026-07-19):
| Browser | Private-profile cookie/localStorage behavior | Third-party cookies | Evidence |
|---|---|---|---|
| Chrome (Incognito) | incognito localStorage is one store shared across the incognito session’s tabs; cookies/localStorage cleared when the last incognito window closes | blocked by default (since Chrome 83) | C6 |
| Edge (InPrivate) | site data kept for the InPrivate session and cleared when all InPrivate windows are closed | follows the profile’s tracking-prevention settings — not blocked by default | B14, C6 |
| Firefox (Private) | cleared on window close | per TCP/ETP settings | C6 |
| Safari (Private) | Private Browsing windows isolate tabs from each other | blocked | C6 |
| Brave (Private) | cleared on window close | blocked | C6 |
Normal-mode sessionStorage remains strictly per-tab everywhere (copied to opener-spawned tabs).
Session-only identity is the maximum capability in private/incognito mode. No cross-session persistence exists.
Page Lifecycle: BFCache and Memory-Confinement
Section titled “Page Lifecycle: BFCache and Memory-Confinement”Storage classes are not the only persistence axis: the browser page lifecycle turns “in-memory only” state into a persistence class of its own. The back/forward cache (BFCache) keeps a frozen snapshot of a page on back/forward navigation instead of destroying it.
- Chrome/Edge enter
Cache-Control: no-storepages into BFCache by default since the 2025 rollout (100% March–April 2025): Chromium shipskCacheControlNoStoreEnterBackForwardCacheenabled by default with a 3-minute TTL and arestore-unless-cookie-changepolicy (developer.chrome.com/docs/web-platform/bfcache-ccns, published 2024-10-21, updated 2025-09-09; Chromiumcontent_features.cc, accessed 2026-08-07; addendum row E1). - A BFCache restore resurrects the entire page snapshot in memory, including the JavaScript heap, with no revalidation;
pageshowfires withevent.persisted === trueon restore (web.dev/articles/bfcache, updated 2026-07-02; MDNPageTransitionEvent.persisted, Baseline cross-browser since 2015-07, accessed 2026-08-07; row E2). unloadlisteners are not a cross-engine control: Safari attempts to cache pages that register anunloadlistener and does not run theunloadevent (web.dev/articles/bfcache, accessed 2026-08-07; row E3).
Consequence for consent-confined memory: UIAF’s pending-consent context is confined to current-document memory precisely so it cannot leak into a later consent state (Attribution Capture). Under BFCache that assumption fails silently. A page frozen with pending context in its heap can be restored verbatim on back/forward navigation, surviving consent changes made on other pages or tabs in the interim. Cache-Control: no-store is a cache directive, not a memory-lifecycle control, and does not prevent this. The observable hooks are pagehide and pageshow with event.persisted === true. pagehide runs as the page enters BFCache, so clearing held context there keeps it out of the frozen snapshot. pageshow with persisted detects every restore, so consent evaluation can re-run before any use of held context. The normative handling contract for pending context lives in Attribution Capture; this section is the browser-behavior explainer it builds on.
Ad Blockers and Privacy Extensions
Section titled “Ad Blockers and Privacy Extensions”Browser restrictions are only part of the constraint landscape. Client-installed content blockers add a second, filter-list-driven layer (C9).
Filter Lists
Section titled “Filter Lists”The two most relevant filter lists (contents live-grepped from easylist.to, 2026-07-19, C9):
- EasyList: blocks advertising-related resources (ad scripts, ad server domains, ad-related requests).
- EasyPrivacy: blocks analytics and tracking resources (analytics endpoints, tracking pixels, fingerprinting scripts).
Attribution matters: googletagmanager.com/gtag/js and connect.facebook.net/…/fbevents.js rules live in EasyPrivacy, not EasyList (live-grepped 2026-07-19; C9). Lists match URL patterns: any request URL matching a filter rule is blocked before it reaches the network.
What Native Integration Does, and Does Not, Change
Section titled “What Native Integration Does, and Does Not, Change”Native integration removes domain-reputation blocking: no filter list targets your own domain the way it targets googletagmanager.com. But the lists also carry domain-unrestricted path and filename rules that match first-party URLs on any origin. Concretely: EasyPrivacy carries the rule /api/collect|$ping,xmlhttprequest, a pattern that matches first-party XHR/fetch and beacon requests to /api/collect on any site. Hundreds of similar generic patterns exist (/collect?, /analytics-*, /gtm.js, /gtag/js?). Only rules scoped with $third-party or $domain= are origin-limited; these are not. (C9, easylist.to list files live-grepped 2026-07-19.)
Practical consequences:
- Avoid tracker-shaped paths and script names for your collection endpoint (
/api/collect,/collect?,/analytics*,/gtm.js,/gtag/js), and verify your chosen path shapes against the current EasyPrivacy list at release time. - Server-side forwarding is not subject to client-side extension blocking. Client-side delivery, however path-shaped, can always be blocked by some list, custom rule, or heuristic.
- When client-side collection is blocked, the implementation degrades to honest loss. It must never fabricate success or silently substitute another channel that policy does not permit.
Naming Guidance
Section titled “Naming Guidance”Choose cookie and endpoint names for collision avoidance and operational clarity, not to evade blockers. Neutral, application-specific names reduce accidental matches against name-pattern rules (_ga, _fbp, track, pixel), which is an operational-hygiene concern. Deliberately disguising tracking infrastructure as something else is not a goal of this specification and offers no durable benefit: lists and heuristics adapt.
Extension Capability by Browser
Section titled “Extension Capability by Browser”- Chrome: MV2 stable-channel disabling began October 2024; MV2 was default-off on all channels from 2025-03-31 and fully disabled in Chrome 138 (2025-07-24); the Web Store purges remaining MV2 listings on 2026-08-31 (B17, verified 2026-07-19). MV3’s declarativeNetRequest provides a shared static-rule budget of ~330,000 rules (≥30,000 guaranteed per extension), 30,000 dynamic rules, and 5,000 session rules (B18). Write blocked-request assumptions against these DNR limits: MV2-era filtering capability is no longer available on stable Chrome.
- Brave: ships built-in filter-list blocking in the browser engine itself (B5), independent of the extension platform.
- Other engines: extension-platform capability claims without a dated ledger row are omitted here; consult each vendor’s current extension documentation at implementation time.
Cookie Lifetime Comparison
Section titled “Cookie Lifetime Comparison”| Mechanism / browser | Behavior | Kind | Evidence |
|---|---|---|---|
| Safari — JS cookie after decorated navigation | 24-hour expiry | expiry | A1 |
| Safari — JS cookies & script-writable storage | purged after 7 days of Safari use without recognized first-party interaction | inactivity purge, not a lifetime | A2, A3 |
| Safari — aligned first-party server cookie | no ITP-specific documented cap; no guaranteed lifetime | — | A5 |
| Safari — CNAME / cross-party-prefix server cookie | 7-day cap | expiry | A4 |
| Brave — first-party cookies (JS or HTTP) | 6 months | expiry | B1 |
| Chrome / Edge — cookies | 400-day cap | expiry | Chromium enforcement, developer.chrome.com (2022-08) |
| Firefox — cookies | browser-enforced maximum; 400-day enforcement unconfirmed | — | B8 |
A purge measures inactivity (Safari’s clock resets on recognized first-party interaction); an expiry measures age. The two are not comparable on one time axis, which is why no numeric chart appears here.
Version Reference
Section titled “Version Reference”| Browser / component | Date | Relevant change | Evidence | Last verified |
|---|---|---|---|---|
WebKit commit a2db53cd97 | 2022-06-08 | Removed the standalone 7-day JS-cookie expiry cap; aligned JS cookies with script-writable-storage purge | A2 | 2026-07-19 |
| Chrome 104 | August 2022 | 400-day cookie cap enforced (Chromium) | developer.chrome.com cookie-max-age blog (2022-08) | 2026-07-19 |
| Chrome BTM default | October 2023 | Bounce Tracking Mitigations launched by default for users blocking third-party cookies (developer trial from Chrome 115): heuristic storage purge for bounce-redirect domains without a recorded 45-day site interaction, active when third-party cookies are blocked (e.g. Incognito) | privacysandbox.google.com/protections/bounce-tracking-mitigations; developer.chrome.com/blog/bounce-tracking-mitigations-dev-trial (accessed 2026-08-07) | 2026-08-07 |
| Firefox 86 / TCP default | Feb 2021 / 2022-06-14 | Total Cookie Protection introduced; default for all desktop users | B8 | 2026-07-19 |
| Firefox 133 | 2024-11-26 | Bounce Tracking Protection in ETP Strict | B9 | 2026-07-19 |
| Firefox 141 | 2025-07-22 | CHIPS re-enabled; known trackers switched from blocking to TCP partitioning | B11 | 2026-07-19 |
| Firefox 145 | 2025-11-11 | Phase-2 anti-fingerprinting (PB + ETP Strict); stateless BTP default in Strict | B12, B9 | 2026-07-19 |
| Firefox 151 | 2026-05-19 | Fingerprinting protection extended into Standard (default) ETP: screen resolution, touch points, canvas uniformity (~14% average / ~49% macOS uniqueness reduction per Mozilla) | firefox.com/en-US/firefox/151.0/releasenotes; Mozilla S&P newsletter 2026 Q2 (accessed 2026-08-07) | 2026-08-07 |
| Brave v1.64 | announced 2024-01-18 | Strict fingerprinting mode sunset | B4 | 2026-07-19 |
| Brave v1.83 | late 2025 | 7-day JS-cookie cap removed; unified 6-month first-party cookie cap | B1 | 2026-07-19 |
| Brave v1.85 | January 2026 | FlatBuffers overhaul of the existing Rust adblock engine (~75% memory reduction) | B5 | 2026-07-19 |
| Brave v1.89 | 2026-04-22 | Shred per-site data deletion on Android (user-initiated) | brave.com/privacy-updates/ post #37 (accessed 2026-08-07) | 2026-08-07 |
| Chrome Privacy Sandbox | 2025-10-17 | Topics, Protected Audience, Attribution Reporting (and others) retired; CHIPS, FedCM, Private State Tokens retained | B16 | 2026-07-19 |
| Chrome 138 | 2025-07-24 | MV2 fully disabled (stable disabling began Oct 2024; default-off 2025-03-31; Web Store purge 2026-08-31) | B17 | 2026-07-19 |
| Safari 18.4 → 18.5 → 26.2 | 2025-03-31 / 2025 / 2025-12-12 | CHIPS shipped → temporarily removed → restored | A6, C4 | 2026-07-19 |
| Safari 26 | September 2025 | AFP protections against known fingerprinting scripts (Apple-official) | A7 | 2026-07-19 |
| Safari 26.3–26.6 | 2026-02 → 2026-07 | No tracking-prevention changes; 26.6 partitioned-cookie deletion fix via WKHTTPCookieStore | webkit.org/blog/17798, /17862, /18178 (accessed 2026-08-07) | 2026-08-07 |
| Safari 27 beta | 2026-06-08 | No new tracking prevention announced; Secure cookies on loopback; Cookie Store maxAge | webkit.org/blog/17967 (accessed 2026-08-07) | 2026-08-07 |
| ITP 2.3 | 2019-09-23 | Last discretely numbered ITP release | A8 | 2026-07-19 |
Prioritize Safari’s constraints first regardless of market position: its restrictions define the floor a portable identity design must survive.