If you recall, in February 2019, Apple published a post on the WebKit blog, which introduced version 2.1 of their Intelligent Tracking Prevention browser mechanism.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
All script-writable storage is deleted when site is not interacted with
WebKit browsers already had a tracking prevention policy in place for other script-writable storage. These include:
- Media keys
- Service Worker registrations and cache
The policy is that if the site does not receive a user interaction (click, tap, or keyboard input) in 7 days of browser use, all this script-writable storage for the site gets removed.
Note that 7 days of browser use is not the same as 7 calendar days. The user might use the browser every day, in which case they are the same thing, or the user might take breaks of days, weeks, or even months in between days of browser use.
To prevent this deletion from happening, the user must visit the website and perform a meaningful user interaction (click, tap, or keyboard input) with the site in first-party context (so loading the site in an embedded iframe would not do by itself). This resets the deletion timer back to 0.
Note that embedding the site in an iframe and using the Storage Access API with it does count as meaningful interaction with the site and also resets the deletion timer.
24-hour expiration cap in some cases does still apply
This remains unchanged and places great constraints on cookies set by companies like Google or Meta after the user clicks an ad or a “regular” link while using these platforms.
After a long period of little activity, it seems like WebKit is coming in for another round of tracking preventions to keep ahead of the cat-and-mouse game with ad tech.
In Safari Technology Preview 157, there’s a new feature being tested that would limit the expiration of cookies set in HTTP response headers to just 7 days in case the response originates from a server whose IP address subnet does not match that of the site making the request. Yes, that’s a mouthful. You can check my Mastodon post and Cory Underwood’s blog post on the topic for more information.
This places limitations on how effective solutions like server-side Google Tag Manager are in creating more durable first-party cookies.
However, for this to happen, the user would still need to periodically visit the site and meaningfully interact with it. Just using the browser isn’t enough.
I wouldn’t read too much into this, though. The difference between 7 days of browser use and 7 calendar days is often non-existent. So I wouldn’t count that this change will drastically “improve” your analytics data, for example.