Preface: I am not a Mozilla employee -- I'm a volunteer and don't speak for Mozilla. I also haven't ever written a Firefox addon, though I have contributed to Firefox in the past and roughly understand how addons work.
> I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake
Yeah, dveditz is calling it a mistake (and I have great respect for his opinions -- he's very frank about them and is very thorough when it comes to security matters). I believe he is calling the original design of addons (years ago) to be the mistake, though.
I personally wouldn't call it a mistake though. Not exactly. There are many options, and each would cause significant backlash. The blog post talks of the sandboxing that Chrome and Safari provide; but Chrome's extension API is very limited (I've used it). It's basically a userscript API with a small number of hooks.
A large chunk of Firefox's user base uses Firefox just because of the power of addons. There are many addons that would just not be possible in other browsers. Restricting the addon API would irreplacably break all these addons and many users would leave because their favorite addon just isn't possible anymore.
A proper permission based sandbox that exposes all the original features sounds easy, but isn't. The blog post seems to oversimplify things. The original API was to simply expose all the browser internals to the addons (with a bunch of extra utility methods). Creating a well-structured, sandboxed addon API with the same capabilities is a really, really hard problem. We can't just selectively expose functions -- browser internals were not designed to be secure in such usage, so we need to provide a whole new shim over the internals and take a lot of security things into consideration. This is a lot of work, and cannot be done in a reasonable timeframe. In the meantime, people are getting their browsers hijacked by rogue addons, which is much worse.
Same thing goes for transparency. You need a proper shim to get that, otherwise you need to turn on logging for the whole of the browser -- there's no way to tell if a request originated from a method call by a browser internal, or a method call by an addon (except for a direct request). There might not even always be a clear distinction!
The review experience could be improved; but Mozilla has limited resources and with reviewers mostly being volunteers, this is also very nontrivial.
Sideloading will always be possible unless addons are encrypted with the user's master password. Firefox's source code is public, so the format of the user data dir is public, so anyone can add stuff. Master password encryption for the full data dir is an interesting idea (it might already happen actually; never tried it), but I don't think it will fix the bulk of the problem which has to do with non-security-aware people getting their browsers filled with crap.
Making code signing optional -- It's a tossup here. I was quite annoyed when Chrome did that for their addons since it made it hard for me to share userscripts. But the sad thing is that people will just write instructions to flick that switch. I personally think that we should draw the line there, really[1] -- if we can't stop users from clicking through warningy warnings it's mostly a lost cause. Besides, attacks can always be through direct exe downloads in that case. I personally hope that Mozilla adds the option to bypass this in the future like Chrome did, but I don't think that's going to really solve the larger problem.
I think the best way to handle this would be to use signing as a stopgap measure, and slowly roll out a permission-based sandbox API that has limited functionality but doesn't need signing. It can start out with a Chrome-like API with the most commonly used features, and expand a bit into more APIs until eventually mostly everything is covered. I do believe that it was a mistake to not plan to do this, however note that this solution is still possible.
But overall I find it to be a case of "you can't please everyone" here.
> yes extension signing is great of course, just not when only Mozilla has the power to do so imo
FWIW the reviewers are volunteers, so it's not as closed a situation as it's made out to be. Still not perfect though.
> My comment is just that I hope that servo/browser.html doesn't make the same "mistake"
We don't plan to. No idea about browser.html, but Servo plans to have proper sandboxing and other things. See [2] for a library Patrick wrote to help for this (i nfact its use cases in Servo extend beyond plugin sandboxing). Plugins are on our mind, and sometimes come up during meetings/discussions, though we haven't done anything about them yet (no immediate plans either). Too many other priorities :)
Of course, servo plugins would be for stuff like Flash (ick) which need to interface with the browser engine itself. I'm not sure how browser.html plugins could pan out. It should be possible to provide a sandboxed API via the mozbrowser extensions, but I'm not sure.
> And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p
:D
[1]: See http://inpursuitoflaziness.blogspot.in/2014/04/the-battle-ag... and http://incompleteness.me/blog/2014/04/24/combatting-self-xss... for some work I've done in the past in a similar situation.
[2]: https://github.com/pcwalton/gaol