ITP: A Timeline of the Ongoing Struggle Between Marketers and Developers: Part 1

by Ricardo Cristofolini

Since 2017 something has been hunting Digital Marketers, Data Analysts, or anyone who relies on tracking data to make business decisions, and that something is called ITP – Intelligent Tracking Prevention. Although ITP has been updated almost constantly, it’s amazing to see how the marketers and developers kept adapting to each update – for better or for worse, unfortunately.

Reading through the updates since 2017, some really caught my attention, not for the update itself, but for how the market adapted to them. For example:

  • ITP would block third party cookies, and developers would update the system to put the third party cookies into the first party cookies jar.
  • Then developers decided to bounce a user through other websites to share user information before sending them to the final destination, ITP blocked that.
  • Trackers would also share information about users with other trackers – called trackers collusion. ITP was updated and that was blocked.
  • Looking for other options, developers decided to decorate the links with users’ information. Once again, ITP was updated and that too was blocked.

These are just a few examples of how adaptable trackers are behaving and if things keep moving this way, eventually a whole new digital marketing environment will be created.


Over the next few weeks, we’ll be coving the past, present, and future of ITP in this three-part article.

The Past – How did we get here?

June 5, 2017

It all started with WebKit (a browser engine developed by Apple) with the idea, from the very beginning, of blocking third-party cookies. Have you ever noticed advertisements following you around multiple websites and social media? Well, you can blame third-party cookies for that. At the time, ITP was updated to reduce cross-site tracking by further limiting cookies and other websites data. For example:

If you visit HockeyFans-history.com site to learn more about hockey history and then visit AmazingGameRules.com site to learn about the rules, if both of these sites load resources from a third party tracking site, SuperTracker.com, and SuperTracker.com has a cookie stored in the user’s browser, the owner of SuperTracker.com has the ability to know that users visited both the history and rules pages, what they did and other information. This is known as cross-site tracking.

All good there.

But, the cookie used by SuperTracker.com to store that information is called a third-party cookie, and it provides the information that allows companies to follow you around, based on the previous visits to both sites.

It didn’t end there.

New Year, New Updates

Feb 12, 2018

ITP kept evolving, and in Feb, 2018 it introduced a Storage Access API. Basically a way for embedded cross-site content to authenticate users who are already logged in to their first-party services. 

This update allowed authenticated embeds while continuing to protect customers’ privacy by default. The problem was, if a specific social website has an embedded comment system and “like” widgets (think Facebook or LinkedIn) on multiple websites to facilitate user engagement through a user’s social website ID, ITP would detect the multi-page embedded content from the social website, the ability to track the user cross-site, and therefore deny embedded content from that site access to its first-party cookies. In other words, only half of a cookie (pun intended) to you. This means, users could no longer use Facebook login credentials to like or comment on a newspaper site, for example.

Storage Access API

Mar 14, 2018

In March of the same year, an ITP 1.1 update was released and along with the Storage Access API, it included two new behavior changes: Partitioned cookies no longer persisted on disk, and Cookies blocked if they will be purged anyway. This means, all partitioned cookies (cookies that are not persistent and were used by third-parties to get first-party cookie access in order to communicate fundamental information) are treated as session cookies – temporary cookies that are deleted when you close your browser.

Previously, if a user interacted with a website in the last 30 days but not the last 24 hours, the site would partition, but keep, the cookies. The idea was to make sure users stay logged in even if they only visit a site occasionally, while restricting the use of cookies for cross-site tracking.

This update moved the partitioned cookie from the disk to the Storage Access API so now users can stay logged in, and ITP would consider that  third-party cookie, (Facebook, for example) as a white listed tracker.

ITP 2.0 – Major Update

June 4, 2018

ITP 2.0 was released. This was the first big update to the WebKit rules and included:

Removal of the 24 hours Cookie Access Window

This new version immediately partitioned cookies for domains determined to have tracking abilities, and the previous general cookie access window of 24 hours after user interaction was removed. To replace this, authenticated embeds could get access to their first-party cookies through the Storage API.

User Prompt for the Storage API Access

This update added a prompt to WebKit’s implementation of the Storage Access API.

Temporary Compatibility Fix: Automatic Storage Access for Popups

This was a short term solution for some federated logins that use popups and then rely on third-party cookie access once the user is back on the opener page. For some cases, the ITP rules stopped working, since domains with tracking abilities were permanently partitioned.

Protection Against First Party Bounce Trackers

ITP 2.0 was released with the ability to detect when a domain is solely used as a “First party bounce tracker”, meaning it was never used as a third party content provider but instead, tracks the user purely through navigational redirects.

Say a user is navigating on Facebook and clicks a news link (newyorktimes.com for example). Instead of navigating directly to the newyorktimes.com site, they are rapidly navigated through trackerOne.example and trackerTwo.example before reaching the final destination. When this navigation happens, those domains could store information about the user’s browsing history in the first party storage and cookies. No more with ITP 2.0 updates.

                Transfers information     Transfers information                   Finally arrive

Protection Against Tracker Collusion

If you thought the First Party Bounce Tracker was actually a “good” way around ITP, think again. Through WebKit research, it’s noticed that cross-site trackers help each other identify users. This is basically one tracker telling another tracker about you. WebKit calls that a tracker collusion, but the 2.0 update detects this behaviour through a collusion graph and classifies all involved parties as trackers.

Origin-Only Referrer for Domains Without User Interaction

Unfortunately, ITP’s purging of website data does not prevent trackers from receiving the so called referrer header that reveals the webpage the user is currently on. Well, in ITP 2.0, the referrer, if there is one, is downgraded to just the page origin for third party requests to domains classified as possible trackers by ITP.

Here’s an example of how that works: If a user visits https://store.example/sports/products/soccer-ball.html and the page loads a resource from trackerOne.example, the request to trackerOne.example would contain the full referrer, https://store.example/sports/products/soccer-ball.html, which can reveal a lot about the user to a third party. No more with ITP 2.0. The referrer was  reduced to just https://store.example/.

New Year, New Updates 

Feb 21, 2019

February, 2019, ITP 2.1 was released to further reduce a tracker’s ability to establish user identities across sites and to  fix previous problems:

A Single Set of Cookies Per Site

Now, partitioned cookies are no longer supported and third-parties classified with cross-site tracking capabilities have to use the Storage Access API to get any cookie access.

Client-Side Cookies Capped to 7 Days of Storage

All persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry. This was based on a number of reasons:

  • Cross-site trackers have started using first-party site’s own cookie jars.
  • Cookies available in document.cookie could be stolen by speculative execution attacks on memory and also by cross-site scripting attacks.
  • The proliferation of cookies slows down page and resource loads.
  • There is a size limit on outgoing cookie headers.

Verified Partitioned Cache

Partitioned cache means cache entries for third-party resources are double-keyed to their origin and the first-party. This prohibits cross-site trackers from using the cache to track users. Even so, WebKit noticed that trackers, in order to keep their practices alive under ITP, have resorted to partitioned cache abuse.

When a partitioned cache is created for a domain that’s classified by ITP, it gets flagged for verification. After seven days, if there’s a cache hit for a flagged entry, WebKit will act as if it has never seen this resource and load it again. The new response is then compared to the cached response and if they match in ways regarding privacy, the verification flag is cleared. However, if the new response does not match, the entry is discarded, and a new one is created with the verification flag set and the process starts all over.

In this version of ITP, verification is done by WebKit for permanent redirects as this is where abuse of usage was noticed.

For example:

Before

After

Remove Compatibility Fix for Popups

In the previous release, a short term solution for the Popup when a user logins in with a third party site was causing ITP to not work as it should. In this version, the compatibility was removed before the user interaction was received, i.e. dismissed before a tap, click, or text entry.

Removed Support For the DNT (“Do Not Track”) Signal

With the introduction of ITP 2.1, the removal of support for the DNT signal was an attempt by web stakeholders to offer users an off-by-default way to ask servers not to track them. Unfortunately, since 2011, the vast majority of websites had not changed their behavior in response to DNT signal for the users who elected to turn it on. Instead, online tracking and tracking techniques have become more pervasive and sophisticated in spite of the DNT project.

Unfortunately, the DNT project ended without the publication of a standard, in part “because there has not been sufficient deployment of these extensions (as defined) to justify further advancement.”

Don’t Stop Me Now – New Updates

Apr 24, 2019

If you were expecting a break from ITP updates, think again. 2 months later, ITP 2.2 was released.

This new update focused on tracking via link decoration. Meaning, persistent cookies set through document.cookie are capped to one day of storage when both of the following conditions are met:

  1. A domain classified with cross-site tracking capabilities was responsible for navigating the user to the current webpage.
  2. The final URL of the navigation mentioned above has a query string and/or a fragment identifier.

Basically, cross-site tracking via link decoration is a way trackers found to follow users through URL query strings for cross-site tracking purposes.

In the example above, the social network website social.example is adding a “click ID” as a query parameter to every outgoing link. Each of these click IDs is connected to the real user ID “Jane Doe” in social.example’s database. Therefore, you have a stalker.

This shows how click IDs can effectively work like user ID’s for cross-site tracking.

When tracking information is added to links, it can be used to connect people and devices when the links are shared. Jane Doe in the example above may want to share the news.example link with a coworker. Through link decoration, her social.example user ID is now copied into her coworker’s web browser and can be used to connect her with her coworker on social.example’s platform.

However, WebKit didn’t only release a new update based on new tracker features. There are other consequences relating to privacy when dealing with link decoration

First, user IDs are transferred when users share links, so sharing a news page from Facebook, for example, will also make available your user ID, and that can be used to connect you with the person you shared the link with. Now, if that person shared it with five other people, your user ID will be all over the place.

Second, some websites fail to load when they receive unknown query parameters. You probably have been in this situation where you received a URL from a friend, but the link refused to open. You try again, and it’s still not working. Well, your clickID (which based on this scenario is working as your userID) is a query parameter in an URL and some sites (when shared) fail to open the link.

What about Ad click Attribution for the Web? – New Updates

May 22, 2019

When a user clicks an ad in a specific website, the destination site, by default, can access where you’re coming from and based on that, show you ads about their product in the original site. If you’re on Facebook and see an ad for sports gear at sports.example.com and click it, sports.example.com would know you came from Facebook and use that information to retarget ads. In other words, you will probably be seeing more ads from sports.example.com on Facebook. Not only that, but Facebook would know you purchased something on sports.example.com and will also start showing you other ads about sport gears.

For WebKit, online ads and measurement of their effectiveness do not require Site A, where you clicked an ad, to learn you purchased something on Site B. Pretty much the only data they need to know is that someone who clicked an ad on Site A made a purchase on Site B.

In order to balance this situation, WebKit presented a new technology that allowed attribution of ad clicks on the web while preserving user privacy:

  • Users should not be uniquely identified across websites for the purposes of ad click attribution.
  • Only websites that users visit should be involved in measuring ad clicks and conversions.
  • The browser should act on behalf of the user and do its best to preserve privacy while reporting on ad click attribution.
  • The browser vendor should not learn about the user’s ad clicks or conversions.

There’s a whole explanation on the WebKit site on how ad clicks work, privacy-invasive situations, how to preserve ad clicks, steps, and more if you’re interested.

This can also be found in Safari Technology Preview 82+.

WebKit Tracking Prevention Policy Announced

Aug 14, 2019

On this day, WebKit provided the world with a Tracking Prevention Policy covering:

  • What types of tracking WebKit will prevent.
  • When other tracking countermeasures come into play such as limiting capabilities and informed user consent.
  • How WebKit handles unintended impact of their tracking prevention.

All based on Mozilla anti-tracking policy, if you’re interested in knowing where WebKit documentation came from.

ITP 2.3 – Another Good Chunk of Updates

Sep 23, 2019

Only five months had passed since the ITP 2.2 release, but WebKit was already busy with more good updates. This time, enhanced prevention of tracking via link decoration, Updates on the Storage Access API, ITP Debug Mode in Safari on macOS Catalina and a note on HttpOnly Cookies.

Link Decoration

In the previous update, when a web page is navigated from a domain classified by ITP, and the landing URL has a query string or fragment, the expiry of persistent client-side cookies created on that page was 24 hours.

Well, we all know how things work on the web. If there’s an opportunity, a lot of people will abuse it, and that’s what was happening with the link decoration, so ITP 2.3 took the following steps:

  1. Capped lifetime for all scripts-writeable website data: No more usage of first-party cookie jar by the third party ones.
  2. Document.referrer downgraded to eTLD+1 (Effective Top Level Domain + 1): No more decoration of the referrer URL and reading that information on the destination page.

Updates to the Storage Access API

Based on developers request, WebKit provided:

  • Only consume the user gesture (tap or click) when the user explicitly denies access: No more gesture consumed when the promise was rejected without a user prompt.
  • Make document.hasStorageAccess() return true when ITP is off: That was causing confusion on developers because, even when ITP was off, the hasStorageAccess() was returning false.

User Enhancement Request

Requested by the users, WebKit was asked to cap the number of times they can be asked for storage access by a specific piece of embedded web content. Some services are requesting storage access on every click or tap, regardless of previous interactions with the user. To counter such repeated prompting, WebKit’s implementation of the Storage Access API was automatically rejecting the request for storage access for documents where the user has picked “Don’t allow” in the prompt twice.

ITP Debug Mode in Safari on macOS Catalina

With ITP Debug Mode enabled, you will see ITP messages in the log as you browse the web. Whenever ITP decides to schedule deletion of website data it will indicate in the log “all data” or “all but cookies” to tell you whether it’s a regular deletion of all website data or new capped lifetime of all non-cookie website data.

HttpOnly Cookies

This is more of an explanation regarding the term HttpOnly cookie, sometimes mistakenly shortened to just “HTTP cookie”. Some say any cookie set by a server is an HttpOnly cookie. Based on WebKit, this is incorrect. The server needs to add the HttpOnly attribute in the Set-Cookie response header to make a cookie be HttpOnly.

Christmas Present Updates

Dec 10, 2019

This time, updates were more related to the most recent versions of Safari on iOS, iPadOS and macOS. That said, there were some other interesting updates included that I will get to in a moment.  It’s important to mention at this time that Google was helping WebKit to improve users privacy and provided reports where they explored both the ability to detect when web content is treated differently by tracking prevention and the bad things possible with such detection.

This shows that the ITP updates since 2017 were starting to be noticed by the big players on the web and, if Google decided to help (at least it’s the first time Google was mentioned as a supporter), it’s definitely something we can’t ignore –  at least not anymore.

Anyway, these updates focused on Tracking Prevention as a Tracking Vector. That means any kind of tracking prevention or content blocking that treats web content differently based on its origin or URL, risk being abused for tracking purposes if the set of origins or URLs provide some uniqueness to the browser, and web pages can detect the differing treatment. In other words, modification on the page because a user blocked some ads can be used to track users (nice, isn’t it?!). In order to make that harder, WebKit devised three ITP enhancements:

  • Origin-only Referrer For All Third-Party Requests: Requests from https://images.example that would previously contain the referrer header “https://store.example/baby/stroller/deluxe-stroller-blue.html” will now be reduced to just “https://store.example”.
  • All Third-Party Cookies Blocked on Websites Without Prior User Interaction: Regardless of the classification status of the third-party domain, ITP will block, unless the first-party website has already received user interaction.
  • Storage Access API Takes the Underlying Cookie Policy Into Consideration: Previously, document.hasStorageAccess() was returning false if ITP was activated. This update had two new rules for that to happen.
  • Absence of Cookies In Third-Party Requests Does Not Reveal ITP Status: This was presented because users were asking if an attacker could reveal the ITP status for a domain outside their control by making a third-party request to the domain and checking for side effect of whether cookies were sent or not? It’s a valid question, and the absence of cookies in a third-party request can be due to ITP blocking existing cookies or the default cookie policy blocking cookies because the user never visited the website, its cookies expired, or because the user or ITP has explicitly deleted the website’s cookies.

Conclusion

ITP came a long way to provide rules to support users towards a smooth experience online. Although, I can’t help but think that in one way, these rules are based on the abuse of the internet by digital advertisements. Looking at the history of ITP until now, it’s clear that where a user was seeing one or two ads, now they are seeing 10, 15 and, not only that, these ads kept following them because the advertisers had way more information instead of just knowing what they are doing in order to provide custom made publicity.

It’s like driving on a highway and you see a billboard and, after 5km, you see another one. Now, picture this scenario where every 100m you see a billboard and every third one is the same as the first one you saw. Even worse, all that visual is now “following” you showing on your car screen, playing on your radio or on your phone, “custom-made” to you with information you didn’t know you provided while you were driving.

Yes, that personalization drives more conversions and sales, but for users it’s extremely annoying. Not only is that annoyance being noticed, it’s driving browsers to listen and come up with ways to try and stop it.

If you find this topic interesting, keep an eye out for Parts 2 and 3 in the coming weeks.

Ricardo Cristofolini

Implementation Specialist

I’m passionate about what I do. If you meet my manager or co-workers, they would say I’m a team player, engaged and always excited to learn something new. Like everyone else I have some flaws. However I’m not afraid to work around those to bring the best in myself and for the company.

See more posts from Ricardo