Slashdot Mirror
Firefox 48 Released With Multi-Process Support, Mandatory Add-On Signing (softpedia.com)
Mozilla on Tuesday released Firefox v48, touted as one of the most important updates the browser has ever received. With the new version, Firefox starts migrating users to using mullti-process threads (e10s, Electrolysis), and it is also the first version to ship with Rust component. In addition, Firefox is now also making add-on signing mandatory. From a Softpedia article: Announced last year, Electrolysis, e10s, or multi-process support is Firefox's ability to process core browser operations separately from the content viewed on a Web page. Multi-process support allows a page to crash without bringing the entire browser down with it and improves the browser's overall performance. e10s rollout will take place in two phases, first in Firefox 48, and it will finish in Firefox 49, set for release on September 13, 2016. Mandatory add-on signing refers to Firefox preventing users from installing any add-ons that have not been approved by Mozilla's testers. This is something similar to what Chrome employs, but Firefox users have been spoiled all these years, always having the capability of installing any add-on they've desired. Rust is a programming language that's a revamped and improved version of C++ but that protects developers from accidentally including dangerous memory bugs in their code. It achieves this by how the language was constructed and by how developers write the code.
Firefox has about 10% market share (several studies collected here), which is hundreds of millions of people.
No changes in the UI. And Classic Theme Restorer still works: https://addons.mozilla.org/en-...
A lot has been written on this, but this is a good and recent analysis: http://www.erahm.org/2016/02/1...
tl;dr: Chrome uses twice as much memory as Firefox on all platforms.
That's probably going to drop a bit it they break all the add-ons.
(Again...)
My interpretation of Mozilla's plans is that they plan to gradually deprecate XUL in order to give time for developers to keep their extensions working with every version of Firefox. So it's not as if they're all going to break overnight. Some will break and won't get fixed if they're not maintained, but that happens on every platform.
The point of signing the extensions is so that some compromised or malicious developer doesn't put malware into an extension's update stream; which can be (and has been) a huge problem, since by default extensions auto-update. So, disallowing unsigned extensions is a security feature. If it turns out Mozilla will be nefarious about it, then you can always recompile Firefox from source with the mandatory signing thing cut out, or go to some fork. Right now I don't think it's a bad move.
Replying to myself, because I realize this isn't entirely accurate: Firefox lets you host your (signed) add-on on your own site if you want. Chrome absolutely requires you to download it from Google servers.
If you're using Firefox 47 or later you can enable e10s yourself. What you read simply means they won't be switching it on for you until FF49.
You can enable e10s by going to about:config and setting browser.tabs.remote.autostart to true. Restart your browser and then visit about:support and look up "Multiprocess Windows" on that page to see if it's enabled. (It might still be disabled if you have one or more add-ons that don't support e10s - if only it would tell you which)
I haven't installed the Firefox 48 update yet, but it may well introduce an option in the Options panel for you to enable multiprocess without having to go through about:config.
What if add-ons don't sign? Can we still "force" them in?
See here: https://wiki.mozilla.org/Add-o...
They could avoid this problem with one level of abstraction, you sign your own extension then they sign that signature.
Mozilla won't blindly countersign extensions because it wants to avoid a situation where you sign an extension and then distribute it to the public without Mozilla having a chance to check it for the most obvious malicious patterns.
The correct solution would be to have a signature checking config setting stored somewhere that is writeable only by an administrator account.
Firefox ESR releases have such a setting. Firefox current lacks this setting because Mozilla wants to avoid a situation where it becomes common to social-engineer users into elevating to change this setting. Home users are more likely to use Firefox current, but they're also less likely to need an in-house private extension. Home users who make their own extensions can use Firefox Developer Edition.
If you really have unsigned add-ons you want to install, there are multiple options for you. See the FAQ entry "What are my options if I want to install unsigned extensions in Firefox?".
https://wiki.mozilla.org/Add-o...
And even that misses the point, I think. Until now, Firefox also let you write and deploy your own unsigned add-on, even if you don't host it anywhere. There are businesses who have created Firefox add-ons specific to their corporate intranet. These add-ons are only used inside the company, they aren't hosted anywhere, no one wants them to be hosted anywhere. And more specifically, no one wants to submit their corporate property / business logic / trade secrets to Mozilla to be blessed with an unnecessary seal of approval.
This is now no longer possible unless you install a nightly FF build on every employee's computer.
Alternately, you can grab the add-on and push it to the add-ons server for signing yourself -- it's all automated. The point of signing is that it allows Mozilla to shut off malicious add-ons when they arise. As mentioned elsewhere, all add-ons hosted on Mozilla's servers have already been signed, so you'd only have to do this if you found some unmaintained add-on lying around elsewhere on the web. To be honest, that sounds kind of fishy, so I'd proceed with caution.
If you don't like it, why don't you fork it
It's called Pale Moon. You should check it out :)
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
While what you say is true on some level - a compromised process can dick with your system, including other processes, just fine - you're missing the point of having a multi-process browser for security. The vast majority of what a browser does requires almost no access to the rest of the computer. You can have one container process that runs with user privileges and implements the few things the browser needs to be able to do to the system at large (save downloaded files, etc.) in a very secure manner, and is also responsible for launching sandboxed, low-privilege sub-processes that do the dangerous work of a browser (parsing web server responses, running plugins, executing javascript, etc.). If these sandboxed processes are compromised, the attacker can still fuck with your browser... but they can't get out into the rest of your system.
This is how Chrome and IE have worked for years (though Chrome's sandbox is a lot tighter than IE's). It's not just about stability/reliability, there's also a very real element of security here. Chrome's sandboxed render processes are so underprivileged that there's practically nothing a compromised one can do (to the rest of the computer) except try to attack its full-user-privilege container / broker process (through the IPC channels that let it do things like say "Please ask the user where they want to save this downloaded file"), but that is a very small attack surface compared to most of what a browser does, and the trusted process can have that attack surface very well-hardened.
There's no place I could be, since I've found Serenity...