Slashdot Mirror
Mozilla Announces Project Fission, a Project To Add True Multi-Process Support To Firefox (zdnet.com)
An anonymous reader quotes a report from ZDNet: After a year of secret preparations, Mozilla has publicly announced plans today to implement a "site isolation" feature, which works by splitting Firefox code in isolated OS processes, on a per-domain (site) basis. The concept behind this feature isn't new, as it's already present in Chrome, since May 2018. Currently, Firefox comes with one process for the browser's user interface, and a few (two to ten) processes for the Firefox code that renders the websites. With Project Fission (as this was named), Firefox split processes will change, and a separate one will be created for each website a user is accessing. This separation will be so fine-grained that just like in Chrome, if there's an iframe on the page, that iframe will receive its own process as well, helping protect users from threat actors that hide malicious code inside iframes (HTML elements that load other websites inside the current website). This is the same approach Chrome has taken with its "Site Isolation."
What you suggest is in fact being done. Servo is the project to rewrite Firefox's engine in Rust, a modern language focusing on provable thread safety through abstractions with zero runtime cost. Quantum is the project to replace parts of Firefox's engine written in C++ with the parts of Servo that are completed.
Except it's already a feature in Chrome(ium) since version 67, and you can read how it works here: http://www.chromium.org/Home/c...
This takes up a bit more RAM however, because each process has its own heap and executable thread for each tab or domain if you enable it by domains only (disabled by default).
This looks to be almost the same thing except just by domains instead.
Translation: "After a year of open discussion we didn't notice until now,"
Here for example is an overview of memory usage reductions related to Fission, from July 2018: https://mail.mozilla.org/piper...
I don't understand why processes are being used to provide security.
Processes leverage MMU hardware to achieve memory isolation such that each process has a private address space that can't be violated by another process without either compromising the OS or overcoming the MMU (rowhammer/spectre/etc.) You will now argue that the processes in a multi-process browser already communicate, pretending that this communication is unfettered by any limits. It is not. The browser designers control this communication with the intention of defending against compromised processes by dropping unnecessary privileges and minimizing the IPC attack surface.
why wouldn't they be able to exploit them to communicate with the other processes and cause just as many issues?
Because the OS and the MMU are specifically designed to prevent unprivileged processes from communicating with other processes. You will now argue that OS's aren't perfect and chips have flaws and so such designs are pointless. You will do this despite the fact that your proposal relies on hypothetical bug free systems as well, as we see here:
If there aren't any bugs in the code...
You're free to fantasize about bug-free systems, but the purveyors of real software must contend with bugs. Bugs in extensions, third party dependencies, compilers and their runtimes, drivers and every other conceivable thing. Any exploited flaw delivers the entire address space of your thread pooled browser and everything it's doing with no further effort. Process isolation at least offers an impediment to further comprise beyond the exploited process.
Google was right to design Chrome as they have, and Mozilla has been remiss in taking this long to copy it.
Maw! Fire up the karma burner!