[jackcook]

I don't think any of these side channels are really easy to pull off without the technical capabilities of a nation state or something similar. I personally think embedding a malicious script in a CDN (e.g. https://blog.ryotak.me/post/cdnjs-remote-code-execution-en/) that serves a script for a large website, or something similar (https://blog.igorescobar.com/2016/08/21/ive-the-chance-to-tr...), is more realistic than getting the victim to install your program -- I would imagine sensitive individuals are very concerned about installing arbitrary software.

We did get a comment about this in our rebuttal but didn't end up including it in our final paper -- we found that we distinguished sites with the same frameworks (such as react, angular, and jquery) at the same accuracy at sites that used different frameworks.

We didn't do much research into content/non-homepage paths but it's a good area for future research. I would suspect it'll still do pretty well.

And yes, we concluded that the source came from interrupts (in Table 3 of our paper you can see we ran an experiment with frequency scaling turned off), which does make me question the practicality of hertzbleed. I wouldn't doubt it can be exploited somehow though.

[yunohn]

In my experience, large websites and most web apps don’t use CDNJS/etc, but bundle their code - this would make injecting your script much harder without a supply chain attack.

On second thought, given CORS I think this attack is actually impossible. How would your embedded script communicate your findings with your server? You would need to control the originating domain itself…