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 b

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).