3 ms·
Tried it in Firefox, but the timing result in the first step was already quite noisy (the two peaks overlapped to about 60%), and the second step didn't complet
by MauranKilom 6y ago
Tried it in Firefox, but the timing result in the first step was already quite noisy (the two peaks overlapped to about 60%), and the second step didn't complete after 3 minutes of dismissing repeated "a website is slowing the page down" prompts.
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.
- throwanem 6y agoIt may not work in Firefox due to the restricted resolution of performance.now() there; per the demo page, that is 5μs in desktop Chrome - Firefox meanwhile rounds to the nearest millisecond, per https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://developer.mozilla.org/en-US/docs/Web/API/Performance.... 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/fantastictimers.pdf https://pure.tugraz.at/ws/portalfiles/portal/17611474/fantas...
- lights0123 6y agoNow of course if they enabled COOP/COEP like their own guide recommends[1], that woukd be different. [1]: https://web.dev/coop-coep/ https://web.dev/coop-coep/