In a nutshell, Safari bases its anti-tracking approach not on a built-in, static list of domains, but on making a local decision about the sites that your browser recognizes as providers of third-party resources. [2/9]

The first problem is that this requires building up a custom model of what sites are loaded in third-party contexts, which depends on your individual traffic and implicitly encodes information about your browsing history. [3/9]

The second problem is that when the browser uses this model to change its behavior (e.g removes cookies or the `Referer' header from some requests), its underlying data gets exposed to any website (How, you ask? -> Section 1.2.1) [4/9]

What you end up with is a personalized anti-tracking model baked into your browser. That model is not only a unique identifier, but also reveals information about sites you visited since last clearing browsing state. That's not great. [5/9]

As far as mitigations go, there are definitely useful things the browser can do to address such leaks (and Safari has done them: webkit.org/blog/9661/prev…). But completely fixing this is hard. [6/9]

There is an important and somewhat unexpected lesson in all of this. It's that if you alter browser behavior based on locally gathered data, then if your changes have web-observable consequences, you're going to have a bad time. [7/9]

This is a concern not just for Safari and ITP, but for all other anti-tracking proposals. For example, Chrome's Privacy Budget idea will have to grapple with the same kinds of issues as it develops. [8/9]

One last thing: it's clear that Apple is trying to do the right thing and the WebKit folks we've interacted with care deeply about privacy. We hope that these results will help Safari & guide other browser vendors in the long run. [fin]

In terms of technical details, twitter.com/s_englehardt/s… has a good summary.

Congrats everyone, really nice work.