Apple’s annual Worldwide Developer Conference in late June this year included a couple of big announcements around Apple’s approach to privacy in their software.

The new Privacy Report in Safari 14 (on all platforms) uses DuckDuckGo’s tracker radar list to detail which of the most prominent tracking-capable domains have been flagged by Intelligent Tracking Prevention (ITP) in the user’s browser.

Apple also announced that the WKWebView class, which all iOS and iPadOS (the operating systems for iPhones and iPads, respectively) must use, will include WebKit’s ITP mechanisms on by default. The list of major browsers running on these operating systems includes Brave, Chrome, Edge, Firefox, and Safari.

The release date for iOS 14, iPadOS 14, and Safari 14 was announced at the Apple Event on September 15, 2020, and all developers working on the Apple stack groaned in unison when they learned that the new operating systems would be pushed out the following day, September 16.

Queue a mad scramble to test the app builds against the latest versions of the build tools (released just 24 hours before the operating systems were updated), and the latest set of App Store guidelines (updated a week before).

Maybe a bit longer lead time next time, please Apple?

In this article I’ll go over these changes, exploring their impact especially on analytics and digital marketing.

Also, I recommend you bookmark CookieStatus.com - a community-led initiative to maintain an up-to-date information resource on the current status of browser (and app) tracking protection mechanisms.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

The Privacy Report

Let’s tackle the easy one first.

For the first time, WebKit’s tracking prevention measures are exposed to the user (beyond enabling the Intelligent Tracking Prevention debug mode).

You can look at the Privacy Report for any site by clicking the small shield icon next to the address bar. If you want to see more details, click the (i) button.

The first thing to note is the terminology.

domain.com was prevented from profiling you across N websites.

What does that mean? It means that the Safari browser has detected HTTP requests to the listed domains, and that the listed domains are found in DuckDuckGo’s Tracker Radar lists.

To put it in another way - if the website is making requests to domains in DDG’s Tracker Radar list, then those domains will be listed in the Privacy Report.

The funky thing is that these domains might not actually have been flagged by Intelligent Tracking Prevention yet.

WebKit’s ITP is algorithmic and on-device. The decision of whether or not a domain should be “flagged” as having tracking capabilities is done based on the user’s browsing behavior and not against a domain blocklist.

So the Privacy Report is a bit misleading.

The Privacy Report means, quite simply, that WebKit’s global tracking protections, such as truncating all cross-site referrers and blocking all cookie access in third-party context have been applied to all the cross-site HTTP requests sent from the site, including but not limited to those shown in the Privacy Report.

The purpose of this approach is without a doubt to just show how the biggest trackers on the web have been prevented from cross-site tracking, but the measures are not limited to just these domains. Nor are WebKit’s ITP measures applied to these domains automatically (I repeat: WebKit does not use blocklists - it classifies domains algorithmically).

If this is difficult to follow, I don’t blame you. I’m worried this Privacy Report only serves to confuddle and obfuscate rather than to illuminate and educate. Case in point: When the release was foreshadowed in WWDC, it led to a tidal wave of misinformation spreading on the web. This prompted me to write an article on the topic in an effort to stem the tide.

Let’s recap this feature as clearly as possible:

• The Privacy Report is available in the Safari 14 browser across Apple’s operating systems (macOS, iOS, iPadOS).
• It uses DuckDuckGo’s Tracker Radar list to enumerate which known tracking-capable domains have been receiving HTTP requests from the sites the user has visited.
• The report highlights how some of the most prominent tracking domains (e.g. facebook.com and doubleclick.net) have been prevented from accessing the user’s browser storage, among other things.
• Since WebKit blocks all access to cookies in third-party context, the full list of “prevented” domains comprises all the cross-site requests done from the sites the user visits, not just those listed in the Privacy Report.
• If a domain is listed in the report, it does not mean that the domain has been flagged by WebKit’s Intelligent Tracking Prevention. This classification is still algorithmic and still based on the sites the user visits, and what types of cross-site requests these sites do.
• Finally, Safari does not block requests - it strips them of the capability to access cookies or parse referrer headers, etc.

I recommend you visit the Safari page on CookieStatus.com for a more detailed walkthrough of what WebKit does by default, and what is behind Intelligent Tracking Prevention’s flags.

Tracking prevention in all iOS and iPad browsers

The more interesting, and perhaps more convoluted, update was that Apple is updating the WKWebView class. Per the App Store guidelines, all web browsers running on iOS must implement this class, though officially there’s a transition period from the deprecated UIWebView to WKWebView which lasts until December 2020.

And what’s the update? Well, nothing more and nothing less than that all WebKit’s Intelligent Tracking Preventions are on by default in all browsers running WKWebView in iOS 14 and iPad 14.

At the time of writing this, all browsers apart from Brave have updated to the latest OS requirements, and Brave should follow up with a new build very shortly.

The main change can be found in Settings for each browser app. This is what Firefox looks like:

Across all iOS and iPadOS browsers, the new setting “Allow Cross-Website Tracking” is toggled off. This means that all these browsers are now implementing the full scale of WebKit’s Intelligent Tracking Prevention mechanisms.

These include, among others:

1. Full third-party cookie blocking. All cookie access in third-party context is blocked. There are no exceptions. Storage access can only be granted through the Storage Access API.

2. All cross-site referrers are downgraded to just the origin by default (https://www.domain.com).

3. All cookies written with JavaScript will have their expiration capped at a maximum of 7 days from the time the cookie is (re)written.

4. Algorithmic classification of domains the browser communicates with. The classifier detects if the sites the user visits communicate with cross-site origins to a point where the classifier deems these domains to have cross-site tracking capabilities. At this point, additional restrictions that apply to classified domains kick in:

   4.1. All storage on these domains is purged after 30 days of the user not directly interacting (i.e. in first-party context) with the classified domain.

   4.2. If the classified domain sends traffic to other sites, appending parameters into the URLs (such as a Google ad click), then any JavaScript cookies written on the sites the links lead to will have their expiration capped at 24 hours.

   4.3. If the classified domain sends traffic to other sites, and the classified domain has URL parameters (or fragments) in the URL, the document.referrer string on the target site will be truncated to just eTLD+1 (so https://www.simoahava.com/some-page becomes https://simoahava.com/).

Note! At the time of writing, there seems to be a bug with the implementation across iOS browsers, and not all these mechanisms are in effect even if the “Allow Cross-Website Tracking” toggle is left to its default position of OFF.

This is … pretty big. The development of these web browsers is now intrinsically linked to the evolution of WebKit’s tracking prevention mechanisms. For example, when the upcoming CNAME cloaking mitigation sees daylight, it will be applied to all iOS / iPadOS browsers, and not just Safari as before.

Impact #1: Cross-site targeting and profiling

As third-party cookies are now flushed out of the mobile operating systems, it means that any cross-site tracking scheme that relies exclusively on these is dead in the water. Google’s DoubleClick network, for example, will no longer be able to build a cross-site profile of web users based on the sites they visit, as they will no longer be able to associate a cookie identifier to these hits.

It’s unlikely that ad tech vendors have the gall to use the Storage Access API to ask permission of the user to track them across sites.

Vendors are, naturally, busy at figuring out workarounds. Those that own an identity platform (e.g. Facebook), have for long been moving cross-site tracking away from third-party context, and others will likely follow suit.

Reliance on fingerprinting will likely increase, even though these measures are addressed by WebKit as well.

The cat-and-mouse game continues.

Impact #2: First-party analytics, optimization, personalization

Services that run in first-party context are not without impact either.

WebKit restricts the lifetime of JavaScript cookies to a maximum of 7 days, with the limit set to 24 hours in some instances.

This can have an impact on the ratio of “new” and “returning” users in analytics tools, and the likelihood of the same individual being included in different experiment groups increases, for example.

There is a known mitigation for this, which does not go against WebKit’s policies: sites can recycle cookies so that they are set in HTTP headers instead.

Impact #3: Referrer truncation

WebKit’s approach to referrers is similar to strict-origin-when-cross-origin, except this is not a “default” referrer policy (it’s always on), and it’s more like strict-origin-when-cross-site.

In other words, when the website makes a cross-site request (e.g. https://www.simoahava.com/some-page/ to https://www.google-analytics.com/collect), the referrer visible to google-analytics.com will be just the origin: https://www.simoahava.com/.

If the website makes a cross-origin (but same-site) request, the referrer string will be untouched.

Additionally, if the website is classified by ITP as having cross-site tracking capabilities and it has query parameters (or fragments) in its URL, then any site it sends traffic to will have the document.referrer string truncated to only eTLD+1 (so https://www.simoahava.com/some-page/?key=value will show up as https://simoahava.com if the domain has been classified by ITP).

Truncating the referrer like this has obvious impacts for analytics, for example, as understanding what sites and pages send you traffic has been a staple of web analytics for a long time.

New App Store Review guidelines

Apple also updated its App Store review guidelines a week before iOS 14 and iPad 14 were released. I recommend checking out Cory Underwood’s overview of the topic - the changes can be quite impactful for apps that also collect data from users.

Apps will basically have to:

• Disclose in detail what type of data collection goes on.

• Provide an opt-in mechanism to the collection of user and usage data.

• Not put up consent walls (allow the user to access content only if they give consent to tracking).

• Implement an opt-out mechanism as well, where if the user withdraws consent, their data should be purged.

There are echoes of GDPR and CCPA here, with the exception that Apple is a private company and not a legislative body. They have far more coverage than the aforementioned legal frameworks, and as these guidelines have a direct financial impact on organizations (loss of revenue if apps are removed from the store), they will likely inspire far more and faster action than any laws or regulations.

Summary

iOS 14, iPadOS 14, and Safari 14, are major releases at least when it comes to privacy protections in software running on Apple’s operating systems.

Browsers running on iOS and iPadOS now must implement WebKit’s ITP mechanisms, which, given iPhone and iPad market share, can have a resounding impact on organizations relying on data collection and sharing.

What’s imperative now is that each organization starts benchmarking and modeling the impact of third-party cookie blocking and first-party cookie restrictions on their own data. Please try to avoid contributing to the FUD with knee-jerk reactions such as “DATA IS DEAD” or conjuring doomsday predictions based on circular reasoning.

The only thing that panic serves is the rapid spread of misinformation. And the only thing that misinformation feeds is diverting attention away from what WebKit is doing with these tracking prevention policies: eradicating cross-site tracking vectors from software and services running on the Apple stack.

Please let me know in the comments if something was unclear. Note that the releases are still quite fresh, and testing them due to bugs might lead to inconsistent results.

Be sure to monitor CookieStatus.com as well. If you have information that’s missing from the service, please submit an issue about it.