Sounds like one of those attacks that works in theory but is too impractical to use in real life. This is harder than cache side channel attacks, and we still haven’t seen much use of those in the wild, years later.
> Ultimately, this furthers other attacks, like website fingerprinting.
Umm no. Did ChatGPT write that? Fingerprinting isn’t an attack and that’s not how it works. Also this requires access to system temperatures and other metrics that are absolutely not available from JavaScript.
It's unfortunate that this article is poor, but the paper itself is clear and readable.
No problem, just use a zero-day to get full system access and then you can read the temps and send them back to JavaScript.
The Chrome developers at Google are preparing a WebHWiNFO proposal as we speak.
But when you read further and see what they tried:
We then selected one Arm instruction from each data-processing bucket,testingstores(str),AESinstructions(aese, aesmc), rotate right (ror), bitwise and (and), and both integer and floating-point addition (add, fadd) and multiplication (mul, fmul). We run each instruction in a loop on all available P-cores on each test device
What they did is define a handful of known workloads, with very different power profiles. And then they find that they can tell them apart by looking at the power of the chip. Well, duh.
Looks like only a local user can do this, but the article is not to clear on that.
Anyway this seems very hard to do. Also I wonder if using OpenBSD's port obsdfreqd can prevent this. Based upon usage, it will adjust the frequency and CPU Temp on the fly.
https://tildegit.org/solene/obsdfreqd
edit: grammer
