Mozilla enabled a new security feature in Firefox 53 recently that moves local file access to a new content process in the browser.
Firefox's new multi-process architecture Electrolysis is making big leaps. Mozilla started to roll out the new architecture in Firefox 48 Stable. While the roll out is still on going, Mozilla is already planning ahead in Firefox Nightly, the cutting edge development version of the web browser.
The stable versions of Firefox that have the multi-process architecture enabled by default use one content process only currently.
This means that the browser is using two processes: one content and one for the browser core. Users who use NPAPI plugins may see a third container for plugin content.
Firefox Nightly on top of that uses a process for GPU tasks powered by the browser's new Quantum Compositor technology.
Plans are underway to enable a second content process in Nightly for instance.
The improvement in Firefox 53 Nightly adds another new content process to Firefox that is only created when local files are accessed.
Any request to access local files using the file:// protocol uses an exclusive process for that request starting in Firefox 53 provided that the multi-process architecture is enabled.
The main reason for doing so is security. Mozilla notes that moving local file requests to their own process would block compromised Firefox processes from accessing local files.
The new local file access content process has only read access on the system Firefox is run on on top of that.
If we only have file:// URLs processed is a separate content process, then a compromised normal content process would not be able to use them to read files.
The file:// URL content process, would have read only permissions.
The new security feature is already enabled on Firefox 53 Nightly. It is not clear yet if it will land in Firefox 53 Stable.
The new feature is controlled by a a Boolean preference.
Set the preference to true (default) to enable the new content process for local file access, or set it to false to disable it.
Moving file access processes to their own content process makes sense from a security point of view. Since this process is only launched when file:// requests are made, and killed when the request end, it should have little to no impact on the browser from a performance point of view.
Now You: Do you run a browser with multi-process architecture?
If you like our content, and would like to help, please consider making a contribution: