At what point do we admit that JavaScript was just a bad idea all round and drop it?

This doesn't look like it could possibly be that effective. Some pickings from the paper as I read through it:

Instead, to bypass the page cache for long-running measurements, we create a file larger than system memory.

Creating a file larger than system memory seems pretty non-trivial. I have 64G of memory and btop says 32.9G of that is currently used for cache. I would expect (but don't know if) there's some maximum filesize limit browsers impose on OPFS that really ought to be smaller than this.

On Chrome and Safari, OPFS supports very large files, up to 60 % of disk space, which is more than sufficient to avoid the page cache on most typical systems, as even a small disk size of 64 GB would allow us to create a 38.4 GB OPFS file. Thus, we can fill up the entire system memory on almost all systems, except specialized systems with very little storage and a large amount of system memory. On Firefox, the OPFS supports up to 10 % of total disk space or 10 GB (whichever is less) [45] per origin (i.e., website).

Oh okay, it's explained in the paper. Allowing any random website to use up to 60% of your disk space seems like it'd have issues other than a side-channel attack.

For our Linux measurements, we use a desktop PC with an AMD Ryzen 7 5800X3D CPU, 32 GB of DDR4 RAM and a 256 GB SanDisk SD8SN8U SSD running NixOS 26.05 with kernel version 6.18.5. On this machine, we perform latency measurements using Google Chrome 143.0.7499.192.

For our macOS measurements, we use a Mac mini with an Apple M2 CPU, 8 GB of RAM, and a 256 GB SSD, running macOS Sonoma 14.2.1, and running the attack in Google Chrome (version 144.0.7559.133).

They only perform the actual proof of concept on the Mac mini here, which as you can see only has 8 GB of RAM. Somewhat minor nit, but I remain unconvinced this is really practical on a workstation with 32G or 64G RAM. The Firefox 10 GB filesize limit is particularly tough for this attack, and their suggestion for overcoming it is purely theoretical (multiple sites running in parallel to have multiple separate OPFS storages).

For our FROST website-fingerprinting attack, we first generate training data for our CNN model. We collect traces while visiting the top 50 websites from the Alexa Top Million list [4], generating 100 traces per website, resulting in a labeled dataset of 5 000 traces. Additionally, we collect 1 trace each for the next 300 websites in the list as an open-world set. Our attack setup is symmetric, i.e., the attacker and victim can use the same or different browsers, as the attack works on the storage level, independent of the browser.

So if I'm reading this right, they use samples from the target machine to generate training data for the neural network that performs the side-channel detection. They seemingly claim this would work across browsers and definitely imply that it would work across different machines, but that seems like a huge, unproven assumption to make.

So basically the actual vulnerability here is, if you first let the attacker collect labeled data on your specific machine and then train a neural network on it, they can then later fingerprint your activity with some accuracy? Whoop de doo.

Can they actually force a write of a large file to test it or do they look at your specs? If they can actually force a large file writing whether it's 100 mb or 50 gb, 1tb this isn't even really a privacy issue it's just a, tech companies can just step all over you and your ardwae st to make sure your human or to make sure they can track your preferences.