Mozilla Announces Project Fission, a Project To Add True Multi-Process Support To Firefox (zdnet.com) 67
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."
Chrome memory usage (Score:4, Funny)
Firefox: Hold my beer.
Even more copying (Score:1)
In other words, more like Chrome which means even more CPU and memory usage for little gain.
If people think they're not going to go down the same road and eventually gimp extensions as well, then they're naive.
Re: (Score:1)
Chrome's plan is to change an API that will essentially kill ad-blockers, and Firefox will probably follow suit.
Re: (Score:2)
The concept behind this feature isn't new, as it's already present in Chrome
I think this should actually be the generic template for any news about Chromefox:
Mozilla announces plant to add $X to Firefox. The concept behind this feature isn't new, as it's already present in Chrome.
for any given value of X.
Heard of Rust? (Score:5, Informative)
What you suggest is in fact being done. Servo [servo.org] 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 [mozilla.org] is the project to replace parts of Firefox's engine written in C++ with the parts of Servo that are completed.
Re: Heard of Rust? (Score:1)
You mean you expect people to do their research and know what they're talking about before commenting? What a crazy concept!
Firefox Quantum memory footprint (Score:5, Interesting)
Memory footprint is bad with Quantum. Never had my laptop swapping until I upgraded to Firefox Quantum.
However, there is a workaround:
Under Preferences -> Performance -> Content Process Limit, change it from 4 to 2 or 1.
The default is the number of cores in your CPU, and when I went from a 2 core laptop to a 4 core one, memory skyrocketed. Setting it back to 2 or 1 keeps it under control.
Also add the Auto Tab Discard Addon, and set it for 15 minutes.
Re:Typical C(++) coders. (Score:4, Funny)
I'm starting to hare firefox (Score:2, Funny)
Re: (Score:2, Funny)
Wait until Intel puts it on-die as part of their new IME. "The fastest most hyperthreaded browser-on-a-chip is now always on even when your machine is off! Swear to god, it's a feature! Sure someone asked for it!"
One process per window or tab. (Score:1)
That should be it.
This will do nothing to properly isolate inter-site scripting attacks, it will increase memory footprint (less if you are on linux and have ksm(kernel samepage merging) running and the threads flagged as ksm compatible.), increase attack surface, and further complicate the already messy debugging firefox requires.
If we were to go back and fork from FF-ESR 38, 45, or 52, implement this process isolation on a per-window or per-tab basis, and have plugins tied to per-window or per-tab session
Re:One process per window or tab. (Score:4, Informative)
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.
Re: (Score:2)
I think that they did exactly that, lowered the precision of the timers.
However if you have threads, you can make your own high precision timer by running a loop in a single thread while doing the side channel in another.
Re: (Score:2)
Yeah damn that completely voluntary update process that I could disable at any time. Damn it to hell!
Help Me Understand? (Score:1)
I don't understand why processes are being used to provide security. Can someone explain it in more detail? If there aren't any bugs in the code, then it shouldn't matter where anything is running because it won't be able to do anything it's not supposed to do. 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? I would think spending time implementing a simpler thread pool with everything being task based would
Re: (Score:2)
Faster too and the OS can still keep up in the background as it has its own part of the CPU.
Everyone gets a part of the CPU.
Re:Help Me Understand? (Score:5, Informative)
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... [chromium.org]
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.
Re: (Score:2)
I don't know, I struggle to believe that, hell Mozilla are incapable of shifting the tab bar back below the address bar where it belongs, so fancy stuff, I am not so sure about that any more.
Re:Help Me Understand? (Score:4, Informative)
> 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.
Re:Help Me Understand? (Score:5, Informative)
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.
Re:Help Me Understand? (Score:4, Informative)
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.
Local Render Server? (Score:4, Interesting)
How long until we have some HTML5/CSS/JS hardware accelerated chip to do the actual rendering and just pass the display information to a 'thin client'?
At some point it's going to be faster to x11 forwarding/VNC to a bigger machine somewhere else to handle the latest JS framework.
Re: (Score:2)
I think you just suggested that we either switch to multi-core CPUs (welcome to 2010), or we switch to cloud rendering (over my dead body).
Re: (Score:3)
How long until we have some HTML5/CSS/JS hardware accelerated chip to do the actual rendering and just pass the display information to a 'thin client'?
At some point it's going to be faster to x11 forwarding/VNC to a bigger machine somewhere else to handle the latest JS framework.
I think it was either oprea mini or opera mobile actually did this to run a their browser at reasonable speeds on early feature phones it would render the web pages on their servers and send the output compressed to the phone were it would decompress it and show the rendering.
Re: (Score:2)
Well, Windows is nearly there, they actually allow you to run the browser engine in a VM if you have Enterprise and configure it to do so. Unfortunately with the recent announcement that they are moving the rendering engine from EdgeHTML to Chromium for Edge I'm not sure if the feature will be supported going forward. I hope they do as it's one of the better end user security features now that Outlook isn't such a steaming pile.
Secret prep != OSS? (Score:2)
Can someone help me square the "open" part of OSS with "a year of secret preparations" please?
Re:Secret prep != OSS? (Score:5, Informative)
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.org]
Re: (Score:2, Informative)
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 ta
Terrible news for tab hoarders (Like me) (Score:1)
So now I’m going to have like 500-600 additional processes running on my box every day. Hrm.
Great... More of a hog? (Score:2)
So instead of taking 100% of my CPU, Firefox will be able to take 500% or 1000% of my CPU (100% for every tab I have opened and Firefox is spinning on for some reason.)
And so instead of nearly crashing my machine by hogging resources, it most certainly will.
Please, Firefox devs, get the CPU and memory leaks, javascript wedging, etc., under control before splitting things into more processes (which will just further hide such performance/memory leaks for now.)
At least one might (supposedly?) be able to kill