Apple’s WebKit team is out with another update to Intelligent Tracking Prevention (ITP) for Safari that targets potential tracking workarounds.

In a blog post titled “Preventing Tracking Prevention Tracking,” WebKit’s John Wilander laid out three updates to fight detection of “which content and website data is treated as capable of tracking” and “improve tracking prevention in general.”

First, some background on Safari, ITP and cookie blocking. Safari has long restricted entities from setting third-party cookies if they don’t already have first-party relationships with users. Then ITP came on the scene in 2017 to identify and limit cookies of any type that have the ability to track users across sites. This severely limits cookie pools for audience targeting, including retargeting campaigns. Furthermore, it limits analytics and attribution data from Safari, which means marketers lose visibility into how their campaigns are performing with typically high-value iOS users.

If you thought Safari and ITP’s previous iterations had pretty well done in third-party cookies, you’d be right, but there are more holes to plug. The updates below apply to Safari on iOS and iPadOS 13.3, Safari 13.0.3 on macOS Catalina, Mojave, and High Sierra.

Cross-site request referer headers

The change. “ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.”

What is a cross-site request header referrer? When a user loads a web page with embedded content from another domain, as in a tracking pixel, the request header referrer for the tracking domain will no longer contain the full web address of the host page, only the domain name. That used to be done only for sites classified as trackers.

What the change means. Of the updates, this is the one that will have analytics implications. If a user loads a page from one web site with assets embedded from another, Safari will strip out the URL details contained in the request referrer header.

This means analytics will only show the referring domain, not the referring page.

Example. A user loads a page with assets from https://images.example via https://store.example/baby/strollers/deluxe-stroller-navy-blue.html. In Safari, the referrer header value will not contain that entire URL path. It will only include the root domain https://store.example/.

In this case, analytics provided by https://images.example would only record https://store.example as the referrer and not the full referrer path of /baby/strollers/deluxe-stroller-navy-blue.html.

(More) third-party cookie blocking

The change. “ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.”

What the change means. This is really aimed at preventing attackers from “seeing their cookies.” It is minor from a marketer’s perspective but further reinforces the need for first-party relationships with users. If you have widgets placed on other sites, it doesn’t matter what your domain classification is, you will need to have a prior first-party relationship with a user in order to see your cookies on those sites. This has been the case in most contexts already.

Example. A user clicks on a YouTube video embedded on a news site. If that user has not previously logged into or visited and accepted cookies at YouTube.com, YouTube will not be able to track engagement from that site.

If you’re not a heavily trafficked site like YouTube and count on tracking from widget embeds, you have little to no visibility into Safari users.

Storage Access API update

The change. “As of this ITP update, the Storage Access API takes Safari’s cookie policy into consideration when handling calls to document.hasStorageAccess().

Now a call to document.hasStorageAccess() may resolve with false for one of two reasons:

1. Because ITP is blocking cookies and explicit storage access has not been granted.
2. Because the domain doesn’t have cookies and thus the cookie policy is blocking cookies.”

What is the Storage Access API? This API enables third-party embedded content to gain access to storage that is typically only accessible in a first-party context. With the Storage Access API, embedded items can determine if they have access and request it from the browser’s user agent.

Typically browsers will not give third-party embedded resources access to the same set of cookies and site storage. And document.hasStorageAccess() indicates whether the document has access to its first-party storage.

What it means. This, too, is aimed at attackers and will have little marketing implication. Detlef Johnson, Search Engine Land’s resident technical SEO expert, explained it this way, “The Storage Access API change is about closing a gap of a false positive API response pertaining to the third-party cookie policy of a given website. For an example of another attack vector, an attacker could previously figure out if YouTube is classified by ITP as a tracker or not by making a malicious request and testing for side effects of whether cookies were sent or not.”

Why we care

It’s important to understand how Safari and ITP affect your ability to target and measure ad campaigns.

Apple is not an ad-driven business and has staked its branding on protecting user privacy. As ITP’s restrictions have evolved, advertisers have had to continue to adjust expectations as Safari becomes a bigger black hole. Publishers and third-party adtech firms have felt the pinch. A recent report by The Information (subscription required) found CPMs for Safari users have plummeted as a result of not being able to sell ads based on cookied browsing behavior, while CPMs for typically less-valuable Google Chrome users have ticked up.