If you're just interested in the PoC, it's available here: https://leaky.page/ and looks like the code is at https://github.com/google/security-research-pocs/tree/master...
That doesn't mean Firefox is safe, to be clear. Just that this PoC doesn't work well for my combination of browser and CPU.
That said, the demo also mentions a paper [1] on high-resolution timing channels available in Javascript without needing to rely on the performance API. I don't know how well a Spectre attack relying on such a timing method would fare in any browser.
Looking at that paper's abstract and code samples, I think most if not all of the timing channels it describes rely entirely on tight loops, so one or more of them being attempted would explain the high CPU usage you noticed.
[1] https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantas...
Does that mean I am missing some spectre mitigation stuff? I thought this was already fixed a few years ago? How do I stop this demo from working? (linux, intel i7, chrome 89)
Disclosure: I work at Google and am involved in deploying some of these features internally.
[1]: https://arxiv.org/pdf/1902.05178.pdf [2]: https://w3c.github.io/webappsec-post-spectre-webdev/
This was a huge WTF to me. I have been doing web dev for 10+ years and can barely get origin based security right. Now we're expected to understand process level security boundaries too???
That said, are there any resources explaining how the chromium process works? It has always been a black box to me. For example if a form is being autofilled, don't those personal info/passwords have to be loaded into memory? There's an infinite amount of things that I thought was inaccessible solely because there's no JS api to access the data that I now need to think about. Direct memory access is just a huge can of worms, no?
[0]: https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src/+/master/comp...