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.