Question
Safari ITP storage limits: which cookie and localStorage lifetimes apply when testing an integration without production credentials
Rahul Echo
0 reputation · 03 Apr 2020, 19:09 UTC
90.6K views1
Loading…
0 reputation · 03 Apr 2020, 19:09 UTC
I'm validating a web integration that relies on first-party cookies and localStorage for session state, and I need to test it in Safari without using production credentials. The concern is Intelligent Tracking Prevention: client-side cookies set via document.cookie are documented as capped at 7 days, and storage can reportedly be deleted sooner for domains classified as having tracking behavior when the user doesn't interact with the site.
The unresolved part is the boundary between those two outcomes. The 7-day cap is documented, but the shorter deletion path depends on Safari's on-device classification, which isn't publicly specified in deterministic terms. That makes it hard to know what a test environment on a throwaway domain should expect, and whether a state loss I observe is an application bug or ITP eviction. Behavior also appears version-sensitive, so results from one Safari release may not transfer.
My constraints: current Safari on macOS, no production credentials, and I can use Web Inspector's Storage tab plus system-date changes to simulate elapsed time.
Specifically:
30275 reputation · 03 Apr 2020, 20:51 UTC
Treat the 7-day cap as a worst case, not a guaranteed outcome. In current Safari, script-written cookies (document.cookie) are capped at 7 days on domains ITP has classified as having tracking behavior; server-set first-party cookies with a proper Set-Cookie header are not subject to that client-side cap. localStorage and IndexedDB are subject to a separate eviction rule: script-writable storage can be deleted after roughly 7 days without user interaction, again only for classified domains. On a throwaway test domain with no tracking signals, you will most likely never hit either path — which is exactly why a state loss you observe is more probably an application bug than ITP.
No, not reliably. ITP classification is heuristic and happens on-device; Apple does not expose a deterministic API or flag you can query, and there is no supported way to force a domain onto the classified list. The practical implication for your test plan:
Mostly no. Advancing the system date will trip the browser's own cookie expiry (the Expires/Max-Age check), so it is a valid way to test your 7-day-cap handling for script-set cookies. But ITP's eviction logic is driven by its own bookkeeping of user interaction, not simply by wall-clock reads, so clock manipulation is not a faithful simulation of the deletion-after-no-interaction path. Treat clock changes as a test of cookie expiry only, and use explicit data clearing to test the eviction-recovery path.
Yes — treat all script-writable storage (localStorage, IndexedDB, Cache API) as subject to the same eviction regime as script-written cookies for classified domains: deletion after a period of no user interaction. Server-set first-party cookies are the exception and the durable option. So for session state that must survive, prefer a server-set, HttpOnly; Secure; SameSite=Lax cookie over anything written from JavaScript.
safariSet-Cookie and one via document.cookie, and confirm attributes and expiry in Web Inspector > Storage.One caveat: if your staging flow redirects through or embeds a known tracking domain, Safari may treat it more strictly than your production same-site flow — another reason to keep mocks on your own registrable domain.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 04 Apr 2020, 05:47 UTC
Web Inspector's Storage tab confirms the 7-day cap on script-written cookies, but it does not expose ITP's heuristic purge timing for localStorage and IndexedDB. The Expires/Max-Age column will show the truncated 7-day date for document.cookie and the original date for server-set Set-Cookie, which is a useful version assumption check for current Safari on macOS.
It does not surface the interaction-based deletion window that applies to script-writable storage on classified domains. For testing recovery paths without production credentials, clearing website data via Settings > Privacy > Manage Website Data or using a fresh private window reproduces the effect of eviction more deterministically than waiting on wall-clock expiry.