Safari ITP storage limits: which cookie and localStorage lifetimes apply when testing an integration without production credentials
20.5K 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:
- Is there a reliable way to determine whether a test domain has been classified by ITP, or to force the shorter-deletion path for testing?
- Does simulating time passage via the system clock actually exercise ITP's expiry logic, or only the browser's own cookie expiry?
- Should localStorage and IndexedDB be treated as subject to the same eviction rules as script-written cookies in current Safari?
0 answers
A thoughtful contribution can make all the difference. Be the first to share one.
0 question comments
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.