[the8472]

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.

[brighteyes]

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.

[simonster]

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.

[mook]

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

[the8472]

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

[brighteyes]

Of course I agree, it had upsides as well.

But you can't add such a switch - if it's there, malware can access it. A switch might prevent other problems, but not that main one.

[the8472]

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

[brighteyes]

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.