[animalCrax0rz]

"We were not able use these techniques in Firefox, as they recently reduced the timer resolution to 2ms. The techinque presented here is potentially relevant even for this timer resolution, but some parameter tweaking is required.?"

AFAIK, Chrome's highest resolution is also in the ms range.

I have some thoughts, too, but thoughts don't amount to a working exploit. Show me a currently working exploit, that is in the open. As far as state actors developing such exploits, there are a ton of holes in that scenario at every layer in the stack.

[saagarjha]

Their PoC focused on Chrome. I would assume that "parameter tweaking" probably means "change some things to make it work but run slower".

[animalCrax0rz]

HN wouldn't let me nest another response. This is in regards to "Timers aren't necessarily even a requirement"

<<you can busyloop and count iterations of that instead as a “timer”>>

Assuming you're the only job running on the CPU, which is not the case. Threads are not running continuously. But again, if there is a working exploit in the browser then show us. Talk is cheap.

[saagarjha]

I am aware that threads don't run continuously; scheduling just makes this worse just like timer jittering does. Sadly, I'm not the kind of person who can drop full, working exploits against unpatched browsers in response to Hacker News comments; I just have a passing interest in the field :(

[animalCrax0rz]

performance.now resolution in Chrome is between 1 and 2 ms, I believe, with jitter. If they have a working POC for Chrome why not demonstrate the full exploit and force the Chromium team to rethink their mitigations? Lots of people talking possibilities but zero working exploits in the open. That's not a good ground for rational debate.

[saagarjha]

Timers aren't necessarily even a requirement to exploit Spectre: https://news.ycombinator.com/item?id=22831067. It's pretty hard to protect against this in general unless you generate retpolines.