[HN Gopher] Pool-Party: Exploiting Browser Resource Pools as Sid...
       ___________________________________________________________________
        
       Pool-Party: Exploiting Browser Resource Pools as Side-Channels for
       Web Tracking
        
       Author : btdmaster
       Score  : 31 points
       Date   : 2022-10-22 16:55 UTC (6 hours ago)
        
 (HTM) web link (arxiv.org)
 (TXT) w3m dump (arxiv.org)
        
       | bluechair wrote:
       | Question: would introducing jitter into browser network requests
       | help mitigate these attacks in any way?
        
         | VWWHFSfQ wrote:
         | Maybe? But the browser artificially making requests slower than
         | they already are seems like a naive anti-solution.
        
       | kfarr wrote:
       | 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).
        
         | CommitSyn wrote:
         | > 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?
        
         | [deleted]
        
       ___________________________________________________________________
       (page generated 2022-10-22 23:00 UTC)