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.
In this version, Safari (and soon all WebKit browsers, including browser apps on iOS and iPadOS) placed an expiration limit on browser cookies set with JavaScript. It was no longer possible to set the expiration date further than 7 days in the future.
In a recent 2022 release (I don’t have the exact date or version number), WebKit has now modified this mechanism to no longer set an expiration cap on JavaScript cookies.
This does not mean that WebKit rolled back the change from ITP 2.1. Rather, it means that WebKit is converging the restrictions placed on all script-writable storage, which includes JavaScript cookies.
The Simmer Newsletter
Follow this link to subscribe to the Simmer Newsletter! Stay up-to-date with the latest content from Simo Ahava and the Simmer online course platform.
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:
- IndexedDB
- LocalStorage
- Media keys
- SessionStorage
- 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.
With this recent change, JavaScript cookies are now included in this list of storage mechanisms that get purged.
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
In ITP 2.2, WebKit introduced an additional limitation on first-party cookies.
If the user clicks a link on a website whose domain is classified by ITP as having tracking capabilities, and the link includes URL query parameters and/or hash fragments, then an additional limitation is placed on JavaScript cookies set on the page the user navigated to.
In such cases, any JavaScript cookies set on the page will have a maximum expiration of one day.
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.
Summary
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.
Together with this recent change to how JavaScript cookies no longer have an expiration cap, we arrive at an interesting conclusion: in many cases it’s possible that JavaScript cookies are more long-lived than their HTTP counterparts.
HTTP response cookies set from servers behind third-party CNAMEs or third-party IP addresses will have their expiration limited to just seven days. JavaScript cookies have no expiration cap (although a 400 day maximum might be introduced at some point).
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.