Apple’s ITP 2.3: One More Cookie Workaround Enters the Battle

In a blog post on Monday 23rd, WebKit security and privacy engineer John Wilander explained that the primary motivation behind Intelligent Tracking Prevention (ITP) version 2.3 is to combat what WebKit considers to be the “continued abuse” of link decoration, aka adding code to a URL in order to create cookie-less identifiers.

Previously, ITP 2.2 cut the lifespan of persistent client-side cookies from seven days to 24 hours (if the three conditions listed below were met), and restricted cross-site tracking via link decoration:

1. The cookie is set via JavaScript (or in their words, “set through document.cookie”). This condition was applied also with ITP 2.1.
2. The site that sent the user to the landing page has been classified by ITP as “having cross-site tracking capabilities” (major ad networks, Google and Facebook are certainly classified this way)
3. The link uses link decoration (it uses query string parameters and/or a fragment identifier)

But WebKit engineers noticed that some trackers had responded by moving their first-party cookies to other forms of first-party website data storage to track users. They have added code to their own referrer URL to read the tracking ID on the destination page.

Under ITP 2.3, sites that do this will see all of their non-cookie website data deleted after seven days. Combined with the capped expiration of client-side cookies, this means trackers won’t be able to use link decoration combined with long-term first-party website data storage to track users.

Thus, ITP 2.3 relates to link decoration. Let’s refresh our brains on what is this.

Link Decoration: The What & How

There are two main ways to decorate a link.

1. The basic way is to statically attach extra information to the URL when a link is created. Here’s an example of a decorated link: https://www.example.com?utm_source=google&utm_medium=cpc&utm_campaign=2019_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 (#).
2. The other, more complex way to decorate a link is to run some Javascript code that is triggered when a person clicks on a link and dynamically adds information to a link.

Companies will do this when they want to pass information specific to the individual click that led someone to the destination site.

For example, an advertiser might do this to track a display ad campaign that is running across multiple publishers’ sites and links to the advertiser’s site. Instead of manually customizing the link for each publisher carrying its ad, the advertiser can have the code add “?publisher=[name of publisher]” to the URL at the time when a person clicks on the ad. This way the advertiser can determine which publisher was responsible for sending the site visitor.

As we have explained in an earlier blog post, link decoration does not have to do with Convert itself, rather with referring domains that have cross-site tracking capabilities AND use link decoration as explained above in the example.

It is clear then that Convert tracking and cookies are NOT affected by the new two steps under ITP 2.3 that WebKit team took to combat the above trackers.

Convert will Stay Respectful of Privacy & Security Updates

It’s great to see the WebKit team continuing to treat privacy violations with the same gravity as security vulnerabilities; the two go hand-in-hand.

At Convert, we also continue to keep a close eye on any privacy and security violations and the implications they have for our customers. You will find us speaking up about matters that concern the viability of tracking and also innovating as we go to offer the best possible alternative.