mozilla Firefox 53: Exclusive Content Process For Local Files

[vissha]

Firefox 53: Exclusive Content Process For Local Files

 

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 53: Content Process for local file access

 

 

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.

 

Quote

 

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.

1. Type about:config in the Firefox address bar and hit the Enter-key afterwards.
2. Confirm that you will be careful.
3. Search for browser.tabs.remote.separateFileUriProcess.

Set the preference to true (default) to enable the new content process for local file access, or set it to false to disable it.

 

You can check out the Bugzilla@Mozilla listing to read up on the development of the feature. (via Sören Hentzschel)

 

Closing Words

 

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?

 

Source

[banned]

Now You: Do you run a browser with multi-process architecture?

 

Nope. Like most "upgrades", they try to solve problems I never had, and instead create more problems than they solve.

[T3rM1nat0Rr3]

And just how many people have had "compromised Firefox processes".

 

Loads of people still use much older versions of Firefox without any problems at all.

 

[pc71520]

12 hours ago, banned said:

Like most "upgrades", they try to solve problems I never had,

and instead create more problems than they solve.

Crazy, isn't it?

[jamesbond]

right now i'm using v52, with e10s disabled. the only thing i notice when it is enabled: it eats more memory, and some extensions aren't working properly.

i couldn't feel any improvements with it enabled. on the other hand, i really want my extensions.

once v52 ESR is out, i will use this for a while, the same i did with v45 ESR

i usually don't need all that fancy new stuff mozilla comes up with, and with every release some extension stops working.

 

but i have to say, firefox runs very stable for me.

[DKT27]

This is an relatively important security fix rather than a performance feature. While I doubt many would even need to use this, there nothing wrong in improving the security I think.