Pool-Party: Exploiting Browser Resource Pools as Side-Channels for Web Tracking | Hacker News Reader

Pool-Party: Exploiting Browser Resource Pools as Side-Channels for Web Tracking

arxiv.org

52 pointsbtdmaster9 comments

LImited to "popular browsers". Were the authors unable to find side channels in unpopular browsers.

This is an issue only the state can prevent. This should be treated like robbing a bank, wire fraud, or any other such crime.

A browser add on won’t end this, jail time might.

Will the EU demand the CEO of an American advertising company be extradited for browser tracking? Unless every country does this, I think it's almost certainly moot.

Totally agree, the US is a big part of the problem. Lawless environment online.

Question: would introducing jitter into browser network requests help mitigate these attacks in any way?

Maybe? But the browser artificially making requests slower than they already are seems like a naive anti-solution.

I was interested in an overview of how the attack works, here's a copy / paste summary of a simplified example from the PDF:

> For this toy example, assume a browser vendor wants to improve performance by only allowing one video element to be loaded at a time, across all sites. If a video is currently playing on any page, the site will receive an error if it tries to play a new video. Algorithm 1 presents a toy algorithm where by two colluding sites can trivially transform this optimization choice into a cross-site tracking mechanism.

And later some examples of actual methods:

> We were able to use the relatively large WebSockets connection pool in Chromium- and Gecko-based browsers to conduct “poolparty” attacks. Safari’s WebSockets implementation was not exploitable, since WebKit does not restrict how many WebSocket connections can be opened simultaneously. Safari’s implementation of the SSE API, though, was previously exploitable before they fixed it. (Gecko’s implementation of the SSE API was not exploitable). Firefox alone was vulnerable to the Web Workers form of the attack (a surprising finding given that Tor Browser uses the same Gecko engine).

> Firefox alone was vulnerable to the Web Workers form of the attack (a surprising finding given that Tor Browser uses the same Gecko engine).

Are Web Workers enabled by default in the Tor browser bundle, and if so, what about the 'safest' setting?

Thanks for this, just giving a name for the attack is a major contribution but I appreciate the level of detail you went into on this.

Reply on news.ycombinator.com