[dherman]

[disclaimer: I co-founded Mozilla Research, which sponsors Servo]

It's awesome to see the Gecko team continue to tackle big, ambitious projects now that electrolysis is rolling out. And I'm so excited that they're betting big on Servo and Rust. Servo has really been taking advantage of one of Rust's promises: that you can reach for more aggressive parallelism and actually maintain it. I believe recent numbers showed that effectively all of Firefox's users have at least two cores, and about half have at least 4. The more we fully utilize those cores, the smoother we should be able to make the whole web.

Over the last year, all three communities have been laying groundwork to be able to land Rust components in Firefox and share components between Gecko and Servo, and now it looks like that's teed the Gecko team up to commit to making use of some big pieces of Servo in the coming year. Some of the initial builds of Firefox with Stylo that Bobby Holley has showed me look really amazing, and WebRender could be a game-changer.

And the Servo project is just getting warmed up. ;) If you're interested in what they're up to next, check out Jack Moffitt's recent presentation from a browser developer workshop last month:

https://www.youtube.com/watch?list=PL4sEzdAGvRgCYXot-o5cVKOo...

[tomdale]

I have to say, the work being done on Servo is really exciting—the first tectonic shift in browser engines to come along in years.

pcwalton's talk about WebRender earlier this year[1] was one of those rare technical presentations that left my jaw on the floor. In particular, the insight that modern browsers are just AAA game engines with a security model, so they should be architected similarly, changed the way I think about browsers. That game developers and Mozilla are both so excited by Rust's ability to safely write parallel systems at scale makes a lot of sense.

[1]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... Previous HN discussion: https://news.ycombinator.com/item?id=11175258

[the8472]

> The more we fully utilize those cores, the smoother we should be able to make the whole web.

I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism.

When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core.

In other words, from the outside it looks like a low-hanging fruit that has not been plucked.

[pcwalton]

> I wonder why the GC/CC are not multithreaded though. It seems like those are fairly isolated components, considering the entire application gets suspended so they can do their job, i.e. prime candidates for parallelism.

> When forcing a collection on a large firefox instance it can easily spend 20+ seconds collecting on a single thread while a java VM can munch churn through something like 1 gigabyte per second per core.

Several reasons why this isn't low-hanging fruit and isn't as valuable as it may seem:

1. Servo runs separate origins as fully separated JS VMs on separate threads. Because they're separate runtimes, the collections can already happen concurrently.

2. The isolated JS runtimes imply isolated heaps, so there is no need for global collection (and in fact no way to do it even if we wanted to with the current SpiderMonkey architecture). Small individual per-origin heaps are much faster to collect than large global heaps.

3. While collection is happening, like in other modern browsers, the Servo chrome and scrolling are fully responsive. But Servo goes beyond that: animations, layout, and repainting can also happen while a GC is occurring. This means that CSS transitions/animations on the page (all animations, not just transform and opacity!) will still happen while the page is collecting, and you can switch tabs and resize the window while the GC is running. You can even interact with cross-origin iframes on the page, so GCs triggered by ads won't affect the content you're reading!

4. SpiderMonkey already has incremental and generational GC, so we've done most of the work necessary to reduce stop-the-world pauses already.

5. Making a single-threaded GC concurrent is a lot of work. It's not low-hanging fruit by any stretch of the imagination.

6. Furthermore, making a single-threaded GC concurrent usually involves a throughput loss, because now you need operations to be atomic that weren't atomic before.

That said, the GC is something that the SpiderMonkey team continues to make steady progress on, and that work directly benefits Servo. So fear not, we aren't neglecting the GC either :)

[mccr8]

Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done in parallel in Firefox.)

That said, I believe IE does some concurrent marking, so there is certainly room for improvement.

[the8472]

> and throughput is more of a concern for server-like workloads

Many java applications also have to worry about latency, not just throughput. Parallel collections cut down on pause times, too. Simply because they can get about the same work (in terms of CPU cycles) done in less wall time. I.e. parallelizing non-concurrent GC phases also improves responsiveness.

[johncolanduoni]

That would be hard to do without writing a new javascript engine, which would expand Servo's current scope pretty dramatically. My guess would be that as long as there are big gains to be made that can be done without rewriting SpiderMonkey, the servo project would rather only tackle one massive project at a time :)

[xorcist]

> all of Firefox's users have at least two cores,

As an end user, it concerns me slightly that the visible change will be that Firefox pegs two cores instead of just one.

An absolute explosion in Javascript usage on the web together, of low quality haphazardly put together at runtime, together with the convenience of tabs makes this a problem. Mozilla may do everything right but that doesn't necessarily help the end user.

Is there anything I could do easily to remedy this, without bothering with white listing Javascript? And is there any activities at Mozilla concerning this, perhaps with identifying the most trivial cases of scripts spinning without doing useful work? Maybe pausing DOM changes for documents that aren't visible?

[mdahlstrand]

Disable javascript? Not that it's massively fun for you without javascript on the web, but it sounds like you have a very performance dependent workload on your computer. I don't think it's anything most people will have to worry about though, cpu scheduling is pretty good most of the time, and people's javascript suck less and less.

[pcwalton]

> Maybe pausing DOM changes for documents that aren't visible?

We already throttle background tabs heavily in various ways.

[oldmanjay]

I would personally not be so eager to disclaim such impressive credentials, but I suppose you have your reasons.

[armitron]

It's telling that not one comment in this entire thread mentions security and exploitability, two areas where Firefox is not just terrible, but the worst choice amongst (Chrome, Safari, Firefox) (1) but also Edge and IE 11. Everyone is focusing on performance, as if that's the BIG issue these days. Talk about having your priorities screwed up.

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...

[pcwalton]

> Every exploit shop considers Spidermonkey to be a security clusterfuck yet it's still in use.

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.

[Eridrus]

Do you see sandboxing at odds with performance? I know it causes a hit to RAM, but I have no sense for impact on CPU usage or user responsiveness metrics.

Once sandboxing is implemented, will there be a push to implement the privileged process in Rust?

[armitron]

It's not just the lack of sandboxing, Spidermonkey is qualitatively worse than V8. The metric used is ease of finding exploitable bugs _without taking sandboxing into account_. I do not know where you get your security track record from, but there is a big asymmetry in public-vs-private information on the matter. Most of the research into exploitation happens behind closed doors and the general public is not privy to it.

Reducing the attack surface is meaningless when the attack surface is humongous, yet people keep reiterating the same old fallacies.

Mozilla has said nothing about starting again on solid foundations. All I see are iterative improvements on top of the same, rotten core, with an emphasis of performance to boot. This is not progress.

[pcwalton]

> I do not know where you get your security track record from, but there is a big asymmetry in public-vs-private information on the matter.

No, there isn't. Security bugs are made public in both Bugzilla and chromium.org once enough time has passed. Both engines have been around for years and years, so there's been plenty of time to gather data.

Sorry, but I'm not going to just trust "I can't link to anything because it's secret".

The only security-related feature that V8 has that SpiderMonkey doesn't is limited constant blinding in the non-optimizing JIT only. This is a cosmetic feature that does little, because an attacker can trivially subvert it. See: https://bugzilla.mozilla.org/show_bug.cgi?id=677272#c58

> Reducing the attack surface is meaningless when the attack surface is humongous, yet people keep reiterating the same old fallacies.

How are we going to get the attack surface down unless we reduce it?

> Mozilla has said nothing about starting again on solid foundations.

1. What do you think Servo is?

2. Who else is talking about "starting again on solid foundations"?

[Eridrus]

Bugs are only made public when developers find out about them then fix them. Many exploits simply die to code churn rather than developers actually fixing what they understand to be a vulnerability.

I have no horse in this race, but I don't think you should assume you have all the information.

[Eridrus]

My knowledge may be out of date, but afaik one example of SpiderMonkey being worse is that it requires manually rooting objects; I don't think Chakra or v8 have this manual requirement that leads to security vulns.

[armitron]

> How are we going to get the attack surface down unless we reduce it?

Ideally you never introduce it. Alternatively, you never let it get to the point where getting it down is essentially a no-op.

>> Mozilla has said nothing about starting again on solid foundations.

> 1. What do you think Servo is?

A research project in a Mozilla lab that is not fully embraced yet. Parts of it may, slowly, end up in Firefox. How does this improve matters or introduce solid foundations? I have yet to see a concrete commitment from Mozilla that Servo will be fully utilized in Firefox. Even the linked article demonstrates the opposite. Even so, let us assume that Firefox uses Servo. We're still in security hell due to SM.

> 2. Who else is talking about "starting again on solid foundations"?

In practice, Microsoft did tremendous work with Edge.

Chrome is not perfect, but is as close to perfect as you can get while still using rotten tools (C++).

There is a shift inside Apple too. We will see how it manifests.

[pcwalton]

> Ideally you never introduce it. Alternatively, you never let it get to the point where getting it down is essentially a no-op.

I can't understand this logic at all. You seem to be denying that you can ever reduce software attack surface in existing software, which is obviously false. It's undeniable that seccomp-bpf dramatically reduced attack surface in the Linux kernel, for example.

> A research project in a Mozilla lab that is not fully embraced yet. Parts of it may, slowly, end up in Firefox. How does this improve matters or introduce solid foundations?

I would think the important thing that determines whether we're developing the software is whether we're developing the software, not whether there are immediate product plans. By that logic, AT&T never developed Unix.

> Even so, let us assume that Firefox uses Servo. We're still in security hell due to SM.

No. I've already explained why this is incorrect. Switching to V8 would make negligible if any difference in terms of security.

> In practice, Microsoft did tremendous work with Edge.

EdgeHTML is a fork of Trident! Its development was not "starting again on solid foundations"!

> Chrome is not perfect, but is as close to perfect as you can get while still using rotten tools (C++).

Chrome is a fork of WebKit, which is a fork of KHTML! Its development was not "starting again on solid foundations"!

[Manishearth]

> Even the linked article demonstrates the opposite

No it doesn't. Servo is still chugging along. Firefox wants to get Servo's advances early.

> I have yet to see a concrete commitment from Mozilla that Servo will be fully utilized in Firefox.

Because Servo is a long term project. And writing a new browser engine is hard, if you want to be 100% web compatible. Servo's getting there, but it will take time.

> We're still in security hell due to SM.

No it doesn't. Content sandboxing is being actively worked on. Even if not, pcwalton already mention that SM and V* are roughly on par wrt safety features (aside from sandboxing).

> Alternatively, you never let it get to the point where getting it down is essentially a no-op.

You have yet to demonstrate why you think Firefox's attack surface is that bad. You linked to a blog post which uses this (http://cyber-itl.org/blog-1/2016/8/12/our-static-analysis-me...) metric, which is light on the specifics (or reproducability). ASLR and content sandboxing may be enough to bump Firefox back to the top. There's nothing there to convince us that the metric used maps well to real-world exploitability.

[Manishearth]

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

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.

[armitron]

They do seem to have Chrome-style Sandboxing in-progress, I guess we'll see how it turns out.

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.

[Manishearth]

> Note that I did say "Sandboxing ala-Chrome". The link you used demonstrates sandboxing for _plugins only_ which is practically useless, most of the Firefox 0day I've seen goes after Spidermonkey.

No, the link mentions "Content" all over the place, which is websites (and IIRC SM runs in the same process). It seems to be a work in progress, but that was all I was going for.

> And 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 break a sweat about it, in fact you seem comfortable dismissing it under "malicious parties".

No, I focused on patched exploits because IMO they can cause more harm (especially to users who don't get the patch in time) over zero days. Zero days can still cause harm, but because they're hoarded it's often less harm -- they can mostly be used in targeted attacks, since in broader attacks it's less likely for them to work under the radar (and stay unpatched). I could be wrong here, sure (and whether targeted attacks are less harmful than broad ones is debatable too, since targeted attacks generally do much more). But I'm under the impression that 0 days in SM (or indeed any software) are not as common as you seem to believe (of course, data on this will be incomplete). Hence I focused on patched exploits (not knowing that you were talking about 0 days in particular).

I was not breaking a sweat about either type of vulnerability because content sandboxing is something being worked on. These vulnerabilities are still bad with sandboxing, but it no longer is something that is hard to incrementally improve on.

[armitron]

> No, the link mentions "Content" all over the place, which is websites (and IIRC SM runs in the same process). It seems to be a work in progress, but that was all I was going for.

You are right, I've updated my post.