Tags: web-dev analytics concept

Browser Privacy Restrictions

Date: 2026-08-16

---

Browsers now decide how long your identifiers live, and the answer is often days rather than years. The mechanisms are durable; the specific limits and the state of third-party cookies change constantly, so treat every number here as needing a check.

---

What it is

Browser privacy restrictions are engine-level limits on storage lifetime, cross-site data access and identifier persistence, applied regardless of what the site requests.

The important shift: cookie lifetime is no longer something you set. You request a duration and the browser decides what it grants.

The mechanisms

Durable, whatever the current numbers are.

Storage lifetime caps. Safari’s Intelligent Tracking Prevention caps cookies written by JavaScript via document.cookie at 7 days, and at 24 hours when the visitor arrives on a URL carrying tracking parameters such as gclid or fbclid. Cookies set by the server in a Set-Cookie response header are not capped the same way and keep the expiry given. [CHECK: verify against WebKit’s own posts — the figures here come from vendor documentation and have moved before.]

That single distinction is the reason server-side cookie setting is now standard advice for measurement — see Cookies and Server-Side Tag Management.

Storage partitioning. Third-party storage is keyed by the top-level site as well as the third party’s own origin. An embedded widget on two different sites gets two separate stores and cannot connect them.

Script-writable storage deletion. Safari deletes localStorage, IndexedDB and script-set cookies for sites the user hasn’t interacted with for a period. An identifier in localStorage is not a durable workaround for a capped cookie — Client Storage.

Tracking prevention lists. Firefox and others block known trackers outright by domain, independent of any cookie attribute.

Third-party cookies — the current position

This has reversed direction and is the thing most likely to be out of date in anything you read.

• Google abandoned the plan to remove third-party cookies from Chrome, announced July 2024, with no replacement date
• In 2026 Chrome presents users with a privacy choice, making third-party cookies opt-in rather than removed
• Privacy Sandbox was retired. Google announced in October 2025 it would wind down most of the APIs — Topics, Protected Audience, Attribution Reporting — with deprecation beginning in Chrome 144 (January 2026) and removal targeted for Chrome 150 (July 2026). CHIPS, FedCM and Private State Tokens survive
• Safari and Firefox block third-party cookies by default and have for years, independently of any of this

[CHECK: this is the single most volatile area in the vault. Verify before relying on it — figures captured 2026-08-16.]

In plain terms: the industry spent five years preparing for third-party cookies to disappear from Chrome, and then they didn’t. What did happen is that first-party identifiers got much shorter-lived, which is a quieter change and affects measurement more.

What it does to measurement

The consequences you’ll actually meet:

• Returning visitors read as new. A Safari user returning after eight days has a fresh identifier, so User Counting inflates and returning-visitor rates fall
• Attribution windows silently truncate. A 30-day lookback is meaningless when the identifier lives 7 days. Upper-funnel touchpoints vanish and credit collapses onto the last session — Attribution Models, Identity Stitching
• The effect is uneven by browser, so device and browser segments aren’t comparable, and any shift in browser mix looks like a behaviour change
• Long experiments contaminate. Assignment stored client-side decays over months, so users get reassigned mid-test — Test Duration, Assignment and Bucketing
• Gradual, undatable metric decline as the effect compounds — a standing row in the symptom list

Responses

Ordered by how much they actually help:

1. Server-set cookies via Set-Cookie from your own domain. The single highest-value change, and it sidesteps the JavaScript cap entirely
2. Server-side tracking so measurement doesn’t depend on the browser storing anything — Client-Side vs Server-Side Tracking
3. Authenticated identity. A logged-in user has a durable identifier that no storage policy touches. This is the only genuinely robust answer, and it’s a product problem rather than a measurement one
4. Shorter attribution windows, honestly chosen to match what your identifiers can actually support
5. Aggregate methods — Marketing Mix Modelling, Incrementality Testing — which don’t need user-level identity at all

What doesn’t help: moving identifiers to localStorage, or setting longer expiry values and hoping. Both are ignored by the mechanisms above.