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.
> If there aren't any bugs in the code,
Ha! Good one!
> If there are bugs in the code, why wouldn't they be able to exploit them to communicate with the other processes and cause just as many issues?
You might be able to, but you might not - it depends entirely on the nature of the bugs.
Basically security programming amounts to putting multiple layers of armor around something, knowing full well that none of the layers are perfect. However, each layer makes it more difficult (read: expensive) to get to the chewy center, at least early on before the vulnerabilities are well known.
And when someone inevitably does find a way through, and the developers learn of it? Then that "one" vulnerability is actually a list of the vulnerabilities that were exploited in each layer or armor - fix any one of those holes and you're safe again, at least until they find a new way through that layer of armor. Fix most or all of them, and you send them back to the drawing board.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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...
Mozilla didn't see site isolation as a high priority until Spectre happened. Unfortunately it is now obvious that given a high-resolution timer, JS can probably read the contents of almost everything in the address space of the process it belongs to using side channels. That means site isolation has to be a priority.
As a temporary fix various timing channels have had their precision reduced, but that's only a partial workaround at best. Also Mozilla wants to enable parallelism primitives for Javascript that can be (mis)used to gather high-precision timing data.
Fine-grained multiprocess has some downsides but Mozilla can't afford to lag behind in security and privacy.
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!
we prepared this in 2014 already. we had to move stuff around until we could actually multi process at all. and sandbox. and move things around more.
firefoxos helped a lot making this happen because the mozilla management didnt care one bit, but it was required for firefox os to work well enough (its not kaios, 3rd worldwide mobile os). chrome was already ahead of course at the time and they were already dealing with this as well. for them, maybe it was secret, but their employee live next floor and keep talking everything anyway.
it took a lot more pushes, and eventually over the past years some of management approved that we should finish this up...
i worked on this directly, as paid staff. its not secret at all.
and while its a bit scary and uses more ram its definitely a big gain for security
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.
And even if it's not malicious/exploitable, it'll crash everything. That was my main annoyance, if you got one misbehaving tab in Chrome you can sort by CPU/memory use, find and kill it if it doesn't die on its own. In Firefox it was the "what tab is killing it now" guessing game.
Live today, because you never know what tomorrow brings