Google Calls Out Apple’s Intelligent Tracking Protection

Apple on Tuesday updated its Intelligent Tracking Protection (ITP) system in its WebKit browser engine because it could be tracked.

While ITP has been somewhat effective, making Safari users more opaque and less valuable in the behavioral ad targeting ecosystem than cookie-laden Chrome users, it still has gaps. Recently, Google security researchers found a way to use ITP for the very thing it was created to stop and passed their findings on to Apple, to the potential detriment of their future ad revenue.

The iPhone biz acknowledged the tip in a WebKit blog post on Tuesday, somewhat masked by a slew of security updates. The software updates to Apple’s various operating systems and browser address three WebKit vulnerabilities (CVE-2019-8835, CVE-2019-8844, and CVE-2019-8846) that permit malicious web content to execute arbitrary code, but these appear to be unrelated. While the blog post thanks Google for the responsible disclosure, it doesn’t go into details about the ITP issue identified.

The blog post, by WebKit security and privacy engineer John Wilander, says only that Google researchers provided Apple with a report that explores “both the ability to detect when web content is treated differently by tracking prevention and the bad things that are possible with such detection.”

Wilander said that the report led to several ITP changes and promised to credit Google’s researchers in future security release notes.

Though not specific about the Google disclosure, Wilander’s post explains that WebKit’s tracking prevention system could itself be used as a mechanism for tracking. Hence the title of the post, “Preventing Tracking Prevention Tracking.”

“Any kind of tracking prevention or content blocking that treats web content differently based on its origin or URL risks being abused itself for tracking purposes if the set of origins or URLs provide some uniqueness to the browser and webpages can detect the differing treatment,” Wilander explains.

That makes it sound as if ITP could function as a browser fingerprinting vector, conveying information that could be used to follow users around the web despite the ostensible tracking protection. To fix this, the WebKit team implemented three changes.

First, ITP now trims all cross-site Referer headers down to the page origin, omitting additional path information.

When a browser user clicks on a link, the browser generally adds an HTTP header labelled “Referer” (rather than the properly spelled “referrer”) that contains the URL of the originating web page in the request sent to the destination web page. When that link points to a different domain, that’s a cross-site request.

For example, clicking on a devclass.com link from a theregister.co.uk webpage would send a cross-site request header, the URL of the referring Register page, which would go in the Referer header field.

Henceforth, a Safari user on theregister.co.uk/example.html will send only theregister.co.uk and not the /example.html portion of the origin URL.

Second, ITP deny all third-party requests from seeing their cookies unless the associated first-party website has already established user interaction.

Finally, WebKit has revised the way it handles calls to document.hasStorageAccess(), an API put in place last year that allows embedded cross-site content to authenticate users (request access to first-party cookies) who are already logged in to first-party services while still limiting tracking. The API now weighs Safari’s cookie policy when invoked, so it may deny access in certain situations.

The Register asked Apple to provide more details about Google’s disclosure. You can imagine how that went. ®

Sponsored: How to get more from MicroStrategy by optimising your data stack

READ MORE HERE