A Quantum Leap for the Web

Reading your comment, and the linked post, I'm left with the impression that this will not change in the foreseeable future. Every exploit shop considers Spidermonkey a security clusterfuck yet it's still in use. Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security. Iteratively improving things on top of a Javascript engine that's a security disaster and a C++ core will not give us a secure browser, as one can not build castles on top of sand.

At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries.

In an age where Nation States can MITM __the entire planet on demand__ [QUANTUM] and the FBI delivers Firefox 0day through TOR exit nodes, this blatant disregard for security should be entirely unacceptable. I don't really blame Mozilla, but those who use Firefox and give Mozilla their share in the browser market. If we don't demand better, we shall never have it.

(1) http://cyber-itl.org/blog-1/2016/9/12/a-closer-look-at-the-o...

Can you elaborate why SpiderMonkey is worse than Chakra, JavaScriptCore, and V8?

SpiderMonkey has approximately the same security track record as all of them. I think you're conflating the lack of sandboxing and some mistaken security-related decisions in the Firefox chrome with some sort of intrinsic security problem in the JavaScript engine.

> Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome.

And sandboxing is being actively worked on right now. In fact, it's an utmost priority.

Nobody is talking about doing Quantum instead of sandboxing. Rather, Quantum is being done alongside sandboxing.

> Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security.

I don't agree. Replacing C++ code with Rust code reduces the attack surface. The more of the browser you write in a memory safety language, the fewer opportunities for memory safety holes that attackers have.

Do I want to shrink the trusted computing base as close to zero as possible? Absolutely! But that's a long-term journey, and I would love to see Servo components get some real-world production use along the way.

> At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries.

There's only one browser vendor that is actively working on "scrapping the pile of mud and starting again", and it's the browser vendor you're complaining about. You claim that the lessons of security "escape" me, but I have been working day-in and day-out for years on a browser engine written from the ground up in a memory-safe language.

Seems like sandboxing exists (in some form) and is part of the plan? https://wiki.mozilla.org/Electrolysis#Security_Sandboxing

> Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security

Rewriting Spidermonkey in Rust is a major project in itself. JS engines have been highly optimized over the years and it's pretty hard to make a competitive new one. I would estimate that rewriting SM would be a project that's larger than Quantum and Electrolysis combined (I could be very wrong with this estimate).

> I'm left with the impression that this will not change in the foreseeable future.

There are folks who want to start replacing bits of SM with Rust code. Also, the build system platform support isn't yet in a state where you can write rust code and have it work for all supported platforms IIRC, so you can only use it for experimental things or nonessential features. Of course this will change by the time Quantum lands.

Not sure what the current status of SM oxidation is (there certainly is interest), but just because one project focused on speed exists, it doesn't mean that there aren't other projects focused on safety. This post and the comment you speak of are talking of the speed-focused project. You can't really draw conclusions about other, unrelated bits of the browser from this. Sandboxing seems to be pretty high priority, for example, but there's no reason for a post here to talk about this.

Also, security is still incremental. The castles on sand analogy only applies if an unpatched exploit exists in SM. This may be more common for Firefox over other browsers (IIRC this really isn't, it's just a matter of not having sandboxing, which I talked about above), but ultimately they get patched (except for 0days hoarded by malicious parties) and reducing the rate of exploits by using Rust elsewhere is certainly a plus.

0day being used by various parties is exactly what I'm talking about here. Most of it will not get patched anytime soon and I dare say is orders of magnitude "bigger" than the exploitable bugs that are reported and patched. Yet you don't seem to break a sweat about it, in fact you are comfortably dismissing it under "malicious parties".

Doesn't that strike you as weird? I know people have trouble putting threats that are not fully visible in perspective, but there is enough information out there for everyone to be able to establish an accurate-enough picture of what is happening. The entire Internet has turned into a domain of War, and we will live with Firefox for the years (or worse, decade) to come.