What Is Intelligent Tracking Prevention and How Does It Work? [versions 1.0 – 2.3]

Apple has built a strong reputation as a leader in tech innovation, and has stayed at the forefront of user privacy protection as well. With its update of iOS 11 and Safari, the company is taking the privacy of its customers one step further with a feature known as Intelligent Tracking Prevention.

What is Intelligent Tracking Prevention?

Intelligent Tracking Prevention is a new feature of WebKit, an open-source web-browser engine that powers Apple’s Safari web browser, among others, shipped out in the new release of Safari 12 and iOS 11.

The feature aims to further protect users’ online privacy by changing the way Safari handles first-party cookies.

How Does Intelligent Tracking Prevention Work?

Before the notion of Intelligent Tracking Prevention, Safari desktop and mobile browsers blocked third-party cookies by default and allowed iOS users to block ads by installing Safari extensions, aka content blockers (available from iOS 9 onwards).

First-party cookies have traditionally been safe from any sort of automatic blocking or removal, as they are responsible for providing a seamless user experience.

For example, first-party cookies can keep the session information open, which can remember things like:

• Our login status, which can be used to keep you logged into to websites and applications.
• Which products you added to shopping carts.
• Website settings, such as which language version you have chosen.
• Values you’ve entered into forms (e.g. name, email, and company on a white paper download form).

However, some first-party cookies can be used to track users in the same way as third-party cookies, and the release of Safari 11 took aim at this kind of data.

When First-Party Cookies Become Trackers

Most people don’t associate first-party cookies with trackers, but there are certain situations where this is possible, and this is where things start to get a bit tricky.

To help explain this point, let’s look at an example of how a first-party cookie could be used to track users across the Internet while using either a desktop or mobile Safari browser (or any other web browser).

Example — A User Clicks on an Ad

For this example, we’ll look at it how this process works with Safari browsers, but it would work in a similar way on other browsers — depending on how they handle first- and third-party cookies.

Here is what’s happening in the image above:

1. The user visits a website and a first-party cookie (xzy890) is created by the website in its domain (example.com) and assigned to the user.
2. The user then clicks on the ad and is directed to the AdTech platform’s domain (ad.ads-r-us.com).
3. The AdTech platform creates a first-party cookie (klm456) under its domain (i.e. ads.ads-r-us.com) and assigns it to the user.
4. The AdTech platform then redirects the browser to the advertiser’s landing page (www.usedcarsite.com).

It’s important to note that the reason the AdTech platform is able to create a first-party cookie is because the user clicked on the ad, which was then directed to the AdTech platform’s domain. This allows Safari to interpret the cookie as a first-party cookie. If the user had not clicked on the ad, then the AdTech platform wouldn’t have been able to create a third-party cookie, as Safari blocks them by default.

As the AdTech platform has created a first-party cookie under its domain (ads-r-us.com) and assigned it to the user, it can now track the user as they move around the web and serve them with personalized ads.

However, this ability for first-party cookies to act as trackers changed slightly with the release of ITP 1.0, and has since been further limited to combat various workarounds developed by AdTech vendors.

So far there have been six releases of ITP — 1.0, 1.1, 2.0, 2.1, 2.2, and 2.3.

Intelligent Tracking Prevention (ITP) Versions 1.0 and 1.1

Here’s a brief breakdown of how Intelligent Tracking Prevention works:

1. Intelligent Tracking Prevention incorporates a machine-learning model (known as the Machine Learning Classifier) to assess which privately controlled domains have the ability to track users across different websites. This model is based on statistics collected by the browser.

2. If the Machine Learning Classifier identifies that a particular first-party cookie (e.g. ad.ads-r-us.com) can be used for tracking, then the cookie will be blocked unless you use the Storage Access API to ask users to allow the use of your cookie (more on that below).

To explain how the first versions (1.0 and 1.1) of ITP worked, we’ll take a look at some scenarios:

Scenario #1: 0-24 hours after clicking on the ad

In versions 1.0 and 1.1 of ITP, there was a feature that allowed first-party trackers to behave like third-party trackers as long as the user visited the website within 24 hours.

Here’s how it worked:

A user visits a website (example.com) and clicks on an ad. The AdTech platform (ads-r-us) displaying the ad would create a first-party cookie for that user. If the user then visits ads-r-us.com within 24 hours after clicking on the ad, then the first-party cookie from ads-r-us.com would be able to function as a third-party tracker.
In this case, the cookie could have been used in a third-party context, e.g. for retargeting.

It’s important to note that in order for this situation to work, the user would have had to actually visit the AdTech platform’s website (ads-r-us.com), which is extremely unlikely to happen as most users don’t visit these types of websites at all. See below for a workaround some AdTech vendors used.

However, users regularly visit sites like Facebook, or use Google’s services (e.g. mail.google.com), or visit websites run by other walled-garden advertising companies, meaning these companies had a better chance of keeping their tracking cookies active (more on this below).

Scenario #2: 24h-30days after clicking on the ad

The user doesn’t visit ads-r-us.com within 24 hours of clicking on the ad. However, they do visit the site 3 days after clicking on the ad.

In this case, as the user didn’t visit ads-r-us.com within 24 hours, the cookie created by ads-r-us.com cannot be used in a third-party context — e.g. it can’t be used for ad retargeting and would have to display a non-retargeted ad to the user.

After that 24-hour grace period, the cookies should be stored in a first-party context or, preferably, as HTTP cookies (more on this later) to avoid these issues altogether. This is to prevent them from being used for retargeting, but still allow other purposes like maintaining a single sign-on session.

Again, this scenario doesn’t apply anymore due to the Storage Access API.

Scenario #3: 30 Days After Clicking On the Ad

The user doesn’t access ads-r-us.com at all within 30 days of clicking on the ad.

If 30 days have passed since the user clicked on the ad without interaction with the tracking domain, all cookies would be purged from the tracking domain. In this case, the first-party cookie created by ads-r-us.com will be purged.

ITP 1.1

ITP 1.1 introduced changes which made it easier to use third-party services that serve embedded content (e.g. embedded video), or social logins. This was because ITP 1.0 defeated the whole purpose of embedded content, and basically required users to visit services in a first-party context before using widgets on a site.

Possible workarounds for versions 1.0 and 1.1 of ITP

In order to get around this problem the limitations imposed by versions 1.0 and 1.1 of ITP, some publishers (under the guidance from their AdTech partners) implemented a workaround by adding a unique query string parameter (aka retargeting script) to internal URLs, so that when a user clicked on an internal link on a publisher’s webpage, they were first directed to the AdTech vendor’s domain and then on to the target URL.

This meant that users were often “visiting” the AdTech platform’s domain, meaning their first-party cookies were able to avoid being purged (deleted) after the 24-hour window and continue to function as a tracking cookie.

However, Intelligent Tracking Prevention 2.0 completely scrapped this 24 hour window, meaning that if a domain is deemed to have tracking capabilities, then it can’t be used in a third-party context unless the user agrees via the Storage Access API.

Intelligent Tracking Prevention (ITP) 2.0

The June 2018 release of ITP introduced a couple other major inclusions, which seriously impacted reporting, affiliate marketing and attribution techniques — more so than before.

Scrapping of the 24-hour cookie access window

As mentioned above, ITP 1.0 and 1.1 allowed cookies to be read and used in a third-party context, provided the user accessed the domain directly in the first 24 hours.

With ITP 2.0, this is no longer possible – the 24-hour grace period was scrapped.

On Safari, websites can no longer leave cookies in the user’s browser for later retargeting and attribution purposes. This impacts companies that access their first-party cookies in a third-party context, and as a result, compromises reporting capability and accuracy.

The lack of a cookie-access window is somewhat connected with user prompts for Storage Access API.

Prompt For the Storage Access API

The next major change to ITP was the introduction of the Storage Access API prompts.

Sites like Facebook typically allow users to log in to their accounts on multiple websites to facilitate easier commenting or liking content on third-party sites. Originally, ITP 1.1 enabled embedded content to access the cookies stored on the third-party domain without displaying user prompts – as long as the content provider followed certain rules.

ITP 2.0 now detects such cross-site tracking and partitions the cookies, eliminating their ability to be utilized in a third-party context (e.g. for tracking). This is an indirect jab at companies that created workarounds for previous versions, as well as walled gardens like Facebook and Google, limiting their tracking possibilities and negatively impacting the user experience on sites that use such commenting or liking widgets.

Third-party embedded widgets that enable liking and sharing (like on Facebook) now have to request access to their first-party cookies when the user interacts with them on different websites. This is usually done by displaying a consent box like the one below:

It’s important to note that the user would be shown this prompt on every website they visit containing an embedded Facebook widget, except on subdomains; for instance, they wouldn’t be shown the prompt on video.example.com if they previously selected “Allow” on example.com.

If the user doesn’t interact with Facebook again (either via facebook.com or via its embedded widgets) after 30 days, their cookies will be purged.

Protection Against First Party Bounce Trackers

Another feature of ITP 2.0 is the ability to detect when a domain is used exclusively as a “first-party bounce tracker,” meaning that it is never used as a content provider and only tracks the user through a series of fast, navigational redirects.

First-party bounce trackers work when the user clicks on a link on social media, and then, instead of taking the user straight to their destination, rapidly opens a series of bounce trackers.

Such tracker domains are created for the sole purpose of storing information about the user’s browsing history in their first-party storage and cookies. ITP 2.0 detects such behavior and treats those domains just like any other tracker (by purging them).

Protection Against Tracker Collusion

Protection Against Tracker Collusion identifies redirects utilized for tracking purposes only – i.e. for piggybacking and cookie syncing. Think of it as a situation in which a number of trackers communicate to exchange information about the user’s behavior.

ITP 2.0 detects this behavior via something known as a collusion graph and classifies all domains involved in the redirects as trackers.

This feature stops cookies from being dropped or read on a user’s browser during such redirects, which negatively impacts affiliate marketing and data-sharing between AdTech platforms. We outline some possible solutions to this below.

Origin-Only Referrer for Domains Without User Interaction

This new feature in ITP 2.0 strips down the referring URLs domain, which is the URL the user is currently on, when passed to third-party trackers — e.g. when a user visits a website site containing third-party trackers (e.g. ads), the referrer information is passed to these third parties.

Here’s an example of what this looks like:

Before ITP 2.0 = https://ecommercestore.com/clothes/mens/business/shoes

After ITP 2.0 = https://ecommercestore.com/

Third-party trackers now have less information about the user than they did before, but this change does not limit data that can be passed in the URL to an advertiser’s site if the user were to click on their ad.

Possible Solutions and Workarounds for ITP 2.0

While ITP 2.0 spelled bad news for a majority of independent AdTech and MarTech companies, there are a couple of things vendors can do to limit its negative effects. The main solution is to use server-to-server conversion and event tracking.

In order to navigate ITP, Facebook and Google have come up with some solutions — Google have released a site-wide tag to help advertisers continue to measure conversions, and Facebook have released a first-party cookie option.

Intelligent Tracking Prevention (ITP) 2.1

On February 21, 2019, Apple released a blog post stating that a new version of Intelligent Tracking Prevention (2.1) would be available in the beta releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and Mojave.

ITP 2.1 makes it even harder for trackers to identify and follow users across the web when browsing the internet on Safari.

Below are the main changes to ITP in this latest version:

7-Day Expiration For Cookies Set Client Side

Cookies can be set in two ways: either via server HTTP responses (server-side) or via JavaScript’s Document.cookie API (client-side).

Cookies created via the JS Document.cookie API (even first-party cookies) will be set to expire in seven days, regardless of their existing expiry date. Cookies created via JavaScript will be able to access cookies created via the HTTP response, as long as they don’t contain an HttpOnly attribute.

This will greatly impact many MarTech tools, such as Google Analytics, whose cookies are set via the Google Analytics JavaScript library. Cookies set by GA in Safari will expire after seven days, unless the cookie is updated within seven days or a workaround is implemented (more on that below).

Storage Access API For All Types Of Cookie Access

In ITP 2.0, there was a possibility for cross-domain trackers to partition their cookies so they could still be used by websites without tracking the user. For example, social media login forms on websites would have had their cookies partitioned so they would still work, but just wouldn’t be able to track users or build profiles about them.

If that social media login form wanted to access its partitioned cookies to track the user, it would have had to use the Storage Access API and obtain consent from the user.

This has all changed with ITP 2.1; all domains identified as having tracking capabilities will need to use the Storage Access API to access any type of cookie. For example, if a user wants to log into a website using their Facebook account, they’ll first have to consent via the Storage Access API.

Removed support for Do Not Track (DNT)

Apple has also removed support for the Do Not Track (DNT) signal, citing that many websites (and software vendors) have chosen not to respect the DNT decision set by users and elected to track them anyway.

This decision will have little or no impact on privacy for Safari users, as ITP offers far more advanced privacy and anti-tracking measures than DNT ever did.

Verified Partitioned Cache

ITP 2.1 has also introduced something known as verified partitioned cache. Essentially, the team at WebKit noticed some trackers implemented workarounds for ITP, with one of them being partitioned-cache abuse.

In response, when a domain with tracking capabilities creates a partitioned-cache entry, it is flagged for verification. Then, if there’s a cache hit for this entry after seven days, it will be loaded again. If the new response and original cached response match, then it’s cleared. If it doesn’t, the original entry is discarded and a new verification process begins with the new entry.

Intelligent Tracking Prevention 2.2

On April 24, 2019, WebKit announced that a new version of Intelligent Tracking Prevention (ITP 2.2) would be released with the beta versions of iOS 12.3 and Safari on macOS Mojave 10.14.5.

The new release, which comes just 2 months after the release of ITP 2.1, takes aim at a specific type of tracking — cross-domain tracking with link decorating.

1-Day Expiration of Tracking Cookies Set Via Link Decoration

The main goal of ITP 2.2 is to restrict cross-site tracking via link decoration.

Link decoration is a technique used by AdTech (DSPs, SSPs, etc.) and MarTech (web analytics, attribution tools, etc.) platforms to attribute clicks, visits, and conversions (purchases, downloads, etc.) across different domains using first-party cookies.

Here’s an example of a decorated link:

https://www.example.com?utm_source=googleads&utm_medium=cpc&utm_campaign=summer-promotion

The information after ? is known as a string query, which is made up of parameters (e.g. medium=). Another form of link decoration uses fragment identifiers, which are introduced by a hash (#).

This link would help the publisher (example.com) identify which visits to their website came from this source, which in this case is a paid advertising campaign on Google Ads.

This is just one example of link decoration, and in this case, doesn’t identify or track the user who clicked on it.

However, other uses of link decoration focus on tracking users by passing a unique user ID in the URL. Here’s an example of what that could look like:

https://www.example.com?clickID=akl872

In this case, the user would have clicked on an ad or a link (e.g. an affiliate link) and then redirected to a example.com.

It’s important to note that in order for this clickID to be recorded by the ad platform, there would have to be some JavaScript tag on the destination website that would allow the ad platform to collect the ID and create a first-party cookie.

Then, when the user visits the same website again, the JS tag would be loaded and the first-party cookie would be recognized. This is how AdTech platforms, including Google and Facebook, are able to measure conversions.

This clickID could be used to identify and track users as they move from one website to another. And this is what ITP 2.2 is aiming to prevent.

Moving forward, all persistent cookies created via JavaScript’s document.cookie will be set to expire in 24 hours if the referring domain has been identified as having cross-site tracking capabilities and the URL contains a query string or fragment identifier

Here’s an example of what that looks like:

If the URL doesn’t contain a query string or fragment identifier and isn’t classified as having cross-site tracking capabilities, then any first-party cookies created by document.cookie as a result of this will expire in 7 days (as mentioned above in the ITP 2.1 section).

This will have little impact on publishers wanting to measure website visits and clicks from campaigns as this information is collected and recorded once when the user visits their page (more on that in the next section), but will severely impact conversion and multitouch attribution if the conversion takes place outside of the 24-hour window.

Intelligent Tracking Prevention 2.3

On September 23, 2019, WebKit released ITP 2.3.

The new release continues the cat-and-mouse game that Apple is playing with AdTech companies.

Crack Down on Tracking Via Link Decoration

One of the main features of ITP 2.2 was the limitation put on cookies that had been created by link decoration.

As mentioned above, if a web visitor accesses a web page containing a decorated link (e.g. https://www.example.com?utm_source=googleads&utm_medium=cpc&utm_campaign=summer-promotion), then any first-party cookies created (via JavaScript’s document.cookie) because of that visit will be set to expire in 24 hours, provided the referring URL has been classed as a tracking domain.

In response, some AdTech and MarTech companies created a workaround whereby they utilize the browser’s localStorage, instead of creating a first-party cookie.

What’s localStorage? This post does a good job of answering that question and other questions.

This allows AdTech and MarTech platforms to store data — the same types of data that cookies store, such as click IDs — without having to worry about that data expiring; localStorage data typically doesn’t have an expiry data.

However, ITP 2.3 now puts a 7-day limit on all non-cookie storage data, including localStorage.

The good news is that if a user interacts with the website within seven days, then the expiry date will be reset, allowing the data to remain in the browser’s local storage for another seven days.

Also, a 7-day expiry on this type of data is much better than the 1-day expiry that first-party cookies get from the same process — i.e. a first-party cookie created by a decorated link from a classified tracker created via document.cookie.

However, it’s impossible to rule out changes to this expiry date. Future ITP updates may put a 1-day expiry date on non-cookie storage that meet the above conditions.

Changes to document.referrer

ITP 2.3 also introduced some changes to document.referrer.

Previously, some websites and platforms would decorate their own URL, instead of the URL’s destination pages. This allowed them to read the tracking ID via document.referrer on the destination page.

Here’s an example of a referrer provided by WebKit:

https://sub.social.example/some/path/?clickID=0123456789

Now, when a website makes a request to retrieve the clickID from the URL via document.referrer, only the top-level domain information will be passed — i.e. social.example.

The release of ITP 2.3. also includes:

• Changes to the Storage Access API.
• An ITP debug mode for macOS Catalina.
• Recommendations to use HttpOnly cookies for security (but can’t be read via JavaScript).

ITP 2.3 is available on Safari on iOS 13, the iPadOS beta, and Safari 13 on macOS for Catalina, Mojave, and High Sierra.