Until someone figures out how to exploit it using JavaScript. The speed this moves it could be any minute now.

From spectre.pdf:

> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.

(granted I think site isolation, if enabled, mitigates crossing domain boundaries)

It goes on to show a sample JS impl that JITs into the expected insns using V8.

And we can't even read TFA with javascript disabled, you have to be less secure just to read the google security blog.

Edit - mixing it up with this other article (https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...)

I can read the article without JS just fine.

Yet another argument against running any native or 1-to-1 bytecode in the browser like WASM

the big if is whether javascript code that can exploit this can be written. (edit: that's a yes, from the pdf itself...) if yes, nobody's safe, as any webpage (any webpage, even that ad in an iframe) could in theory read your password if it's anywhere in RAM.

Firefox and Chrome have both started posting mitigation strategies. They're mentioned in other comments, some depending on making time functions less accurate since this is a timing attack.

Chrome is listed as impacted. People use chrome password managers.

Chrome is listed as impacted due to javascript being able to read memory from outside the browser sandbox.

"In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." - from the spectre paper