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 11 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. 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 Safari 11.

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).

So far there have been three releases of ITP — 1.0, 1.1, and 2.0.

Before diving into the most recent release (2.0), let’s take a look at how the first two releases worked.

Intelligent Tracking Prevention (ITP) Versions 1.0 and 1.1

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

Scenario #1

In versions 1.0 and 1.1 of ITP, there was a featured 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 third-party trackers from then on.

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. It’s a different story for walled-garden advertising companies, such as Google, Facebook, and Amazon (more on this below).

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 (see below).

Scenario #2

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.

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

Scenario #3

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

In this case, the first-party cookie created by ads-r-us.com will be purged.

This is still the case with ITP 2.0, but is now controlled by 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.

On Safari, websites can no longer leave cookies in the user browser for later retargeting and attribution purposes. This will impact companies which access their first-party cookies in a third-party context, and as a result compromise reporting capability and accuracy. The lack of a cookie access window is somewhat connected with user prompts for Storage Access API detailed below.

Prompt For the Storage Access API

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

Sites like Facebook typically allow users to log in to their account on multiple websites to facilitate commenting or “liking” content on third-party sites. ITP 2.0 will now detect such cross-site tracking and partition its cookies, limiting its ability to be utilized in a third-party context.

Third-party embedded widgets like Facebook now have to request access to their first-party cookies when the user interacts with them on different websites by displaying a 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 a Facebook embedded widget, except on subdomains — e.g. 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 their embedded widgets, after 30 days, then their cookies will be purged.

Protection Against First Party Bounce Trackers

ITP 2.0 has 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 a social media website and then, instead taking the user straight to their destination, rapidly opens a series of bounce trackers.

Such tracker domains can store 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, i.e. purges them.

Protection Against Tracker Collusion

Protection Against Tracker Collusion identifies redirects utilized for tracking purposes only — i.e. for piggybacking and cookie syncing. 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 will stop 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 spells 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, with the main one being using 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) will 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 the Safari browser.

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 (i.e. server side) or via JavaScript’s Document.cookie API (i.e. client side).

Cookies created via the JS Document.cookie API (even first-party cookies) will be set to expire in 7 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 it doesn’t contain HttpOnly.

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 7 days, unless the cookie is recognized within 7 days or a workaround is implemented, like the ones suggested by Simon Ahava.

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 that they could still be used by websites without tracking the user — e.g. social media login forms on websites would have had their cookies partitioned so that 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, they 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 access. For example, if a user wants to log into a website using their Facebook account, then they’ll first have to consent via the Storage Access API.

Removed support for Do Not Track (DNT)

Apple have 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 gets flagged for verification. Then, if there’s a cache hit for this entry after 7 days, it will be loaded again. If the new response and original cached response match, then it’s cleared. If it doesn’t, then the original entry is discarded and a new verification process begins with the new entry.

Which Companies or Services Are Affected By Intelligent Tracking Prevention?

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

Therefore, the companies affected by ITP are ones that rely on cookies, especially third-party cookies, for running advertising and marketing services. This can range from retargeting ad vendors through to affiliate networks.

Which Companies or Services Are Not Affected By Intelligent Tracking Prevention?

While Intelligent Tracking Prevention affects most advertising and marketing vendors, there are some companies that were not initially affected too much by the first release of ITP, including:

Web Analytics and Other Marketing Software Relying On First-Party Cookies

With ITP versions 1.0 to 2.0, as long as the first-party cookie was used only in a first-party context, as is the case with Google Analytics or Piwik PRO Analytics Suite, then Intelligent Tracking Prevention didn’t block the software from setting cookies.

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, then 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 tools, unless they store the data in localstorage or implement a server-side setup.

Self-Hosted or White-Labeled Software

Most companies that use self-hosted software won’t be affected by this change as in most cases the software is hosted under a subdomain (e.g. software.example.com), meaning first-party cookies will still be created when a user visits their site.

Also, some cloud-based software can be configured so that the software points to the client’s subdomain. This practice is known as custom domain support or domain white labeling.

However, these tools will face the same challenges listed above as they’ll most likely be creating first-party cookies as well.

However, there are very few AdTech companies that provide on-premises versions of their software or domain white labelling, mainly because:

1. The user will be bound to a specific client, meaning they can’t track them across a whole customer base.
2. The cookie-syncing process would have to be carried out separately for each custom domain, making it an unscalable model as it would have to support hundreds or thousands of customers.

It’s important to note that this point applies to all popular platforms in the ecosystem, such as data-management platforms (DMPs) and other marketing software. Companies will have to make changes to how their marketing and advertising tools handle third-party cookies and record conversions. Alternatively, they can use tools that can be self-hosted and white-labeled.

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.

With the enforcement of the GDPR in May 2018 and with ePrivacy on the horizon, all companies operating in the digital advertising ecosystem will need to put more of a focus on protecting user privacy and complying with new privacy laws.

For the most part, this will involve making major policy changes and a lot of innovation.

Need help dealing with Intelligent Tracking Prevention and complying with the GDPR?

Schedule a call with one our AdTech and MarTech development teams and find out how our privacy-focused approach to software development can help your company.

Schedule a call or ping me on LinkedIn.