Preventing Pool-Party Attacks

More generously, I'd say they were giving the matter a more accessible name to raise consciousness about it and because they intend to do significant future work addressing it. There is a marketing angle to this: they might then claim to be the most private browser on this basis. However, given they are cooperating with other browser dev teams on this, if the danger of bypassing anti-fingerprinting measures is as serious as they say, this seems quite legitimate.

“Pool-party” attacks work by manipulating pools of browser resources which are limited (i.e., the browser restricts how many of the resource websites can open or consume) and unpartitioned (i.e., different contexts consume resources from the same pool). While the examples focused on in this work utilize limited-but-unpartitioned pools of network connections, browsers include many other limited-but-unpartitioned resource pools that could be similarly exploited, such as pools of file handles, subprocesses, or other resource handles.

A “pool-party” attack occurs when parties operating in distinct contexts (contexts the user expects to be distinct and blinded from each other) intentionally consume and query the availability of the limited resources in a resource pool, to create a cross-context communication channel. Each context can then use the communication channel to pass an identifier, allowing each party to link the users behavior across the two contexts. We note again that most commonly the two contexts considered here are two different websites running in the same browser profile, but could also be the same (or different) websites running in different browser profiles.

I'll stick to Firefox anyway :)

How I wish all advertising networks worked like that.

So instead, this approach has different adversaries sharing the fractional information they've gathered about this user and collaborate to build a stronger profile to positively identify the user.

The problem as I understand it is when you have two separate contexts, neither of which can unique identify you by themselves, and they want to test whether you are in fact the same user and furthermore send information between each other. The two contexts are usually either (1) two different websites, or (2) two different browsing contexts (two profiles or one is a private browsing / incognito session) on one site. The two contexts have a server-side communication channel to coordinate the attack. The two together may still not be able to uniquely identify you, but that's not the attack -- they just want to learn if you're the same user.

I haven't read the paper, but I imagine it to work like this: say you have a global maximum of 100 WebSocket connections allowed alive at once. Context 1 opens up WebSockets until opening a new one fails. Then it tells the other context "hey, watch this." Using a shared clock, it closes one of the sockets for 1 second, reopens one for 1 second, etc., producing a string of 1s and 0s. The other context reads this string by attempting to open a socket of its own for a millisecond before closing it. (This is all hypothetical, there are probably flaws all over this.) If the probe succeeds, that's a 0, else it's a 1. You pass across a randomly-generated UUID or something.

If you're using separate profiles, the advertiser (attacker) can now permanently remember that those profiles are actually the same person. You have a happy tracker, sad user.

To defeat it, you need to partition the maximum limit, which means you either allow massive overcommitting, or you artificially restrict everything to a small value. It looks like they're arguing for overcommitting, using the argument that this will cause the attack to degrade the user's experience enough that they'll stop using the site, which means it'll stop being used.

(To mitigate it, it seems like you could slow down the cross-context resource accounting, to make the bit rate too slow to be useful? But it probably doesn't take many bits.)

But it is bad that you then decided to add a post to that effect.