Safari ITP 2.3 Update Hamstrings localStorage Workaround, As Expected

In September, Apple released a highly predictable update (I called it in June) that killed the localStorage workaround. Because using localStorage was a quick workaround to their first-party cookie limitations, we expected Apple’s Safari would eventually have to limit localStorage as well. That’s exactly what they did in the September ITP 2.3 update. So the general rule is, “If you have an obvious workaround (even the obvious workaround like link decoration that Apple recommended), Apple will eventually go after that workaround to make it less effective.”

Here is what Apple says about new localStorage limitations:

“After seven days of Safari use without the user interacting with a webpage on website.example, all of website.example’s non-cookie website data is deleted.”

Side Note: I still feel like their example domain names should be something like “website.example.com” as most people are familiar with domains that end in “.com” as opposed to “.example”, but oh well.

This says that if the browser sees someone return to the domain that used localStorage within 7 days, it will not delete localStorage. So, if you were using the localStorage workaround to avoid first-party cookie limitations, this is still a good workaround for seven days. If you’re a website that has returning visitors on a daily basis, no problem at all. If you’re a website that wants to understand if the same person from two weeks ago (who clicked on an ad) came back to your site to make a purchase, then you’re out of luck. The only way you can connect the dots would be to have another type of persistent identifier other than a client-side one. Longer-term persistent identifiers are becoming more difficult to come by.

Enterprise software companies will typically be able to setup a CNAME to make sure that your data collection endpoint is first-party. I *think* that the server-side first-party cookie that results from this setup is the next best workaround — available to those who use something other than Google Analytics as their primary data collection. The only browser (it seems) that is setup to potentially block these requests would be Firefox — this might happen when a CNAMEd first-party endpoint ends up on their disconnect.me list. Right now, this seems unlikely, but as I type this, I expect Apple is reading. The question that remains to be answered is whether Apple will find a way to “intelligently” (with machine learning) categorize even first-party domains as “trackers” in their system.

Assuming you have consent (take a look at CCPA law), you could leverage a high-performance CDP such as Tealium to also send data along server-side to Google Analytics — this solves for the case when Google Analytics is blocked on the client. The Enterprise CDP allows one, via the first-party middle-man, to distribute event data from a server-side data hub.

Firefox brands their unique approach to blocking cookies and data collection as “ETP” (Enhanced Tracking Prevention).  Firefox’s approach is this: instead of limiting client-side persistent visitor identifiers, why not just block all outgoing requests to vendors such as Google Analytics? Apple takes the approach that using “Intelligence” and “Feature Restriction” will limit the ability to track someone across sites or across visits. These are more limitations than blocking.

Firefox, on the other hand, blocks network requests entirely by maintaining a list (via their partner “disconnect.me”) of all know Tracker endpoints. Keeping a long list of domains to block is a fairly effective strategy for blocking the popular tracking endpoints, but it requires constant maintenance and the occasional dispute resolution. One potential issue would be when the wrong endpoint gets on this list. When this happens, we blame Firefox for a weird experience on the web. Apple’s Safari limitations might simply make for an annoying experience on the web — we might think, “It is extremely frustrating that I have to enter my postal code again on this site.” But I wonder if the typical mobile phone web user will know to blame Safari for the frustration.

Looking towards the future

I expect more browsers to be self-promoting of what they are blocking. Firefox displays a shield icon next to the URL — they promote this symbol as the constant visual reminder of their vigilance. By typing in “about:protections” in the Firefox browser you get a report that totals the number of blocking events in the last week. Other notifications are more subtle and require the Web Console (which only developers use). For example, the Firefox web console shows when a browser is blocking Google Analytics or other known tracker. The following message is displayed: “Request to access cookie or storage on “<URL>” was blocked because it came from a tracker and content blocking is enabled.”

Google Chrome is now warning people (in the Web Console) that their SameSite updates are coming soon — they issue a warning about third-party cookies that will no longer be available for reading.  Google is even reporting this for their own cookies in the doubleclick.net domain (as noted in this TLC post).

I also expect browsers to have a “Here is what we are blocking, should we continue?” type of prompt. These preferences would also be exposed in the browser’s privacy settings control. Machine learning systems will need feedback — they will get it wrong and need to be “trained” on how to behave. The browser should not consider itself too smart. Eventually, we arrive upon a web browser’s built-in version of “Consent Management”. The browser that provides this in a smart and simple way wins the minds of technologists and ultimately the general web browsing population.

What happens next?  While cookies are still around, a new long term solution may be required. Web analytics, while still an important part of the ecosystem, is fundamentally changing through this and other factors, including privacy regulations.

The new Digital Marketing tool of choice is the Customer Data Platform. An Enterprise-grade CDP like Tealium AudienceStream that’s focused on first-party data could be setup to persist a server-side visitor id and connect the dots in the cloud. Leveraging a CDP as a real-time data hub also means that you can push massive event volumes to the server and from there move data out to the many vendors in your Digital Marketing arsenal.

If necessity is the mother of invention, we can expect a lot of inventive solutions as the cookie continues to evolve.

Stay up to date by tuning into our blog regularly.