This is the subhead for the blog post
Since 2017, WebKit, the browser engine that powers Apple’s Safari browser, has been diligently earning the enmity of digital marketers via the employment of a technology called Intelligent Tracking Prevention.
An attempt to prevent cross-site tracking, Intelligent Tracking Prevention (ITP) has grown from a vague cause for concern to an existential threat for firms that track user movements throughout the web.
In February of 2019, WebKit announced that all subsequent versions of Mac operating systems would ship with an updated version of ITP — ITP 2.1. This update significantly tightens ITP’s tracking restrictions and changes the playing field for anyone who works in marketing or analytics.
Digging into the history of ITP can help us understand this latest iteration of the technology, and how to counteract its effects. We’ll talk about when and how ITP started and how it works, and we’ll compare 2.1 to its predecessor, 2.0. (In tomorrow’s blog post, we’ll explain what advertisers can do about it; stay tuned.)
A brief history of ITP
WebKit first introduced ITP in 2017. In its blog post explaining the technology, WebKit claimed that:
The success of the web as a platform relies on user trust. Many users feel that trust is broken when they are being tracked and privacy-sensitive data about their web activity is acquired for purposes that they never agreed to.
Pundits also suggested that WebKit, employed primarily to power Apple’s Safari browser, might be making a concerted effort to act as a fly in the ointment of both of Apple’s principle competitors — Google and Facebook. Both Google and Facebook rely on advertising as their primary source of revenue, and thus they benefit from building user profiles via cross-site tracking. ITP directly threatens this line of business.
Whether altruistic or otherwise, WebKit’s commitment to combating tracking has proven very real indeed. After introducing ITP 1.0 in 2017, WebKit moved rapidly, further restricting web protocols that could be used for tracking with the introduction of ITP 2.0 in June of 2018. It enhanced these restrictions with ITP 2.1 in February of 2019.
ITP has shipped automatically with every version of macOS since Mojave in June 2018. With 31% of US internet users relying on Safari as their primary browser, and ITP-like restrictions likely to come soon to Firefox and other browsers, the technology has the potential to transform the digital marketing industry.
How does ITP work?
ITP uses machine learning to figure out which domains are likely to have cross-site tracking abilities, then restricts those domains’ ability to place and access cookies.
Understanding ITP demands at least a cursory understandings of browser cookies. Every webpage has a small amount of storage that developers can use to persist data between browser sessions. This “cookie jar” can hold text strings, which are used for everything from determining the last time a user visited a site, to keeping track of user preferences, to keeping track of items placed in a user’s cart.
For our purposes, there are two types of browser cookies that we’re interested in: first-party and third-party.
First-party cookies are cookies placed on a website by the website itself. Say I’m on example.com and a script from example.com places a cookie on the example.com domain — this is a first-party cookie.
However, say example.com calls a script from facebook.com and that that script places its own cookie. While I’m on example.com (when example.com is the window to which I’ve navigated in the browser) that facebook.com cookie is a third-party cookie.
First-party cookies are set by the domain that the web user is visiting; third-party cookies are set by a different domain — simple as that.
Cookies, especially third-party cookies, are essential to cross-site tracking. Prior to ITP, they worked more-or-less like this:
The lawnmower example
Say you’re shopping for a new lawnmower on quality-lawnmowers.com. Quality-lawnmowers.com lets users “like” certain of their products, and in order to do this loads a “like” button from social.com. When it loads this button, social.com executes a script that drops a social.com cookie (third-party, in this context) onto the user’s browser. This cookie contains a unique identifier that can be traced back to the profile social.com has collected about your behaviors and preferences.
Then, after you’re done shopping for your lawnmower, let’s say you navigate to lawn-furniture.com. Lawn-furniture.com has a commenting system that validates users through social.com. As it loads the scripts for this commenting system, social.com checks the third-party cookie that it originally dropped when you navigated to quality-lawnmowers.com. If it finds that cookie, Social.com can then match your subsequent browsing to your original visit to quality-lawnmowers.com. This helps them build out a profile of your behavior. If social.com can say for certain that you visited both sites, then it can compare how long you spent on each site, which browser you used to navigate there, what things you clicked while on each site, and many other types of information. It then uses this information to target ads.
ITP seeks to prevent this sort of cross-site tracking.
The first thing ITP does is use a machine learning model to figure out whether a domain is trying to track users. This model takes a number of factors into account — user clicks, redirects, number of resources requested — and makes a decision about whether or not a domain is trying to track people.
If the machine learning model (which, to WebKit’s credit, appears to be pretty accurate) decides that a domain is trying to track users across sites, it places several restrictions on that domain’s ability to manipulate browser cookies.
In ITP 1.0, WebKit restricted a potential tracker’s third-party cookies to a 24-hour window. It then purged the tracking domain’s cookies (first and third-party) after 30 days with no direct user interactions with the top-level domain.
An example of ITP at work
Say you visited social.com and it placed a cookie on your browser. This cookie would be available to social.com in a third-party context — if, for instance, you were visiting news.com — for 24 hours. After that, social.com’s cookies would only be accessible to it if you were actually visiting social.com. And if you didn’t visit social.com for 30 days, Safari would go through and delete all of social.com’s cookies.
This restricted approach was intended to preserve some features that users enjoy, such as remaining logged in to websites they frequent, while also thwarting attempts at the kind of tracking described above.
However, WebKit decided that trackers were finding ways to abuse the system nevertheless, so they tightened these restrictions with ITP 2.0.
Released in tandem with macOS Mojave, ITP 2.0 foisted further restrictions on domains that were determined to have tracking abilities. In this update, WebKit did away with the 24-hour grace period entirely. Instead, WebKit began partitioning cookies from tracker-related domains into a special bucket (you can think of it as a locked cookie jar), which could only be accessed through something called the Storage Access API, which WebKit introduced in ITP 2.0 as an olive branch to developers. This API allows third-parties to access their cookies, but only as the result of a user interaction, and only if the user explicitly allows the third party such access.
So, let’s say video.com has placed a cookie on a user’s browser that records whether or not the user is logged into the video.com service. If a user clicks a button that plays a video from video.com, Safari will then prompt the user and ask if he or she wants to allow video.com access to its cookies. If the user approves, then video.com will be able to use the Storage Access API to gain limited access to its third-party cookies.
Federated login systems, which allow you to use one login for multiple sites, rely heavily on third-party cookies. Safari has requested that these technologies use the Storage Access API, rather than relying on traditional browser cookies.
With ITP 2.0, WebKit also increased the scope of its tracker-blocking activities. This iteration began blocking “bounce trackers,” which use redirects to place cookies on a user’s browser as they navigate between sites. ITP 2.0 also goes after “tracker collusion,” which WebKit defines as trackers sharing information between each other to help establish a user’s identity.
Got all that? Good. Because things get even more restrictive with ITP 2.1.
WebKit’s decision to aggressively engineer for user privacy appeared to pay off in 2018, as tech behemoths were raked over the coals for a variety of misdeeds. In response, WebKit and Apple have doubled down on their privacy commitments.
No third-party cookies
The latest (as of this writing) iteration of ITP, ITP 2.1 further increases the restrictions initiated in ITP 2.0. Gone are the partitioned cookies. Now, the only way for third parties to set or access their cookies on Safari will be through the Storage Access API. This means any third-party cookie access on Safari will require express user consent.
Time limits on first-party cookies
More significantly, ITP 2.1 place restrictions on sites’ first-party cookies as well.
After the introduction of ITP 2.0 several advertisers, most notably Facebook, stopped using third-party cookies in favor of first-party cookies.
Rather than facebook.com using a third-party cookie to track your activities on news.com, facebook.com’s marketing scripts now write a cookie directly to news.com’s own cookie jar and use this value to match interactions to specific users. As WebKit pointed out, this also allows different marketing scripts to piggyback off each other’s tracking cookies. If you know what facebook.com calls its user identification cookie, then you can look for that cookie across different domains and use it to build your own user profiles (which is likely why Facebook avoided using first-party cookies in the first place).
WebKit has attacked this practice with a sledgehammer.
As of ITP 2.1, all cookie storage in Safari, both first- and third-party, will be limited to seven days. This is a huge change. A cookie’s lifetime has typically been left to developer discretion, with some having expiration dates set years in the future. ITP 2.1 severely restricts developers’ ability to persist information within an application.
IPT 2.1 Effects for marketers
ITP 2.1 stands to severely limit analytics insights, touchpoint mapping, and conversion tracking for users who visit websites via Safari.
Because of ITP 2.1’s aggressive approach to cookies, it makes it very difficult to match multiple user actions to the same person across browsing sessions. This threatens to hamper Google Analytics’ ability to determine unique page views, Google Ads’ ability to track conversions across windows of greater than seven days, and all MTA platforms’ abilities to attribute multiple touchpoints to the same user.
Discouraged? You’re not alone. Check back tomorrow for a post explaining ways advertisers can deal with the new restrictions.