3 ms·
See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and ins
by ddworken 6y ago
See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and instead focusing on what can be done at the browser level. And at the browser level, it is possible to ensure that sensitive resources don't end up in processes running attacker JS.
Of course this could be fixed at the CPU level, but realistically very few people want that since that would drastically slow down modern CPUs which rely on speculative execution.
[1]: https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf
Disclosure: I work at Google and am involved in deploying some of these cross-origin resource restrictions internally.
- the8472 6y agoBut it's still going to help exploits against the browser, isn't it? Letting code poke around until it finds addresses it needs or something like that.
- ddworken 6y agoAs I understand it (though I don't work directly on Chrome), a key part of Chrome's threat model is that a compromised renderer process (where there is one renderer process per site) has limited security impact. So being safe against Spectre (which gives a read primitive in the renderer process) is just a subset of being safe against a compromised renderer process.
- 177tcca 6y agoPer site isolation =] Which the (comparably) insecure likes of Firefox (unfortunately) does not have.
- ddworken 6y agoNot yet! But soon. :) See Project Fission [1]. Currently if you're using Beta or Nightly you can toggle it on and I believe it is getting very close to being ready to ship. [1]: https://wiki.mozilla.org/Project_Fission https://wiki.mozilla.org/Project_Fission