True, and unfortunate. I’m still sad that Spectre is treated as an “all hands on deck” emergency—one that played a not-insignificant role in killing a browser engine, in fact. It’s very hard to exploit and process isolation doesn’t even fully help today.
-
-
Replying to @pcwalton @BRIAN_____ and
Specifically: The lack of e10s + sandboxing was exploited hundreds of times. Clearly implementing both was a huge priority. Spectre: a vuln never exploited in the wild that could conceivably be helped—once OS and HW fixes land—by a project that’s ~3x as much work as e10s. :\
0 replies 0 retweets 0 likes -
Of course we can never be sure. But finite resources and prioritization requires that we go with the best evidence we have. I think that memory safety work should take priority over Site Isolation, for example.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @BRIAN_____ and
Because when attackers attack browsers, in practice they go after memory safety issues (leading to sandbox escapes, often times). Not Spectre.
1 reply 0 retweets 1 like -
Replying to @pcwalton @BRIAN_____ and
(And to reiterate I think we *should* do Site Isolation…just that we should be clear about what the real-world benefits are going to be.)
0 replies 0 retweets 0 likes -
You’d rather have a memory-unsafe renderer with Site Isolation over a memory-safe one without it? That’s putting a *lot* of faith in your sandbox mechanisms.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @BRIAN_____ and
I am not nearly so sure that I would take a renderer in which attackers can attack the sandbox and IPC mechanisms directly via RCE over a renderer that has potential speculative execution vulnerabilities but no RCE.
1 reply 0 retweets 1 like
…given that we’ve seen a lot more sandbox escapes in the wild than we’ve seen Spectre exploits.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.