Google finds privacy holes in Safari’s ITP anti-tracking system

Far from protecting the security and privacy of Safari users as advertised, Apple’s much-vaunted Intelligent Tracking Prevention (ITP) could leave them exposed to a raft of privacy issues, including – ironically – being tracked.

That’s the surprising conclusion of a group of Google researchers who this week published a short but sharp proof-of-concept analysis of the flaws they found in ITP, some of which were recently fixed while others, they suggest, present more fundamental problems.

Based on machine learning, ITP was added to Safari in 2017, since when it has been revised several times up to the current WebKit implementation, version 2.3, released in September 2019.

Unexpectedly, in December, Apple published a blog thanking Google for suggesting some changes to ITP which they’d implemented in Safari as part of December’s iOS 13.3, and Safari for macOS 13.0.4 updates.

That offered Apple’s explanation of the changes – this week it was Google’s turn and it makes for interesting reading.

Users are prey

True to its name, one of the things ITP is supposed to do is to limit the amount of information users share with cross-site cookies (cookies set by a site that isn’t the one they’re visiting). Tracking and advertising systems typically use cross-site cookies to track and profile individuals as they move from website to website, noting what sites they visit and what they do there.

ITP tries to classify sites by watching how users interact with them, as a way of allowing some sites to track people for legitimate purposes (intentionally clicking on an ad or logging into sites using Facebook, say).

It does this by counting what Google calls ITP ‘strikes’. Each time a cross-site request is made the domain the request is sent to acquires a strike. Once a domain has accumulated enough strikes it is classed as a ‘prevalent’ domain. Prevalent domains are subject to restrictions – cookies may be removed and Referer headers shortened – to ensure the user remains anonymous. Unfortunately:

Any site can issue cross-site requests, increasing the number of ITP strikes for an arbitrary domain and forcing it to be added to the user’s ITP list.

And that, it turns out, allows sites to interrogate a browser’s ITP list.

By checking for the side effects of ITP triggering for a given cross-site HTTP request, a website can determine whether its domain is present on the user’s ITP list; it can repeat this process and reveal ITP state for any domain.

In other words, ITP creates a “global state” for a user’s browsing history, accessible to any website a user visits. Sneaky websites can attempt to access this global state to work out if a given domain is on on the list, what websites a user has visited. Most alarmingly, the unique state of a user’s ITP database might even be used against them as a “fingerprint” useful for cross-site tracking (using a similar technique to HSTS fingerprinting).

Safari’s December updates closed most of the issues in ITP but the fact that a bunch of researchers were able to punch holes in it underlines how even the most sophisticated anti-tracking system can come unstuck.

On the other hand, some of the attack scenarios suggested by Google would have required websites to invest a fair amount of effort into defeating it. There is also no evidence that any did. If you’ve been using Safari recently, it’s unlikely your privacy was compromised by the techniques Google discusses.

However, Google believes that even after Apple’s fixes, the fundamental problem of targeting the ITP list and fingerprinting will be difficult to stop.

Apple has been here before – support for the old ‘do not track’ feature was removed last summer after it was discovered it was being used as just another fingerprint variable.

Apple will persevere with ITP, of course. All browsers need to have some answer to the privacy issue, however imperfect.

But what’s clear is that it’s taken a bigger risk with ITP than seemed evident when it launched it nearly three years ago. Creating a filter built on machine learning sounded logical but it’s that very design feature that potentially allows it to be gamed when attackers – advertisers – work out how it works and what it prioritises.

Latest Naked Security podcast