That's interesting. Thanks for the explanation. If I read this right this isn't as effective against spinning HD-based systems and there is a dependence on the user maintaining more than one tab as they browse?

If that's the case then my system which is still HD-based is not threatened and since I tend to close tabs and windows and just spin up a new private window for each site while clearing cookies, etc on exit then maybe this is a non-issue for me. Or maybe just block javascript too.

It'd have some effectiveness against spinning HDDs because it's really just measuring contention for the I/O subsystem, but it'd likely be less because the kernel usually buffers writes to HDDs internally. But then, the kernel also usually buffers writes to SSDs, just with lower latency between the call and the data being written.

I don't think too highly about this particular threat vector - it seems like the kind of attack where you could perhaps get a working proof of concept going in the lab to write a paper and demonstrate some results, but actually using it to attack people at scale seems prohibitively noisy. People that close all their tabs when not at use are not at risk (and the data I had was that most people don't actually use browser tabs, they're very much a power-user feature). People who have disk-intensive other processes like Bittorrent or various file-syncing services aren't really at risk, because those other processes inject similar noise into the data stream. The signal in general seems weak because of buffering and differing SSD latency and so on.