In this case, I agree that it’s a low priority patch. Here’s what you must do as an attacker. Decide for yourself whether it sounds practical for general deployment.
Requirements: Fill OPFS storage with an arbitrarily large amount of data which at least exceeds RAM, but may require up to 60% of SSD, then lock up a thread with random reads while a worker thread hosts a model that you feed any detected latency clusters.
Even if users don’t notice their fans maxing / battery burning / memory+storage disappearing and kill the tab themselves, this definitely will be the first tab offloaded by most browsers and OSes shortly after it is sent to the background.
That means you have a brief window where you might get the chance to guess which sites a user is visiting. Your guess is likely far less than 89% accurate (PoCs illustrate in optimal conditions where models are often deliberately overfit to specific machine(s) and locale) outside a hyper-targeted attack, you will be lucky for coin toss levels of certainty for any guess.
While I am surprised by the lack of throttling or resource quotas permitting this (assuming they do) I must reiterate that repurposing OPFS this way is, to put it mildly, unrealistic even under optimal conditions. This “API for measuring SSD usage” is quite bad at it.
The meager data this exploit might return will, at best, require excessive cleanup to salvage any value at all. More likely, the data would still be considered worthless due to the expected margin of error and the likelihood that any targets successfully profiled are already well-known via existing datasets.
That said, typically niche-use-case and high-performance APIs that aren’t hidden behind experimental flags require user permission by default (a practice solidified by mitigations of other exploits like mining, fingerprinting, etc) so to find one open and apparently unregulated by default does seem unusual, if true.
Edit: Either way, I suspect any user vulnerable to this exploit is likely already exposed to much worse via similarly unsophisticated but more reliable attacks, and thus has already been heavily profiled.
In this case, I agree that it’s a low priority patch. Here’s what you must do as an attacker. Decide for yourself whether it sounds practical for general deployment.
Requirements: Fill OPFS storage with an arbitrarily large amount of data which at least exceeds RAM, but may require up to 60% of SSD, then lock up a thread with random reads while a worker thread hosts a model that you feed any detected latency clusters.
Even if users don’t notice their fans maxing / battery burning / memory+storage disappearing and kill the tab themselves, this definitely will be the first tab offloaded by most browsers and OSes shortly after it is sent to the background.
That means you have a brief window where you might get the chance to guess which sites a user is visiting. Your guess is likely far less than 89% accurate (PoCs illustrate in optimal conditions where models are often deliberately overfit to specific machine(s) and locale) outside a hyper-targeted attack, you will be lucky for coin toss levels of certainty for any guess.
Is this an attractive attack vector?
You’re not wrong. But on the other hand, do we really need a browser API for measuring a user’s SSD usage?
While I am surprised by the lack of throttling or resource quotas permitting this (assuming they do) I must reiterate that repurposing OPFS this way is, to put it mildly, unrealistic even under optimal conditions. This “API for measuring SSD usage” is quite bad at it.
The meager data this exploit might return will, at best, require excessive cleanup to salvage any value at all. More likely, the data would still be considered worthless due to the expected margin of error and the likelihood that any targets successfully profiled are already well-known via existing datasets.
That said, typically niche-use-case and high-performance APIs that aren’t hidden behind experimental flags require user permission by default (a practice solidified by mitigations of other exploits like mining, fingerprinting, etc) so to find one open and apparently unregulated by default does seem unusual, if true.
Edit: Either way, I suspect any user vulnerable to this exploit is likely already exposed to much worse via similarly unsophisticated but more reliable attacks, and thus has already been heavily profiled.