What Is Intelligent Tracking Prevention and How Does It Work? [versions 1.0 - 2.1]

AdTech Industry, Data & Privacy

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

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.

How a first-party cookie is created by an ad retargeting service

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 four releases of ITP — 1.0, 1.1, 2.0, and 2.1.

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:

Intelligent Tracking Prevention after 24 hours of clicking on an ad

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.

Intelligent Tracking Prevention 30 days after clicking on an 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.

Intelligent Tracking Prevention 30 days after clicking on an 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.

AdTech companies implemented a workaround for Intelligent Tracking Prevention (ITP)
Query string parameter - a possible workaround for ITP

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:

consent box

Here’s an example of what this would look like:


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.

Protection against tracker collusion stops cookies from being dropped or read on a user's browser during redirects
Tracker Collusion. Adapted from the original source: webkit.org

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.

How Does ITP Impact AdTech Companies?

The Intelligent Tracking Prevention feature is just another example of a privacy update that threatens the very thing upon which online advertising depends – cookies.

AdTech companies won’t be able to run targeted and retargeted ad campaigns on Safari browsers due to the cookie restrictions caused by ITP.

Possible ITP Workarounds and Solutions for AdTech Companies

Although most online ad campaigns will be restricted, click-through attribution for some types of campaigns should still be possible.

This can be achieved by passing a unique click ID in the URL to the destination website. From there, the destination site can use a JavaScript tag to capture and store the ID, notifying the ad server about the conversion from the given click ID.

Second-party data (or data co-operative) partnerships could also implement a workaround to ITP by syncing identifiers between sites. Exchanging identifiers between sites – for example, between partner sites or domains owned by the same company – is made possible by passing the IDs via URLs and then storing the IDs in a first-party cookie on the server (i.e. server-side).

This workaround can provide limited remarketing between partners and even promote further expansion of data co-operatives.

How Does ITP Impact Analytics and MarTech Companies?

ITP versions 1.0–2.0 had little or no impact on most analytics or MarTech platforms as long as the first-party cookie was used only in a first-party context, as is the case with tools like Google Analytics and Piwik PRO Analytics Suite.

The reason for this was because these platforms set a cookie (via JavaScript) under the domain of the website the user is currently visiting, and typically don’t track users across the internet.

For example, if the Piwik PRO tag were installed on the www.example.com website, then it would set the cookie under the www.example.com domain. This cookie isn’t used in a third-party context because the software is used only within the www.example.com domain.

Now if Piwik PRO were used to analyze a different site – e.g. www.usedcarsite.com – it would have a separate cookie set in the www.usedcarsite.com domain along with a separate site ID in the database.

However, ITP 2.1 will now delete first-party cookies set by web analytics and other MarTech tools after seven days, unless they implement a workaround.

Possible Workarounds for Analytics and MarTech Companies

As ITP 2.1 now includes a seven-day expiry for first-party cookies created via JavaScript’s Document.cookie, which is created in the browser (i.e. client-side), web analytics and MarTech vendors wanting to maintain accurate data will need to implement a workaround.

Simon Ahava lists a number of ITP 2.1 workarounds for analytics tools in his blog post, including setting first-party cookies server-side via the HTTP response, storing the first-party cookies in localstorage and creating a reverse proxy server.

If web analytics and MarTech tools don’t implement a workaround, then metrics and reports from users on Safari browsers will be inaccurate if their last visit was more than seven days ago.

Walled-Garden Advertising Ecosystems

While companies like Facebook and Amazon weren’t affected too much by ITP 1.0 and 1.1, the introduction of ITP 2.0 and 2.1 has changed this.

As mentioned above with the Facebook-widget example, Google, Facebook and Amazon will now have to get approval from users to drop cookies and access website data via the Storage Access prompt.

Final Thoughts

Major advertising groups have criticized Apple for releasing Intelligent Tracking Prevention as they feel it will threaten the economic model of the Internet, even though Safari browsers only account for about 14% of total browser usage across all devices, but the feature’s introduction is just one of many changes the online advertising industry will have to adjust to.

In addition to the GDPR’s rules regarding obtaining consent from users to drop a cookie on their browser, and the steady adoption of ad-blocking software, it seems likely that Firefox will follow in Apple’s footsteps and implement something similar to ITP, and there’s a cloud of uncertainty about what Chrome plans to do in this space.

However, one thing is clear: the use of cookies as a way to identify and track users on web browsers is becoming less reliable with every passing year.

Ask us anything about data privacy

Send us your questions

FREE AdTech & MarTech Resources

Thousands of C-level executives, software engineers, marketers, and advertisers all learn about the inner workings of AdTech and MarTech with our bimonthly newsletter — and so can you! Subscribe today and get access to the latest and best articles, videos, and guides!