Steven Englehardt

Finally, the attacker can use a bunch of dummy origins to encode a cross-site identifier within the ITP list (similar to HSTS supercookies). ITP doesn't classify origins loaded in documents open for less than 5 seconds, so attackers can read the encoded ID without destroying it.

An attacker can use this same approach to place a victim domain on the ITP list, potentially leading to denial of service. e.g., get a competitor's authentication origin classified by ITP, so its cookies are stripped and future login attempts fail.

As a practical example. Let's say the user visits dating.example, which embeds dating-cdn.example. An attacker can load dating-cdn.example on two attack sites. If they detect classification after the second visit, they learn that the user has visited dating.example.

Does this mean that only "prevalent" domains are vulnerable? No. The authors find that ITP consistently classifies domains as prevalent after they load on 3 sites. An attacker can load the non-prevalent domain across multiple sites and check its classification...

An attacker can use these side channels to determine whether specific hostnames are classified by ITP, thus implying that the user visits sites that embed those hosts. These hostnames can reveal incredibly sensitive information (e.g., phncdn[.]com, which is Pornhub's CDN).

Excellent paper by @arturjanc et al. on the risks of on-device tracker classification. Specifically, they discuss how Safari's ITP can be abused to leak browsing history, leak search history, and perform denial of service attacks: https://arxiv.org/ftp/arxiv/papers/2001/2001.07421.pdf … [thread]

...and that's the metric we should use to determine whether a browser is working to protect user privacy. If my browser locally infers my sexuality from my site visits and reveals that to advertisers, that's certainly not a browser working to protect me.

In some sense, this is an opportunity for a clean slate. We can decide what functionality to re-enable (e.g., cross-site logins). But what's left to be seen is how much of the new functionality added back in by browsers will be focused on re-enabling behavioral profiling...

I'm excited that Chrome has signaled a desire to block third-party cookies because it means all browsers will share the breakage cost of removing a very common tracking vector. A vector that's so intimately connected to things users care about that it's very difficult to block.

The profiling and targeting of users based on their browsing history is privacy invasive. Cookies are just a means to an end. Blocking cookies alone doesn't mean a browser is protecting privacy.

There are a lot of reasons to dislike cookies: 1. They aren't origin-bound like basically all other storage. 2. The only way to use them securely is to add prefixes and tokens. These are largely unused (https://tools.ietf.org/html/draft-west-http-state-tokens-00#page-4 …). But these don't make cookies privacy invasive...

Third-party cookies aren't inherently privacy invasive. It was a mistake to equate blocking cookies with protecting privacy. (I'm guilty of this myself) [thread]

@blassey @justinschuh Are you able to confirm what anti-fingerprinting work is in scope here?