The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

I don't get the impression that those are the full extent of the changes though; I think those two were called out only because they're API changes rather than implementation details. Haven't checked the code so I could be wrong, of course.

A little bit more info can be found here [1]. In particular, site isolation [2] will also assist in protecting against this vulnerability.

[1] https://support.google.com/faqs/answer/7622138#chrome [2] http://www.chromium.org/Home/chromium-security/site-isolatio...

Would it be practical to run each javascript VM in it's own sandbox?

Edit: Apparently you can already do something like this. Seems to be an option for Chrome starting with 63. (Which was an October release I believe?

http://www.chromium.org/Home/chromium-security/site-isolatio...

That can't be right because they already round performance.now() so the Spectre attack didn't use it (it instead used a webworker with a tight-loop incrementing a counter)

the tight loop iteration used a shared array buffer to provide a high resolution timer, specifically to deal with the obvious fix of truncating precision of performance.now().

The reason for /further/ truncating performance.now() is that the relative cost in this attack means that you don't need as much precision as was needed for the original (page table? I think) attack.

A SAB timer just needs to increment a counter in one thread and read it in the host thread and the granularity is however long it takes to get through a for-loop.

Thanks, I missed how important SAB was to their webworker timer.

> ...severely round performance.now().

This sucks, and is a side-effect that I didn't even think about. I guess it's probably pretty effective, but it will make benchmarking a lot harder, since you'll probably now have to do a lot more runs.

If it was a big issue you can always introduce a 'benchmark mode' switch that allows you to put resolution back into the counter when you want to run a benchmark. Display a 'WARNING BROWSER INSECURE IN THIS MODE' banner for good measure.

Doubt that. The Firefox news said they will round to 20 us.

That's much more accurate than necessary to benchmark any software code.

Those are the mitigations firefox is doing. Is chrome doing the same?

For some reason, performance.now() and even the performance profiler are capped at 1 milisecond precision on my machine, which make both pretty much useles. Can only get better for me. :|