I must admit that people around me are starting to show an increasing interest in multi-process Firefox and so, I’ve decided to further document the electrolysis project herein.
The electrolysis project ?
Electrolysis is the working name of a Mozilla project which goal is to re-arch good old single-process Firefox into a multi-process one. The idea’s been around for some time now, all the more so since competitors like Google and Microsoft have released multi-process versions of their browsers! Currently, there is going to be three types of concurrent processes :
- The main browser process (called the “chrome process”)
- Plugins processes (called “plugin processes”)
- Web content and script processes (called “content processes”)
And why are we moving toward multi-process browsers ? Because there are several benefits associated with it :
Security
Generally, plugins are a potential threat to browsers integrity. In the single-process case, they can load themselves into the main address space and exploit weak entry points by, say, calling functions with forged string arguments. With multi-process electrolysis, though, each plugin gets loaded into its own process (with its own address space) and is considered “untrusted” process. Those “plugin processes” have to communicate with the main browser process through IPDL, an inter-process/thread communication protocol language developed by Mozilla. Thus, most of exploit/attack attempts from plugins are more easily caugth. When caugth (Or in fact, when any IPDL protocol error is detected), we just shutdown the plugin process.
Regular web content and malicious scripts may just as well do harm to the system. Thus, each tab you open in the browser is going to load and run its web content in separate “content processes”, also considered “untrusted”, thus leading to all the above-mentioned security advantages.
But IPDL is not the only security feature that’s added to electrolysis. In fact, multiprocess Firefox will also implement sandboxing to keep untrusted processes from accessing some system resources/features.
Performance:
Since we’re seeing more and more multi-processor/multi-cores CPU coming to the market nowadays, it is very likely that this chrome/content/plugin process separation will greatly increase general performance. In fact, multi-process software are well-suited for multi-CPU/multi-cores systems and therefore, each process can be separately run on a single CPU.
Stability:
Formerly, with single-process Firefox, if some web content happened to crash, the whole Firefox process would crash. This will not be the case any more with multi-process Firefox. Because every web content/plugin will run in its own process and address space, crashes caused by some scripts/plugins/content on some web site will only affect the associated browser tabs, thus letting the user browse other web sites normally. This is an important breakthrough for increased Firefox stability and, because the “chrome” process (the main Firefox “default” process) is self-contained and well-tested, the rate of main process crashes should drop near 0.
UI responsiveness
UI responsiveness is an important aspect of every user’s browsing experience, especially on mobile devices. UI responsiveness could be simply defined as the time elapsed between, say, a click from the user and the associated visual feedback from the UI. In the browser world, UI responsiveness is especially important when panning the content area around. The user wants to feel he’s really manipulating the content in realtime. In Firefox, the main “chrome” process is responsible of all the UI stuff. So, having all the UI-related management isolated into a single trusted process will surely increase the browser’s responsiveness.
The world is OPEN 