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.
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.
- Type about:config in the Firefox address bar and hit the Enter-key afterwards.
- Confirm that you will be careful.
- 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?
@Tom Harvack
When you gain some Security you ALWAYS lose some Liberty… and we know how Mozilla is paranoid and willing to remove any power to the user to gain so called “security”.
Just call me Tom! even if Harvack looks nicer than Hawack. Maybe the “Har” like Harvard (I’ll forget Hara Krishna!)
“When you gain some Security you ALWAYS lose some Liberty”. I’d rather conceive that assertion as a philosophical study. Also because I’m rather cautious with assertions, definitions which often (aim to) stick with the power of eternity what may not be (as well as it may be) true. Not sure if skepticism guides my interest for philosophy or if it’s the other way round, though :)
“I’d be sucking my thumb” .. so that would be a rule of thumb then? Amirite?
@Tom “Should we face once again the dilemma security (e10) verses privacy (monitoring local storage)”
I’m not an expert on this, but surely, by it’s very nature .. a single process (currently only split between UI and content .. but later on per domain, per tab .. when it arrives) then NOTHING can be cross-contaminated – right? I mean each process has it’s own restrictive security sandbox.
So the usual mantra applies – block cookies and dom storage by default (99% of sites work fine without them) and only allow when you really have to. Block all xss by default, etc. There are also other settings such as isolate first party and enforcement based on origin attributes .. by the time we get to 57 and Web Extensions only (and that could be delayed) .. a lot will have happened with e10s as well (although that too could be delayed). I’m going to go out on a limb here and say you can lock your local storage down to only being read by first party.
So the only question remains, is the means to (auto)wipe a domain’s local storage in order to defeat first parties … not talking about sites where you log in (eg gmail, facebook), but for example, the occasional site which requires cookie and dom to function properly, such as cracked.com. I don’t log in there, but they could track me thru dom storage. I was looking at Cookies Exterminator and was thinking I might set it up to see if it would work with cookie controller: cookie controller to allow which sites can have cookies/dom either session or permanent (default block all), and cookies exterminator to whitelist a couple and autoclean everything else when not open in a tab (rather than waiting for the session end)
What say you Tom?
I say, Pants, that I have whatever your expertise level may be minus a strong delta.
I try to avoid cross-site data exchange. To accomplish this without breaking anything (valuable) I limit as much as I know and can whatever storage.
Concerning cookies and LocalStorage (the data that fills webappsstore.sqlite) I use the Firefox ‘Self-Destructing Cookies’ add-on, which removes a site’s cookies AND the site’s fill of LocalStorage once the user has quit the site unless that site is whitelisted (means set as exception to keep in Firefox options) :
user_pref(“dom.storage.enabled”, true); // ‘Self-Destructing Cookies’ add-on (webappsstore.sqlite)
Concerning IndexedDB which fills another user’s local storage (user’s profile ‘storage’ folder), dom.indexedDB.enabled, I don’t even have to set it because I use another Firefox add-on called ‘Disable IndexedDB’ which disables IndexedDB at Firefox start and has its toolbar button to enable IndexedDB on user’s choice, hence on per-site requisite. If a site doesn’t render correctly all I have to do is toggle the IndexedDB permission to ON with the toolbar button… and toggle the setting to off once I quit the site : unfortunately no per-site permission for IndexedDB in Firefox.
Concerning Mixed Display Content (security.mixed_content.block_display_content), I set it to false and, as above, use another Firefox add-on, ‘Toggle Mixed Display Content’ on per-site requirement.
I use extensively the — your — famous user.js settings, never blindly and with a disagreement here or there, but few.
I have an empirical approach to all this “stuff” because I lack a global approach and try to use brains and intuition when brains get stuck on a 50/50 pro/con issue. Moreover English is not my mother-tongue, English slang even less, technical English lesser even :)
As you see, without experts (that qualification means anyone knowing what I ignore) I’d be sucking my thumb as a new born child when it comes to the infinity of computer/network settings.
About security vs. privacy, how ironical a society’s dilemma (sure is a trend nowadays) gets applied to the networks. I often wonder if security is not sometimes a pretext to invade one’s privacy.
Let’s stay in peace (don’t go if you can help, otherwise as you like it!)
Of course Mixed Display Content has nothing to do with cross-site data exchange, at least not obviously. I mentioned it above because it was served by one of those toggle add-ons I appreciate.
Concerning cross-site data exchange, I forgot to mention an essential settings area, that of so-called Service Workers, which I’ve concatenated (from your user.js) into one dedicated group in my user.js file :
// SERVICE WORKERS
// disable workers API and service workers API – WARNING: WILL break sites as this gains traction -> ENABLE?
user_pref(“dom.workers.enabled”, false);
user_pref(“dom.serviceWorkers.enabled”, false);
// disable SharedWorkers (SharedWorker violates first party isolation)
user_pref(“dom.workers.sharedWorkers.enabled”, false);
// disable service workers cache and cache storage
user_pref(“dom.caches.enabled”, false);
// disable push notifications – push requires serviceWorkers to be enabled
user_pref(“dom.push.enabled”, false);
user_pref(“dom.push.connection.enabled”, false);
user_pref(“dom.push.serverURL”, “”);
user_pref(“dom.push.udp.wakeupEnabled”, false);
user_pref(“dom.push.userAgentID”, “”);
// disable web/push notifications
user_pref(“dom.webnotifications.enabled”, false);
user_pref(“dom.webnotifications.serviceworker.enabled”, false);
I’m experiencing but may be obliged to set dom.serviceWorkers.enabled to true further on …
Cross-site, again and again. What next?
I appreciate its its all good security wise…
but memory use is creeping up,
firefox.exe used to be 300,000 k average on my old netbook, and with the contentproc –channel rose to 500,000k,, so another channel on top of that will increase it more?
only if you access file:// URIs. But yes, the benefits of a multi process architecture are not possible without memory overhead.
Now I can get rid of stylish since userContent.css works again! Thanks mozilla.
The developer of Cookies-exterminator just answered me about how E10s is not compatible with any addon that monitor local storage. Now I am kind of concerned about FF and privacy addons. Since I know little to nohting about coding, I am not sure if the content of this post has something to do with the developer’s answer. Related or not, Preventing add-ons to access (and delete) local storage such as cookies is a good thing, a bad thing or a mixed bag?
I understand that FF is at a crossroads. If the whole mess with e10s / WebExtensions envolved trading IU addons for performance and stability, it would be hard (like most power users I have a highly customized IU) but I could try. However if privacy or security addons got affected in any shape or form pff… I hope this is just my ignorance talking
I would appreciate some gidance about all of this.
The answer from the developer: https://addons.mozilla.org/es/firefox/addon/cookies-exterminator/reviews/831202/
I copy/paste it here in plain text:
Off JustOff (developer) November 27, 2016
Thanks, this addon is 100% compatible with e10s, but Firefox devs have broken dom-storage2-changed notifications in e10s mode and refuse to fix it – https://bugzilla.mozilla.org/show_bug.cgi?id=1130859
Thus when e10s will be forced on, it will be impossible to monitor local storage neither by this extension nor by Self Destructing Cookies nor by any.
Indeed the developer of Cookies-exterminator explicitly states,
“[…] when e10s will be forced on, it will be impossible to monitor local storage neither by this extension nor by Self Destructing Cookies nor by any.”
I share your wondering, a preoccupation here. Should we face once again the dilemma security (e10) verses privacy (monitoring local storage) that I’d seriously reconsider my priorities not to mention my default browser.
I have no immediate answers to your most legitimate questions, Inolvidable.
@Parker, I’ll take my time to start with the shortest answers :)
– I’ve removed h264ify :: Add-ons for Firefox because it doesn’t seem to perform as well. No idea what happened but this add-on (or equivalent script) used to lower my cpu consumption with html5 videos, and no longer does …
– I knew nothing of Pascal’s “I am sending you a long letter because I don’t have time to write a short one.” but I can confirm that concision may require more time a free-flow-as-it-comes distribution of thoughts : I’m talkative because I don’t have time (energy to be honest) to sumarize and I’d suffer with Twitter and its 140 characters :) In France we say that one shouldn’t write as he speaks especially when he speaks “as a book”! I often, quite… very often… OK: always speak as a book : I’m just in a hurry! I’ll remember Pascal’s word next time I get charged by someone to “get to the point” – LOL!
– Your investigation, description of the e10-LocalStorage problematic did require more than a Tweet because it’s complex. I didn’t understand all details of your explanation/hypothesis but I believe I get enough of the idea to start conceptualizing the processes involved. I lack a general knowledge of computer processes so I learn step by step but that won’t allow a leap to the global approach when the other way round is more obvious and logical : if you know the start your positioning is absolute otherwise it remains relative to what you’ve learned, hence more you learn more you start conceptualizing wider areas … I told you I spoke as a book!
Thanks for sharing your curiosity. We fill our brains with information we don’t always totally understand but once in the box it aggregates with information to come, so it’s always good.
The developer experienced it first hand so he must be correct, but it’s possible that Inolvidable misinterpreted the consequence of having that dom-storage2-changed event not being propagated to the extensions any more due to multi-process.
Based on the name alone and some general experience completely unrelated to Firefox, usually that kind of event would fire when the content adds, modifies or removes storage. A bit of background: Events are fired by code whenever something precise happens. There are other bits of code elsewhere in the program that can register to this event type, i.e. “dom-storage2-changed”, and receive a notification whenever it is triggered. An extension could be such a bit of code. But with e10s, this particular event is not sent outside of the content process for reasons such as performance and memory consumption vs usefulness to propagate the notification outside of the process. I guess the extension sits only in the chrome process and therefore never hears about “dom-storage2-changed” events triggered by content.
But that doesn’t mean the content doesn’t obey general rules such as, is this website allowed to set storage ? And that doesn’t mean either that the extension can’t delete storage, because it uses a different code path for doing so.
The fact that Cookie Controller is aware of local storage being set by content means something is wrong with my supposition. Perhaps “dom-storage2-changed” advertises a slightly different event. The developer must be right that one feature is broken or misbehaving, we just don’t know which one. And seeing how Cookie Controller works just fine, my guess is that it’s not a core privacy feature that’s broken or misbehaving. Perhaps it’s an ease of use one, or an informative one, or an automated convenience thingy, who knows. E.g. if an extension wants to delete storage 5 minutes after it is set, it has to either be notified when storage is set (dom-storage2-changed) so that it knows when 5 minutes are elapsed, or proactively dig into the website storage to grab the required information “manually”. The developer seems fairly certain that there is no work around to the absence of dom-storage2-changed though.
Note: I don’t know Firefox’s code here, that’s just pure supposition based on his comment and event naming habits.
Sorry for the lengthy reply. I think it was scientist&philosopher Blaise Pascal from your country who said “I am sending you a long letter because I don’t have time to write a short one.”, so blame your own people for making up good excuses! :P
PS: If you want to test his extension with e10s you can create a second profile that doesn’t have 74 add-ons :D (You used to have 75, who was thrown out of the party ?? :( )
@Parker, OK. If I understand correctly (you have e10 active on Firefox and the Cookie Monster add-on had “diagnosticated” and treated LocalStorage correctly) and if I deduce correctly as well, this would mean that above-mentioned assertion from the developer of ‘Cookies-exterminator’ add-on is invalidated :
“[…] when e10s will be forced on, it will be impossible to monitor local storage neither by this extension nor by Self Destructing Cookies nor by any.”
I don’t know. This is really an adventure in the dark here, only trying to understand if, yes or no, Firefox’s e10 will block LocalStorage management by the user. In terms of privacy this is essential I guess.
I appreciate your experiencing work. i’ll have to wait for e10 enabled here to test myself as well.
If those extensions have a pane with storage from all sites listed at once, maybe it’s that feature that is being crippled ? e.g. perhaps it’s broken, or perhaps it is not updated in real time when compared to the data in SHIFT-F9, which is per site. No idea.
Thanks for the sample site :)
I double checked and Cookie Controller can properly do everything it’s supposed to do. It notices when local or session storage is set, it can forbid the site to set anything, and it can delete what has been set.
I don’t think Cookie Controller is a WebExtension yet, only e10s-compatible, but the bug report specifically mentions e10s and predates WE’s announcement by 9 months.
If someone wants to test features from Cookies-exterminator and Self Destructing Cookies on an e10s-enabled profile, you could also rely on the “Storage” web developer tool to monitor Session and Local Storage. To open the tool if it’s your first time, press F12, click on the cog wheel on the right of the panel, check the “Storage” checkbox under “Default dev tools”. A “Storage” tab should appear in the list of developer tools and from now on you can access it directly with SHIFT-F9.
@Parker, I have e10 totally disabled here on Firefox 50 (no idea if it would be enabled already considering I have now 74 add-ons of which my Extensions.ini reports 27 in [MultiprocessIncompatibleExtensions] ), so I cannot test at this time.
For those who wish to find a site which puts the user’s data not in a cookie but in LocalStorage (only) here’s a site which does so : http://www.clocktab.com/
It’s a simple clock which you can configure with settings on top of the screen. Do so, close the site, check your cookies and you’ll notice no cookies from that site. return to the site and your settings are still there. Quit Firefox, delete the webappsstore.sqlite which handles LocalStorage, open Firefox and return to the clock site : settings were removed since they were all in the webappsstore.sqlite file…
This is obvious for those who know but may come in handy to others as well as to check if their cookie management add-on (‘Self-Destructing Cookies’, ‘Cookie Monster’ etc.) handles correctly LocalStorage for non-whitelisted sites together with e10 if applicable.
(Also the extension can still delete DOM storage)
Privacy is my #1 reason to use Firefox as well.
In that case the developer is talking about dom-storage2-changed not being transmitted to extensions because of e10s. (So, not because of WebExtensions, that’s refreshing)
The event is not communicated across processes. But just from the name, what’s inaccessible should only be the fact that content added or removed DOM storage. The extension should still be able to allow/disallow DOM storage on a per-site basis as expected. The extension apparently won’t receive a poke when content actually adds or removes storage on its own, but content should still obey permissions as set by the extension.
I don’t know how good or bad these news sound to you. I use Cookie Controller on this e10s-enabled profile and it does (seem to) be able to tell that there is DOM Storage for a given site, I’ll make sure to double check next time I enable cookies on a site that relies on DOM Storage.
Thanks for your answer. Now I know it is a legitimate concern
I wrote my comment in a hurry. It will not win a Nobel Prize but I hope you get the idea