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.

Comments

Because dangerous memory bugs should be intentiona

[davidwr]

accidentally including dangerous memory bugs in their code

Good, now I can be assured that all of my dangerous memory bugs in my code are intentional.

Mozilla's starting to get back in shape

[LichtSpektren]

I've been on Nightly for awhile now and the performance with e10s is now almost as good as Chrome's. Firefox Hello is thankfully going to get axed in a future release, and if Mozilla continues to fine-tune the performance a bit more and rips out Pocket, I think Firefox will be back on top.

Re:Mozilla's starting to get back in shape

[chefmonkey]

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.

Re: Mozilla's starting to get back in shape

[cfalcon]

> No per tab processes means no real sandboxing at the kernel level.

This change seems to be about stability more than security. Remember, if a browser process is owned, it is still running with all the permissions of the browser process. It can certainly go dick with other processes running, such as other instances of the browser, your email client, etc. But a crashed process that runs everything with threads is, everything is crashed, while if different tabs are there own processes, you lose that tab.

Re:can we please

[LichtSpektren]

Firefox has about 10% market share (several studies collected here), which is hundreds of millions of people.

You must be new here

[sjbe]

Can we please stop posting about minor, useless OSS software releases? It's not like anyone uses this piece of shit anymore.

Really? Wow and here I thought I was using Firefox to type this. Thanks for letting me know that I'm not really using the browser I think I am.

Re:How much more Chrome-like is it?

[LichtSpektren]

No changes in the UI. And Classic Theme Restorer still works: https://addons.mozilla.org/en-...

Multi-process not available for most users?

[trawg]

I was kind of excited by this so updated immediately instead of my usual process of waiting a couple days.

While it was updating I did another unsual thing - clicked through to the article - where I read the following:

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.

Firefox with multi-process support will first reach 1 percent of the users who don't have any add-ons installed in their browser, and in ten days' time, Mozilla will activate e10s for 50 percent of the same users.

Full e10s support for Firefox instances using extensions or running on older versions of Windows will be available in the fall, during the second rollout phase scheduled for Firefox 49.

So, at a glance (and from what I can see from my now-updated install), multi-process is not /really/ included in this release except in certain cases like users who don't have any add-ons.

Re:Multi-process not available for most users?

[Barefoot Monkey]

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.

Re:can we please

[Joce640k]

That's probably going to drop a bit it they break all the add-ons.

(Again...)

for a minute there i thought i had freedom.

[nimbius]

Firefox users have been spoiled all these years, always having the capability of installing any add-on they've desired.

Yes how pampered a life I've led in my fantasy-land where the computer performs in accordance with my instruction. oh i was a fool to think personal computing would remain my own personal fucking shangri-la. Thank god Mozilla has come to the rescue and spirited me away from this dubotcherous land of sodom called personal computing. But hey, you know, whatever it takes for your corporate masters to reign in ad blocking, cookie whitelisting, and script blocking. I just cant wait to watch another taylor swift autoplay video.

Re:for a minute there i thought i had freedom.

[LichtSpektren]

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.

Re:for a minute there i thought i had freedom.

[Barefoot Monkey]

I don't find it hypocritical at all. If I want to use addon that isn't signed I can simply send it to Mozilla to be signed. It's quick and easy, and has no cost. I can do this for as many addons as I want, whether the addons are my own creation or somebody else's. Alternatively, I can use the developer edition, or a nightly, or the current ESR version of Firefox where this ceases to be an issue at all. With Windows 10 I have none of those options - getting a driver signed by Microsoft is prohibitive, so there's simply nothing I can do. Being completely different situations with nothing more than a superficial similarity, having a different reaction for each is quite reasonable.

Re:can we please

[LichtSpektren]

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.

Re:Whoops

[chefmonkey]

Ah, I follow your logic: "Whoa. Firefox is now better in performance and memory footprint than Chrome. But it has THE EXACT SAME ADD-ON SIGNING POLICY AS CHROME, so... you know... fuck it. I'll stay on the worse browser."

Re:Whoops

[chefmonkey]

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.

Re:can we please

[LichtSpektren]

What if add-ons don't sign? Can we still "force" them in?

See here: https://wiki.mozilla.org/Add-o...

Firefox ESR allows turning it off

[tepples]

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.

Re:mandatory "freedom" not to do as "desired"?

[NotInHere]

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...

Re:can we please

[chefmonkey]

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.

Re:mandatory "freedom" not to do as "desired"?

[TangoMargarine]

If you don't like it, why don't you fork it

It's called Pale Moon. You should check it out :)

Thus, sandboxing

[cbhacking]

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.