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 maintain that repurposing OPFS as a measure of SSD usage by this method is unrealistic even under optimal conditions, I gotta admit I’m surprised by the lack of throttling and resource quotas.
That is, assuming the API is enabled by default
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.
But if it’s gated by a flag or user permission, I don’t know why the fuck they’d bother to publish this.
ETA: Either way, I suspect any user vulnerable to this exploit is likely already exposed to much worse from attacks that are similarly inelegant but far more reliable. Those users are already heavily profiled in many datasets. I mean, no one here… hopefully.
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 maintain that repurposing OPFS as a measure of SSD usage by this method is unrealistic even under optimal conditions, I gotta admit I’m surprised by the lack of throttling and resource quotas.
That is, assuming the API is enabled by default
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.
But if it’s gated by a flag or user permission, I don’t know why the fuck they’d bother to publish this.
ETA: Either way, I suspect any user vulnerable to this exploit is likely already exposed to much worse from attacks that are similarly inelegant but far more reliable. Those users are already heavily profiled in many datasets. I mean, no one here… hopefully.