Apple's Intelligent Tracking Prevention, A Dangerous Game Of Cat And Mouse

Apple Safari's further restrictions on cross-site tracking in ITP 2.2 and 2.3 won't stop advertisers for long, but might just have the end result that Apple are looking for 

Apple are coming hard and fast with updates for their Intelligent Tracking Prevention - a feature built into their Safari browser that aims to restrict cross-site user tracking. The reason they're coming fast is that with each new release, new workarounds are developed to circumvent these restrictions.

Take ITP 2.2 for instance. Apple's focus with this update was around link decoration, where a user is directed to a website with some query string parameter appended to the URL for tracking purposes. If (some entirely hypothetical) SocialMediaSite identifies you as user ID XXX123, then by appending a link on their platform with...

https://www.example.org/?trackingID=XXX123

... this means on clicking through to example.org, any SocialMediaSite JavaScript running on the site (via share buttons, advertiser analytics etc) can store your user ID as a persistent cookie. SocialMediaSite can then tie your activity on that site to your individual user profile - any time now or in the future where you visit example.org.

ITP 2.2 tried to restrict this behaviour by introducing the following (from https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/)

Tracking Via Link Decoration Caps Client-Side Cookies to 1 Day of Storage

As of ITP 2.2, 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.

So in the example where you clicked through from SocialMediaSite to example.org with a trackingID query string parameter appended, any cookies set would expire after only one day. SocialMediaSite now can't tie your future activity on example.org to you as a person.

The quickly adopted workaround? Use another browser storage mechanism, such as localStorage. No restrictions on expiry time set there, so business as usual. And just to make sure, stop decorating the destination URL with the user ID - decorate an intermediate page instead. This can then be read from document.referrer on the destination page. Consider the following steps:

• From SocialMediaSite, you click a link that you think is to example.org
• SocialMediaSite instead sends you to
  SocialMediaSite.com/tracker?trackingID=XXX123&destinationPage=example.org
• You're redirected from here to example.org
• example.org loads (without any link decoration) but with a document.referrer that reads
  SocialMediaSite.com/tracker?trackingID=XXX123&destinationPage=example.org

As there's no link decoration on the destination page, the conditions of ITP 2.2 do not apply, so cookie storage is uncapped. The document.referrer value can then be read, and the user ID there is stored as before.

Clever, no? It's Apple's turn to hit back now though, with ITP 2.3 (from https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/)

Capped Lifetime For All Script-Writeable Website Data

Since ITP 2.2, several trackers have announced their move from first-party cookies to alternate first-party storage such as LocalStorage. ITP 2.3 counteracts this in the following way:

1. website.example will be marked for non-cookie website data deletion if the user is navigated from a domain classified with cross-site tracking capabilities to a final URL with a query string and/or a fragment identifier, such as website.example?clickID=0123456789

2. After seven days of Safari use without the user interacting with a webpage on website.example, all of website.example’s non-cookie website data is deleted.

This half of the update closes off the localStorage storage mechanism, if the conditions of ITP 2.2 are met. The second half though, goes further:

document.referrer Downgraded To eTLD+1

Our research has found that trackers, instead of decorating the link of the destination page, decorate their own referrer URL and read the tracking ID through document.referrer on the destination page.

ITP 2.3 counteracts this by downgrading document.referrer to the referrer’s eTLD+1 if the referrer has link decoration and the user was navigated from a classified domain. Say the user is navigated from social.example to website.example and the referrer is https://sub.social.example/some/path/?clickID=0123456789. When social.example’s script on website.example reads document.referrer to retrieve and store the click ID, ITP will make sure only https://social.example is returned.

So in our previous example of SocialMediaSite's intermediate tracking page - on the destination page example.org, document.referrer now only contains the eTLD+1 (Effective Top Level Domain +1), no query string parameters can be read. So once again the balance is restored, your activity is safe from tracking.

But wait...

There is a solution so obvious that it betrays Apple's actual intentions with ITP. Advertisers are forced to move from using link decoration in the referrer, to setting the values in the referrer's path. So instead of:

SocialMediaSite.com/tracker?trackingID=XXX123&destinationPage=example.org

Expect to see something like:

SocialMediaSite.com/tracker/trackingID/XXX123/destinationPage/example.org

No link decoration on either referrer or destination page, so ITP 2.2 and 2.3 do not apply.

Apple are giving advertisers just enough rope to hang themselves with. As part of ITP 2.4, they can then point to these examples as justification for further restrictions. And so their creeping disregard for web standards advances one more step, with their ultimate goal, in my opinion, being to push for a complete reform in how the web and tracking fundamentally works. 

Whilst this is an apparently well meaning end goal; their approach of gradually breaking standards and functionality until they're no longer fit for purpose on their platform seems a heavy handed misuse of Safari's position as the web's 2nd most popular browser.

Consider a website that uses localStorage as part of some legitimate functionality, such as on site personalisation. A user is referred to the website with link decoration, via a site that Apple decides is a 'classified domain' (using their own non-transparent definitions - another contentious point), and as such triggers ITP 2.3. Safari then breaks the standards for localStorage - purging any data that exists there in 7 days time. The website owner can no longer rely on the single accepted definition of localStorage, which is of no expiry time.

Consider also ExampleAffiliate.com, an affiliate website encouraging users to shop at ExampleShop.com. ExampleAffiliate is paid if the user makes a purchase on ExampleShop within 30 days of their initial clickthrough. This is tracked by storing a user ID cookie with a 30 day expiry on ExampleShop.com (when the user lands on www.ExampleShop.com?affiliateID=ExampleAffiliate from their initial referral from ExampleAffiliate.com), and then having some ExampleAffiliate JavaScript fire on the conversion page to pick this up.

Because the initial navigation likely breaches ITP 2.2 (referrer is a classified domain and a query string parameter exists on the destination site), ExampleAffiliate misses out on their payment when the user returns to ExampleShop.com the following week and completes a purchase - the expected 30 day cookie only lasted 1 day in Safari, so there is no visibility of the original referral. Again, behaviour not laid out in the accepted web standards (see the work done by the Internet Engineering Task Force (IETF) for more info on these)

Purely for my own morbid curiosity I'm looking forward to seeing what developments come next - from both advertisers and Apple. Is it sustainable for SocialMediaSite.com to implement individual domains per user - SocialMediaSiteTrackingDomainUserXXX123.com for their intermediate pages, when Apple invariably restrict the referrer to just the eTLD+1? Maybe not, but advertisers will continue to develop creative new workarounds to Apple's restrictions.

And Apple, on evidence, will continue working to their own standards, landing web developers back in the position they were in when having to deal with the dominant force that was Internet Explorer, and their approach to web standards.