Re:UnGoogled Chromium: Chromium with enhanced privacy, contr...
by pcwalton on Monday September 26, 2016 @02:47AM
(#12579764)
> Spidermonkey in particular (Firefox's Javascript engine) is laughably bad when it comes to vulnerabilities.
This is the first I've heard this claim. Do you have data showing this?
JS engines, from my point of view, regularly have all sorts of memory safety issues. No particular JS engine stands out relative to the others.
> This is also the reason why the Servo browser that some folks think will be a lot more secure (due to Rust) is mostly smoke & mirrors. They're planning to keep using Spidermonkey there too!
Smoke and mirrors? Servo has sandboxing, which is already implemented (and which I maintain). There's a night and day difference between that and an unsandboxed browser.
The goal of Servo's architecture is to, first, achieve a best-in-class sandboxing story and then, afterward, to advance the state of the art by reducing attack surface. We aren't going to reduce the memory safety attack surface to zero. But it's very much feasible to reduce it so far down that attackers don't even look at layout/DOM/etc. code for memory safety issues the way they do today when searching for browser holes. The return on investment when looking for memory safety holes in memory-safe languages just isn't there.
This is the first I've heard this claim. Do you have data showing this?
JS engines, from my point of view, regularly have all sorts of memory safety issues. No particular JS engine stands out relative to the others.
> This is also the reason why the Servo browser that some folks think will be a lot more secure (due to Rust) is mostly smoke & mirrors. They're planning to keep using Spidermonkey there too!
Smoke and mirrors? Servo has sandboxing, which is already implemented (and which I maintain). There's a night and day difference between that and an unsandboxed browser.
The goal of Servo's architecture is to, first, achieve a best-in-class sandboxing story and then, afterward, to advance the state of the art by reducing attack surface. We aren't going to reduce the memory safety attack surface to zero. But it's very much feasible to reduce it so far down that attackers don't even look at layout/DOM/etc. code for memory safety issues the way they do today when searching for browser holes. The return on investment when looking for memory safety holes in memory-safe languages just isn't there.