Hacker News Reader

Comment by ballooney | Hacker News Reader

Would someone who actually _knows_ the answer (I know this will not deter the HN-reckon but worth a try) be able to comment on if/why this security gap exists?

Is it something fundamental to the different design choices, is it just which has had more test/resources thrown at it, and is the closing of the gap practical and/or on a roadmap?

View on HN

The Chrome multiprocess isolation model is really good. Firefox devs have known this for ages (heck, there were demos of a version of Firefox 3.x with a similar model), but could not actually land this model for two reasons:

- it would break all old-style extensions and users were unhappy about that;

- it takes looooots of memory and users were unhappy about that, too.

Now that Firefox has dropped all old-style extensions, there's large focus on reducing memory footprint, to allow moving to this model without costing as much memory as Chrome.

There are still a few kinks to fix, but this new isolation model should hopefully land within a few months.

Also, all sorts of security improvements are much easier now that Firefox dropped old-style extensions. Also, switching many developments to Rust makes new code much, much safer.

Also, Firefox isolates the browser UI and Web content into separate processes now. So that all the code you download from the internet doesn't run in the browser process. Same is with plugins.

A browser written in Rust (which is probably Firefox's long term goal) should blow Chrome out of the water in terms of security, despite the massive efforts invested in that regard by Google to prop up Chrome's C++ code base.

Would it really though? Sure, there are definitely things about Rust that make coding more secure, but surely that it only one part of security?

Definitely, it prevents the buffer overflow style of exploits but there’s also a lot of leaks in how all the DOM objects interact.

Indeed, that's only one part of security. But it's a pretty big one!

Google doesn’t have military grade static analysis that rejects anything that could allow buffer overflow attacks?

No, they don't, because such a thing cannot exist for C++. Any attempt would basically recreate Rust, or something equivalently incompatible with existing C++ codebases.

It seems unlikely that FF will ever be completely written in Rust. More likely that new bits that get added are Rust, and many of the old bits stay C++.

If FF gets rewritten in Rust, it will be a decades long effort.

I would just add that Mozilla also targets security critical portions with Rust rewrites. You don't necessarily need 100% Rust to be secure (if you have the right security model).

I know of at least one design choice that resulted in Chrome preferring security vs. Firefox preferring privacy: when exactly to persist HSTS information. https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro...

Reply on news.ycombinator.com