The report is always some version of the same thing. It logged me out again. My draft is gone. The settings I picked went back to default. It worked last month.
Nothing threw. Nothing is in your error tracker. The user is not doing anything unusual, and you cannot reproduce it, because on your machine it has never once happened.
The rule
WebKit's tracking prevention page states it plainly:
ITP deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website.
And then it lists exactly what goes:
- IndexedDB
- LocalStorage
- Media keys
- SessionStorage
- Service Worker registrations and cache
Two entries in that list are worth stopping on.
SessionStorage is there, which surprises people, because session storage dies with the tab anyway. It is on the list because the rule is about the storage form, not about how long you expected it to live.
Service Worker registrations and cache is the one that quietly matters most. An application you built to work offline stops being registered. The next visit is a cold one: everything re-downloads, the offline fallback is gone, and nobody involved connects that to a storage policy.
The clock is not seven calendar days
This is the part that makes it untestable by accident, and it is in WebKit's own announcement of the change rather than the summary page:
the seven-day cap on script-writable storage is gated on "after seven days of Safari use without user interaction on the site"
Seven days of Safari use. Not seven days on the calendar. A user who does not open Safari at all for a fortnight has not spent any of their seven days. A user who opens Safari constantly and simply does not visit you burns through them in a week.
So you cannot test this by setting a machine aside for a week, which is the obvious experiment and the one that produces a false negative. You have to use the browser without using the site.
Why it never happens to you
You interact with your own site more or less daily. The counter resets every time you do, so for you the deletion is permanently seven days away and never arrives.
The people it does happen to are the ones who use the product occasionally: monthly reporting, quarterly reviews, the person who logs in when something needs approving. They are also the users least likely to report precisely, because from where they sit nothing broke. It just asked them to sign in, which software does.
The exception that is actually useful
If the thing is added to the home screen, the rule changes. From the same post:
Web applications added to the home screen are not part of Safari and thus have their own counter of days of use.
And WebKit is explicit about intent: a first party in such a web application having its data deleted is something they "would consider a serious bug". So the installed path has a different and much friendlier clock, which is worth knowing before anyone redesigns their auth around this.
What to do, and what to collect
Do not solve it by writing more to LocalStorage. The fix is to stop treating script-writable storage as durable: anything that must survive belongs on the server behind a real session, and what stays local should be the sort of thing you can lose without the user noticing.
For diagnosis, the useful signal is not an error, because there is no error. It is the shape of the session. Was this a returning user whose client-side state was unexpectedly empty? That is one boolean you can record at load, and it turns "it logged me out again" from an anecdote into a pattern with a date attached.
The original reason for all this is in the same announcement, and it is fair: "APIs like LocalStorage have no expiry function at all, i.e. websites cannot even ask browsers to put a limit on how long such storage should stay around." Nobody gave the platform a way to say this expires, so the platform picked a number.
Top comments (0)