"BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello.
Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install."
And a more serious comment from a developer of DownThemAll!:
"I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention…
But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.
To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer."
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.
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.
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.
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.
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.
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.
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 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.
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.
> The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions.
This is very bad news for me. I'm a power user that prefers the balance of new features/chance of breakage that the Beta channel offers and I take full responsibility for the addons I install and the security decisions I make. I don't need Mozilla to be "defending" me in this case.
«The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions»
So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
The thing is, I'm not a web developer and I don't think I should be forced to use the Developer Edition just so I can remain in charge of what I install in my browser. Now that I'm writing this it occurs to me that after this change it's not really my browser anymore, is it?
I hear you on the control thing. You mention you are a power user above so my two cents is that likely puts you outside of the user base Mozilla covets. In the last couple years, the words "Firefox" and "power user" went hand-and-hand but I'd wager Mozilla would trade customer bases with Google in a heartbeat.
FWIW, the Developer Edition feels pretty lean and mean. I haven't tried since I am a web developer, but it looks like you can remove most or all of the parts that make it web developer-y if you are so inclined.
"You mention you are a power user above so my two cents is that likely puts you outside of the user base Mozilla covets."
Mozilla's business model needs users who can't figure out how to turn off Yahoo search. That pays for their new Firefox offices on the waterfront in San Francisco.[1]
I've ran Nightly and Aurora (which is now Developer Edition) for a while but extensions/themes broke more often than I'd have liked because there was too little time for extension devs to update their extensions in case incompatible changes were introduced.
I don't know if they'll offer each permutation of all those possibilities. I don't see why not though, it's just a little more build time.
In any case, if the specific combination of features you want is missing, the option to build from source is always there. (At least on Linux, building Firefox is also pretty easy.)
That doesn't sound like an option that will fork for my use-case - I manage a bunch of Windows machines; if we upgrade Firefox to "Noname Browser" with a different icon, the users will be confused and unable to find it.
i tried running firefox developer for a while and since it's based on the alpha code, it broke all my extensions on each update. so yeah, i'm a power user (i run 3 custom extensions that i wrote, pentadactyl and dotjs) but it's not feasible for me to keep running developer.
Agree. And as someone who's been running the Developer Edition as his primary browser for some time, I'm happy to report that it has been by enlarge reasonably stable--even though I've had e10s enabled.
This was true for me until the most recent major version (42.x) that broke the Tree Style Tabs extension. My whole browsing workflow depends heavily on that extension, so I had to revert to using the stable version for now.
https://github.com/piroor/treestyletab master works fine; you just have to clone it and replace extensions/treestyletab@piro.sakura.ne.jp in your profile.
I also used to rely pretty heavily on Tree Style Tabs. With the release of 42 I've been using tab groups (cmd+shift+e) with pretty satisfactory results.
e: cmd+shift+e assumes a Mac. Not sure what other systems use.
Hmm, i'll have to try that thanks for the heads up.
Losing tree style tabs in 42 has made me nervous, it was the primary reason I love firefox. Without that most of the why in using firefox goes away for me.
As I understand, the author's opinion is that Adobe Reader is more secure than pdf.js. I'm not sure I would trust them with maintaining a secure browser in light of that.
Their monetization model is also questionable (I understand it injects ads / referral links).
Never heard of it, quick scan of the page seems to indicate that it is windows/linux only though? I did a quick look at the download page and didn't see an osx build.
That is overall fine but I like to keep my browsers portable across all of my primary operating systems.
The Developer Edition won't help much if plugins that don't fit the new API are abandoned, which strikes me as a likely occurrence. I don't think many will bother to maintain non-developer-oriented plugins just for those using the Developer Edition.
One reason for add-on signing is that there's a major attack on Firefox using stolen add-on IDs to insert malware. This started in early 2015, and one of my add-ons has about one-third bogus versions out there. They all have different random version numbers, typically above 1000. Those are about to get flushed out of the ecosystem.
Whether add-on signing is part of a power trip at Mozilla to enforce a walled garden with Mozilla-favorable policies remains to be seen. When Mozilla blocks an add-on which disables Pocket or Sync or Hello, we'll know that AMO has turned to the dark side.
That could presumably be solved by allowing developers to sign their own add-ons and tying the ID to the key they used to sign it - it doesn't require a centralised signing system of the kind Mozilla introduced.
Fully agree. On Mac OS X you can still run unsigned apps, but you have to be savvy enough to do so. Mozilla should at the very least adopt such an approach.
A big problem for a lot of Firefox users is addons that are side-loaded into a profile. Like when you download some junk and it comes with an installer that injects an addon into your profile. This is a good expose on what even a seemingly legitimate site like download.com does: http://www.howtogeek.com/198622/heres-what-happens-when-you-... (and several of the malware examples in that article are side-loaded addons).
Unfortunately hoops aren't enough to fix this problem, because hoops generally involve some flag that you've gone through the hoop, and the installer can easily fake that.
Couldn't those installers patch Firefox to remove the signing requirement? Or, if they don't get sufficient privileges to modify the executable, patch the user's Firefox process in memory?
Yeah, this might end up being just a salvo in a longer battle. But maybe part of the problem is that some of these malware authors are lying to themselves and believe they are just grayhat hackers, and once you start patching executables it becomes a bit clearer you are a blackhat. So far download.com isn't distributing actual rootkits. They could of course. And yet still they probably won't.
Relatedly I did notice when putting my own addon through the signing process that there was a checkbox specifically for sideloaded addons, with the implication that the checks would be even more stringent. I'm not sure if that's enforced or not, or how.
I don’t see how antivirus software completely failing to protect its users from “easy” attacks (rogue extension drops) should inspire any confidence they can protect you from more sophisticated attacks. Oh yeah this gun is useless now, but wait till they roll in with tanks!
Never mind the entire idea of antivirus software is completely ridiculous from security PoV and basically a scam to have people pay for a false sense of security.
no, because then any malware would immediately install that extension first, and then flip the about:config bit on the filesystem, and then install their extension, and then you're right back where you were before signing.
Allow enterprise users to generate firefox executables with additional trusted certificates and distribute that on their machines instead of the original?
do you think people will do that, or just give up and use another browser?
then with everyone developing exclusively in chrome, any bug in firefox will be ignored as everyone adds a note to their support staff to 'just tell users to use chrome'
So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension ecosystem is one of the highlights of Firefox.
I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.
Exactly. Once all your front-end is in html, including the part that manages tabs, nothing prevent a WebExtension to implement TreeStyleTabs.
Also note that the same extension support is landing in Firefox OS (we are working on the missing apis), and will let you install the same extensions everywhere.
I understand people mourning xpcom access. You can do fun things with that, but I've also seen my share of horrors when I was reviewing add-ons (let's override the http protocol handler, what could go wrong!).
>And yes, I know that you will be consulting with addon authors about api functionality, but i guarantee tons of stuff is still going to be lost...
Not to mention all the potential extensions that nobody has thought up yet that will no longer be possible and probably never will be. The ability to experiment and try out new ideas that nobody had thought of before is what gave us a lot of the extensions people use today. An API that tried to imagine all the possible features people might need and then locked down everything else would have prevented a bunch of the extensions that are popular today.
This problem exists for the web in general though (being a tightly controlled sandbox where only features agreed on by all the vendors are allowed). So I think Mozilla is probably institutionally incapable of understanding the problem, since it undermines the central mission of the entire organisation - which is to convert all end user software into software that runs in a vendor controlled sandbox. People who appreciate the creative cost of tightly controlled sandboxes probably wouldn't go to work for Mozilla.
Except for people losing interest in developing for the platform due to all the API churn. By the time all this lands no one will care to implement TreeStyleTabs.
Seeing the vibrant plugin ecosystem revolving around Atom makes me cautiously optimistic for Firefox's future prospects. Implementing the entire interface and plugin system in standard Web technologies will also make plugin development more welcoming to web developers who found XUL development too archaic.
In fact, I'm one of those developers, and the first thing I'd do in post-XUL Firefox would be try to create a Tree Style Tabs alternative.
Atom was a new program though so people started from scratch and had no pre-existing code-bases (unless you count ST3 ports), whereas here Mozilla's change would drive many developers away because they would now need to rewrite addons entirely for the new API or if the API doesn't support what their addon did they're SOL. It seems like a bad way to go about it, they shouldn't deprecate the API till there's feature parity in the new API.
Feature parity is a meaningless term. Extensions currently have access to the entirety of Firefox internals. That huge internal surface couldn't be stabilised without stopping development entirely.
Couldn't that internal surface be gradually phased out? Make an API that gives you full access to it, then piece-by-piece replace the full access with safer replacements?
I think I would introduce the new APIs through Jetpack (which has a formal separation between the extension proper and the APIs it uses, but ships the implementation for both). Once an extension uses only stabilised APIs (APIs taken from chromium could stabilise first, assuming there aren't too many abstraction leaks), label it as Forward-Compatible on AMO (similar to restartless addons). Help the top extensions port, and start breaking internal APIs more aggressively. Maybe start measuring the latency introduced by cross-process wrappers (assuming the extension that uses them can be determined at runtime), and warn about extensions that use them. The perception that Firefox is slow largely comes from that kind of compatibility hack, and people would probably make an informed choice to speed up their browser.
The trouble is that they aren't planning to wait to switch to browser.html. They're deprecating XUL extensions now, without switching to an HTML-based UI first.
Disabling unsigned extensions without any opt-in is a terrible decision. Putting up barriers to entry for addon developers in a browser that survives primarily based on the addon ecosystem is suicidal. Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager. I really don't care about the rest of these changes, but they need to rethink their stance on unsigned extensions.
One possible workaround would be to provide a way to add keys from which you would accept extensions. Then as part of the extension development process, you could sign your extension with your key when you are ready to install it.
If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
No, indeed I do hope that security is the primary thing they are concerned about.
But it is possible they have other motivations (like control). I hope that is not the case, but I think it would be foolish to not even consider the possibility.
A lot of people in this very thread are complaining because the add-ons are the only reason they use Firefox in the first place. So basically, citing this thread.
> Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager.
Why not use the stable versions which allow unsigned extensions?
One of the maintainers already committed to flipping the switch on the mailing list. The reasoning given was that extension signing was a security feature and it is better to trust Mozilla than to trust an old add-on whose developer did not bother to update so that it could be signed.
>...than to trust an old add-on whose developer did not bother to update so that it could be signed.
Yea, those pesky deceased developers. When will they stop being so lazy and update their code?
I don't understand how technically savvy people are capable of reasoning around the walled garden approach. It isn't their place to tell me who I should trust.
Long time coming, the FF extensions system has been a security risk and a development burden for years. Yes, it offered unique advantages, at a significant cost though.
Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that.
You can't bury your head in the sand and expect the problem to go away or wipe your hands of it and insist users should know better. The fact of the matter is, browser extensions are one of the most common malware attack vectors nowadays and vendors should be concerned about that.
It's going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can't let diehards force you to drown with the ship. They'll live and find a way. It's regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.
Chrome doesn't sign extensions though, and getting them listed isn't anything more specific then a 5$ charge—how can you judge whether its "hardly a dealbreaking change" based on that?
Each vendor is moving at their own pace and in their own way, but the endgame is clear. With that comment, I was also referring to the depreciation of XUL more than the signing requirement.
No, its absolutely not. The new firefox addon signing requirements are a hundred percent more restrictive then the requirements to get listed on the chrome store.
Wrong. Chrome IS more restrictive, they don't allow non-Chrome Store add-ons AT all. With Mozilla's implementation all non-AMO add-ons need to do is go through the automated signing process. Which only takes a couple of minutes, at most.
> they don't allow non-Chrome Store add-ons AT all
This is wrong. You can drag and drop an extension into the Chrome extensions folder (or enable the developer mode in the extensions page) to install any extension in Chrome.
> Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that.
Fewer people might need the flexibility, but Mozilla effectively dictating the browser experience still seems excessive. Comparing it to Windows, it's almost akin to Microsoft requiring signatures on all software that can be installed.
> Comparing it to Windows, it's almost akin to Microsoft requiring signatures on all software that can be installed.
The equivalent of a Windows app is a Web app. Nobody is requiring signatures on all Web pages that you visit.
A better analogy would be Windows requiring signatures on all kernel-mode drivers that you install. Which, in fact, it does, and has for 8 years now, starting with 64-bit Windows Vista.
Requiring code-signing is fairly controversial by itself, but even still, comparing add-ons to drivers isn't really accurate. For monolithic systems, drivers imply kernel mode, which implies Ring-O privileges, which also implies root access. An add-on is restricted to user privileges or less.
1. If the browser is an operating system (which it is) then the browser itself is naturally "ring 0". An example of where this matters is the fact that Hacker News can't access your bank account, while addons can. It is hard to imagine anything more security-sensitive than your bank account.
2. "An add-on is restricted to user privileges or less" doesn't mean much for the Firefox addons that are affected by this—they run with full user privileges, which for many attacks (malware, spying, TLS interception, keylogging, etc.) is close enough to ring 0 as to make no difference.
There are security vulnerabilities, I don't think anyone in their right mind can deny that. Ultimately they're no different than being able to install software on your computer though. So, assuming reading your bank account were a user-level privilege, nothing prevents software you install from accessing it. As long as you can install software, you can install malicious software.
Theoretically, gpg could be capturing my key password. It couldn't capture other peoples' key passwords though.
Said add-ons can also access your entire browsing history, listen to you type in your passwords to your online banking account, get access to your emails and hence online identities, and generally know everything there is to know about you in a very short amount of time and code.
I'd argue the threat here is that malicious extensions at this level can be done by somebody with little to no experience, compared to kernel extensions which actually require some modicum of skill.
Requiring signing is a recognition of the fact we are increasingly moving our lives online, and hence into the browser.
Add-ons can do malicious things, requiring signatures doesn't stop that and it could even give a false sense of security. However, I think the major concern with signatures is the authority aspect.
You're absolutely right, as indeed pcwalton says above - but it's a step in the right direction from "let anybody have access to anything they feel like".
Standardizing the basic means of browser extension is something that I've been eagerly awaiting ever since Microsoft announced that Edge will support both Firefox (Jetpack) extensions and Chrome extensions. But how will future versions of Firefox handle the extensions that just can't exist in Chrome, such as NoScript and Tree Style Tabs?
EDIT: I'm also excited at the idea that this could give Servo a running start at an extensions story, since Servo will never in a million years support XUL or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there anyway.
"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. 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."
So to all extension developers leaning on the current permissive features or XUL/XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year.
Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html/css/js (thanks to nwah1 for pointing that out).
As a decade+ Firefox user I think this is fabulous news, not because it'll be easier for Chrome exts to come to Firefox, but because the old extension 'API' was a heap of junk and made it trivial for third parties to really gum up Firefox internals. Also huge kudos to Mozilla for not bikeshedding some new/slightly incompatible API, which I'm not sure Google would have been capable of. :)
Chrome's API is much better designed, I suppose, because they had the first chance in 15 years to actually sit down and design a modern/safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.
We at Opera have called on for a single (or at leat a shared) API for making browser extensions, which I think will benefit the developer community immensely (instead of making one set for each browser).
It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status.
Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does:
- Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets.
- Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps.
- Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway.
- Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB.
- Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!)
I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions.
I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.
The customization element was nice, but I feel like most of these issues will be addressed by future developments.
With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?"
While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.
Firefox implemented file system access for extensions long before Chrome existed. They're just taking it away now.
If Mozilla wanted to go the standardized API route, they could have done that initially instead of introducing the Add-on SDK (Jetpack). IMO, that would have made more sense.
And if they wanted to, Mozilla could still allow XUL/XPCOM add-ons to coexist with WebExtensions add-ons until Firefox itself stops using XUL/XPCOM (which will most likely happen when Servo is ready for prime time). And by that time, maybe they could standardize js-ctypes as part of WebExtensions, which would address the middle 3 issues on my list.
That's the goal. "Web apps" are always going to be 2nd class apps, because it is insanity to allow the spoofing of the native UI. The security sandbox will always have significant restrictions, by definition. If you don't like this, write a native app instead.
> Reading/writing arbitrary files to the file system.
Are you trying to open up a massive security hole? Filesystem access is banned on purpose. Writing an extension in a way that guarantees arbitrary filesystem access cannot be exploited through some complex interaction with the rest of the browser environment is probably impossible (see: the Halting Problem). It would certainly fail in practice.
Seriously, stop treating the browser as the OS+desktop. If your platform doesn't offer any true "native" access that has the features you want, then take that up with the platform's vendor.
> Are you trying to open up a massive security hole?
Firefox extensions run in a privileged context. They essentially are not really different from components of firefox itself.
Firefox components can obviously access the filesystem.
So can extensions.
An extension in itself is not any more a security hole than firefox itself.
> Seriously, stop treating the browser as the OS+desktop.
While I agree with you there, what's needed to get to that point would be browsers actually talking to the native environment more. Pipes, sockets, filesystem access (chroot-style) even limited process launch capabilities.
If web or extension APIs allowed that it would be far easier to integrate with native instead of having to build it straight into the browser.
But that just addresses the "app" kind of extension.
Other extensions instead customize the web browsing experience. For example if you have a file form and want to do automation (filling in the right files?) then you already need access to the file system. This has nothing to do with native apps and yet needs access to native resources.
> Firefox components can obviously access the filesystem.
Which is a hole that should be plugged.
Beyond its home subdirectory and a tmpfs Downloads location an Internet-connected browser should be prevented from writing anywhere.
Bonus points for preventing read access to non-runtume locations too. Not only prevent bad data from coming in but prevent good data from being sucked out.
Sandboxing extensions' access to the file system would be acceptable. We could work with that, just as OS X app developers have. But Chrome and the current WebExtensions API don't allow extensions any file system access beyond what webpages get.
Well, this is all terrible. They mention having to use the nightly or developers releases instead of their walled garden versions. But both of those are unstable and very crashy. And how likely are they to keep the unbranded version up and updated as time goes on?
And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It's why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.
I don't have sufficient command of the English language to fully express how strongly I disagree with this. I have an extension which I made for Chrome and Firefox. The Chrome version basically consists of a single Javascript file, and a tiny json file with about 15 entries. I spent perhaps an hour to learn the basics from scratch. I don't have space here to describe all the crap I went through to get the same extension working on Firefox - and I was using their easy API. The Firefox extension development process is one of the most confusing, complicated, experiences I've ever had on a computer. Good riddance!
Nobody said Firefox was easy to develop add-ons for, the GP said "The add-ons are what makes firefox good". The add-on API itself might be arcane and confusing and horrible, but you basically have access to everything. Since the entire browser is written in XUL, add-ons can override and recreate anything at any level.
The end result is that Firefox users have a much wider array of add-ons to use (despite the add-on system being somewhat crazy by today's standards).
Well I disagree with him/her there too. What made Firefox good was that it was a lightweight, simple browser, that rendered content exactly the same on three OSes. It's still my main browser, but that's only because I want less Google in my life, and because Safari aspires to be a motion picture instead of a tool. But I haven't considered Firefox actually "good" since probably 2010, or whenever it was that they dumped a bucket of LSD on the interface. Since then it's become a bloated mess.
If someone wants to add toolbars and skins, etc, I suppose the new API would disappoint. But it's hard for me to relate, because I'm not that adventurous. The ones I really care about, generally AdBlock and privacy extensions, just interact with web content, not chrome. That sort of add-on is just as available on Google Chrome.
New, simpler addon APIs are fine, but not when they replace more powerful ones.
I guess that it's inevitable that Firefox has creeped from a "power user browser" to a dumbed-down maintstream one. I guess it's time to start looking for a new power-user browser.
> I guess that it's inevitable that Firefox has creeped from a "power user browser"
Think about that statement in the context of Firefox's history. It's totally backwards. Firefox was not supposed to be a power user's browser. That was Netscape. Firefox was supposed to be a simple browser. And once upon a time, that's exactly what it was.
The mission of the Phoenix browser was to be end user focused. This did involve jettisoning a bunch of complexity that was there for the Mozilla suite or whatever else anybody with commit privileges had thought of, but simplicity wasn't an overriding goal.
That's not exactly how I remember its origin story, nor how I remember it being written about when it rode its first crest of popularity. The last thing people talked about was Firefox being a tool for power users. It was "Tell your friends and relatives to switch to Firefox! Finally MSIE has worthy competition! Look at how uncluttered and easy to use it is!" I don't recall anyone talking about flexibility, or advanced features, unless they were tied into its ability to render webpages without a bunch a glitches.
Here's the introduction they gave it over at boingboing.net:
"
Firefox, an Internet Explorer killer, has gone 1.0
By Cory Doctorow at 3:46 am Tue, Nov 9, 2004
Firefox, the finest, most secure Web browser ever created for average-user applications, went 1.0 today. You can download it below, toss out Internet Explorer, and be relatively assured that you computer won't be compromised due to Microsoft's bad design decisions and lax security maintenance."
That sounds pretty compatible with what I wrote. End user and average user mean about the same thing, and my use of "overriding" was pretty intentional.
And convenience comes with lack of power. Some extensions need access to more powerful features to do their thing. It would make more sense to just keep both.
As someone who has written several extensions across all the different browsers (IE COM Interop FTW!!!) over the last few years, Chrome's dev experience is by far the best in my humble opinion.
Firefox's experience was hamstrung by having to learn XUL and a new and different set of tools and way of doing things. Their approval process and packaging scheme was surprisingly not as streamlined as I would have expected from them either. Chrome's experience is fairly standard and intuitive HTML, JS, and JSON interactions. In most cases it really shouldn't take too long for someone to port or migrate an old Firefox plugin to the new format.
Extensions are probably the least reason why i use Firefox. The few extensions i use are also available in Chrome. Other reasons to use Firefox (at least for me):
- It's free software.
- Uses less RAM than Chrome (when having many tabs open).
- The address bar is awesome; i can always find previous pages i visited from there without having to google them.
- It's backed up by a non-profit organization, instead of an advertisement company.
It's probably better to compare Firefox to Chromium which is as free as Firefox. I think the RAM and address bar comparisons could be addressed by extensions in Chromium. So really you are left with the last point about funding, but Mozilla gets its money somehow and it's mostly not coming from charitable donations.
That's become my default response to Mozilla news. It reminds me a lot of what I started going through maybe 6 years ago or so with GNOME. 'Wait, what?' 'Why?' 'You've got to be kidding me!'
Why do you think they are getting rid of the community? They are (presumably) making life easier for cross browser extension developers, and the first big deprecation is about 16 months away.
We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
> Why do you think they are getting rid of the community?
They're getting rind of those people who are willing to dive deep into the internals do develop something that nobody thought of before (if they did there would be high-level APIs for it).
I don't think there is anything to worry about there. The blogpost says that they are adding things to the API to allow popular addons to work in the new model, and those addons certainly count.
I think the point of the comment above that is it's precisely because of the extensive access that such useful addons could be made in the first place and subsequently become popular.
The default behavior with firefox is honestly borderline unusable for me. I can understand the need for a better add-on API, but I think limiting capabilities will probably end up driving a fork.
We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.
Seems like there's still a lot of power available, if you really want to dive in.
They're completely broken. Vimperator has an issue on github about getting e10s support but it looks like with these changes it doesn't matter Firefox will permanently break or cripple them.
Mozilla has an add-on review process in place. So you probably wouldn't get a new addon approved that relies on those APIs.
And with enforced signature signing you can't even distribute it to users yourself.
So effectively it will restrict extension-development to a whitelist of APIs. Everything else will be verboten, maybe with varying degrees of enforcement.
It certainly doesn't sounds like an open system to me.
Have you used it? After I heard about the changes coming down the line in 41 a week or so back I immediately downloaded it and started configuring it to be my new main browser. The only problem was that it crashed constantly. It's just anecdotal but my personal experience backs up what I've said here.
Well, to give a counter-anecdote: I've been using nightly for years and only experience severe problems maybe a handful times per year, the rest of the time it works fine.
FYI, i have used Aurora/DevEdition almost exclusively (outside of testing) on at least a dozen different Windows and OS X machines ever since the Aurora channel was created and i have never once had a serious problem. Occasionally i find little visual glitches or whatever, but it rarely ever crashes and i never get data loss or anything severe like that.
I switched to Firefox in part because XUL-based extensions can heavily customize the user interface. Things like Tile Tabs, Tab Mix Plus, and other extensions have been extremely useful to me. Despite my dislike of XUL as a language, I'm sad to see XUL extensions go; I suspect that WebExtensions will, like Google Chrome extensions, be much more limited.
In fact, I had always hoped that FF would move in the opposite direction, and split itself apart into a bundle of extensions, so that even more customization could be possible.
I've also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla's approval.
Are there any plans to maintain a fork of Firefox that will not include these changes?
I don't really know why, but I have some small optimism that Servo might enable such a browser. The only other candidate browser engine is Webkit, which is already too huge to be part of a small Unixy browser. Maybe Servo, as a project that people are actively hacking on, might work.
I think that any browser that can render the modern Web will necessarily be too big to really be called "Unixy". But Servo is an exceptionally modular browser engine, as is obvious upon building it. We're up to 150 crate dependencies and counting, most of which are independent of the browser engine.
One option I have found is surf (http://surf.suckless.org/), but it seems too limited for me to use it on a regular basis. Really, what I'd like is a browser in which almost all components (tabs, bookmarks, etc.) are just extensions around a simple (Servo-based?) core.
Servo is awesome, by the way -- I look forward to seeing what comes next!
None of the major browsers are really modular in the Unix way. There are some research browsers that are much more modular, though, like IBOS and Servo,
And this is how Google killed Firefox. Why do people use Firefox? For extensions. What breaks extensions, frequent updates and extension API changes.
Google managed to suck Mozilla into frequent releases and now extension API changes that make Firefox yet another generic easy to substitute browser. Wow, just wow.
Frequent releases aren't a bad thing, per se. Although, huge API changes like this, without a valid plan for supporting existing ones a large community depends on seems like a disaster in the making.
The impression I get is that Mozilla wants to be more involved in the user experience around their codebase, but personally I preferred firefox's lack of involvement. I think the UI is poorly designed and getting worse, but as long as it was easy to modify, it wasn't an issue. The real value in firefox for me is gecko. Most other things largely get in the way, and it seems like that's what's becoming the focus.
I can understand the need for a better designed add-on API, but there should probably be a non-compulsory reason for people to switch.
I use Firefox because it's open and more pro-user than Google is. And Mozilla's work on Rust is incredibly important too. (Rust manages to accomplish what decades of effort and loads of money on C analyzers and mitigation techniques fail to.) So it's important, ethically, to support Firefox.
"we will require all extensions to be validated and signed by Mozilla starting in Firefox 41"
I hope there is an "opt out" option to this for people who know what they are doing. I understand the reasoning behind it, but what about an extension I write just for myself that I don't wish to share with Mozilla? I don't particularly like having that option taken from me.
Yeah, I know, I could edit the source and work around it -- but based on past attempts to just build firefox, that could be a real pain.
It doesn't mention addon permissions, which I would assume is something WebExtensions has, since that's how addons work in chrome. At least I hope this is the case, lack of permissions in firefox addons is a little scary, and probably one of the reasons I have the minimum addons installed
I'm much more relaxed using Firefox add-ons from addons.mozilla.org than Chrome extensions because Mozilla has actual people making sure that the add-ons don't do any nefarious things. (Or at least forces them to disclose that properly.) On the other hand, getting hidden adware or password keyloggers into the Chrome store is no problem at all.
I was under the impression that add-ons like ublock / umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible anymore?
I think those will work fine, my worry is that significant part of extensions that I use will no longer be available. I don't believe their functionality can be replaced with web extensions.
Here are some:
- FireGestures (mouse gestures)
- NoScript (it can do much more than the Chrome equivalent)
- SecureLogin (wand-like behavior from Opera; basically instead filling login and password after page loads it logs you in after pressing a button)
- Tab Scope (thumbnail of webpage when you hover over a tab)
- Tree Style Tabs (it does what the name says)
- Informational Tab (this I can live without, but I like it, it puts progress bar in the tab which looks nice)
This news sucks, first Opera 12 was discontinued and replaced with Chrome with different skin. I finally moved to FF and used multiple extensions to get some of Opera functionality back and now those are going away.
That's the first thought that came to my mind as well.
Addons like Fire Gestures and Easy Dragtogo are what keep me on Firefox. Chrome can't implement those apparently, and now it seems that support for them will be deprecated too.
thanks for the clarification, I haven't looked at add-ons for other browsers for quite a while, and at the time I remember discussions about adblock not being possible to be done anywhere else like in FF due to the add-on model, glad to see this does not seem to be the case anymore
- adblock pioneered on firefox
- deemed useful
- chrome implements necessary APIs
- can finally be implemented on chrome too
For that to work you first need a permissive enviornment where the addon developers can think outside the box and do things not covered by the standard APIs.
Just like you can, as ultima ratio, write kernel modules if your system has no other way to support whatever you need to be do.
that was what I thought as well, however I went to the umatrix github page and if you look at the top it links this page[1] that discusses how umatrix needs permission to disable prefetching so no network connections are made for blocked sites, which seems to imply it can do the pre-emptive blocking as opposed to just hiding of elements.
I am wondering though now if I am mixing things up in my brain and the issues were with safari add-ons as opposed to chrome/chromium: there is no umatrix for safari[2] that I can see, ublock seems available but not ublock origin, but I am not sure if ublock on safari just hides or actually pre-emptively blocks.
> umatrix needs permission to disable prefetching so no network connections are made for blocked sites
Disabling pre-fetching is to prevent a TCP connection to be established at all, and this is something that needs to be also dealt with in Firefox -- it's not just a Chromium thing. This ensures that no TCP connection is established before it has been decided whether a network request must be blocked or not.
Chromium used to not be able to support the pre-emptive blocking of network requests, but that has been remediated in 2012 with its webRequest API in Chrome 17.
Which brings us back to the point that one cannot develop any new, unforseen kind of extension unless you either have the option to directly interface with the browser's internals or somehow get that API included in the browser.
Great news.
With the current system, firefox's stability, upgrade compatibility and performance were entirely dependent on every author of every extension I use being sufficiently careful. It meant a lot of periodic purges, housekeeping, and reduced trust. I'm sure the overhead helped users move to chrome, despite Firefox's vanilla install being lighter. Reducing the API surface was a necessity.
Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.
> It meant a lot of periodic purges, housekeeping, and reduced trust.
> I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases,
For me those tradeoffs are worth it. Sometimes it means installing a beta builds of an addon or nagging its developer on github or even finding a replacement. But that's still better than not having the addons at all because the APIs simply make it impossible to have them in the first place.
If mozilla separated addons into "uses stable APIs only" and "might break at any time, we may even turn them off if they cause to many crashes" that might allow users to choose which kind of model they want to follow.
XPCOM has support for stable, versioned APIs, but no one cared about using that subset since the rest was also available; it stagnated and the supposedly unstable APIs ended up bearing the compatibility burden. Now there will only be a supported subset, and the trickier stuff will require getting a patch accepted instead of monkey-patching and letting the user cope with the breakage. Your coping skills are above average, I've submitted patches too, it's still yak shaving and not a very productive use of time. Working out APIs is a hard problem, it should be handled as part of the development phase instead of being completely disconnected.
WebExtensions is very good news. One of the biggest pains is to develop extensions compatible both with FF and Chrome so it would make our lives a lot easier.
> We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
This is basically the creation of a new, multi-browser API standard for browser extensions. This isn't them just adopting a single competitor's ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem.
> There is also a slim chance IE and Safari will join the plugin ecosystem.
You mean Edge. IE development is pretty much dead except for maintenance releases, and it now exists solely to handle legacy websites (read: corporate dinosaurs that rely on ActiveX).
Recent releases of Opera are just a reskinned version of Chrome. This is exactly them adopting a single competitor's ecosystem, it's just that Opera did the same thing even more completely a while ago.
That's true. But that isn't what most users care about regarding this change. Just look at these comment threads: users care about the power-user extensions being forced out. There's a definite drop of support. Firefox is dropping the add-ons that made it special.
Ya know, my initial reaction to this was pretty negative. As a developer, I don't like the idea of losing access to a more powerful technique in favor of a less powerful one. If I want to write an add-on, I want XPCOM / XUL, etc., at least as an option.
However, giving it more thought, I think this might actually be a Good Thing in the long-run. OK, it's a stretch, but hear me out... I've been a vocal opponent of this whole idea of making the browser a poor man's operating system for a while. I want a Web where browsers are really good at, well, browsing hypermedia, and other applications handle "application stuff". So maybe, in a roundabout fashion, making it a little bit harder to extend the browser even further, will encourage people to shift back to a model of handing off some kinds of requests to an entirely different app, rather than trying to shoe-horn the kitchen sink, bathtub, 3d printer, milling machine, jumper cables, semiautomatic pistol, bandsaw, swimming pool, and clown suit all into the browser.
I think the opposite is more likely: Firefox and Chrome using the same extension mechanism -- and, inevitably, that means two-way chasing on implementing APIs that prove useful -- means that even if the ability to do more complex apps in Firefox falls in the short run, the ability to more complex apps in the browser in general (or, at least, Firefox, Chrome, and their descendants and others who adopt the same framewoek) is going to accelerate over a longer term.
"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist."
That's so Mozilla. There's a long history in add-on development of Mozilla deprecating the old thing before the new thing works.
XUL/XPCOM had to go. The mobile browser, "Fennec", doesn't use it at all.
But the "Jetpack" API, the one Mozilla wanted everyone to use instead of XUL/XPCOM, is apparently being deprecated as well. The announcement says it will "continue to work", but the new API seems to be completely separate from Jetpack. That probably means bugs in Jetpack won't be fixed, and bug reports will be answered with "convert to (new thing)".
Jetpack was such a clusterfuck. Horribly documented, released while not ready for prime time, missing basic functionality, and progressing as slowly as Italian criminal trials. I can see the point of them starting from scratch.
It would have been nice if they had learnt their lesson and actually started communicating changes after they had something real to show, but alas, it seems like they're doing the same thing, just a little bit faster (maybe).
I'm really disappointed with them deprecating XUL extensions.
I use a number of extensions that extensively modify the UI (e.g. Tab Mix Plus), and honestly I'd rather just stick with an older version of Firefox than use Firefox without these extensions.
They're using the WebExtension model of isolated extensions with permissions. They're not going to limit themselves to any competitor's API, they'll build a superset by consulting with the developers of popular extensions. Tab Mix Plus being the 15th most popular extension, it's pretty certain they'll be consulted on the new APIs.
Quoting from the announcement:
> A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. 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.
I loved this: " We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple "
>Blink-compatible API in Firefox called WebExtensions
Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? My understanding is that Blink is just the rendering engine and extension code can be found within the main Chromium project.
My best guess is that they are referring to it this way since I think that currently the list of browsers that use Blink is the same as the list of browsers that use Chromium code and people are more used to categorizing browsers based on their rendering engine rather than where the code originated.
> Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible?
That's a good question, since the two sources they link to (from Chrome and Opera) both refer, directly or indirectly, to Chromium extensions, and neither refers to "Blink" at all.
It looks like a bad case of Big Rewrite. Which is mildly unsurprising, coming from an organization that was created to undertake a Big Rewrite; however, after the dismal Jetpack experience, I'm surprised they want to do it all over again, just harder and with no safety net.
How can you tell your own developer community "what you're doing now, it won't be allowed next year; but what will be, we don't know yet"? You might as well tell them to go home.
We all know too well what happens when a backwards-breaking change is imposed without strong functional justifications : most developers don't actually put the effort to upgrade and as a result the vast majority of extensions break. Case in point : python modules, after tremendous effort and years of waiting about 2/3rd of the existing modules have been ported from python 2 to 3.
This is relatively "mitigated" in the case of add-ons because backwards-incompatibility has become the norm so old add-ons are likely to break anyway at some point, but this still seems like a very bad idea for Mozilla to kill a large portion of their ecosystem in that single move, especially if in the bunch are very differentiating extensions like Tree Style Tabs.
Justifying the decision by becoming even more interchangeable with Chrome is especially baffling, what is the strategic point of this?
They want to kill XUL for Firefox, so they must first kill XUL for add-ons so that the add-on situation sucks so bad with XUL Firefox that people don't lose anything by moving to non-XUL Firefox.
And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.
We've identified that XUL is a growing impediment to Firefox's continued success. Exactly what that means (there are dozens of reasons and dozens of ways forward), and how we're going to tackle it, is a big topic that we're digging into.
Yes, removing XUL implies that XUL-based add-ons are not going to last forever. That doesn't mean there won't be a path from here to there: everyone involved recognizes that add-ons are important, and we're increasingly going to be shipping parts of Firefox itself using add-on mechanisms.
And I haven't seen anyone seriously consider killing Gecko: it continues to be awesome, and one of the motivations for deXULification is to allow our platform developers the freedom to only focus on supporting HTML UIs, not a mix of HTML and XUL.
Uh-oh. The main reason I use firefox is vimperator. Followed by the open source, easy to self-host sync framework, noscript and adblock.
One thing I don't see anything about wrt extensions is user control. If ff is to remain relevant - signing extensions will need to come with a trust management framework. I might want to run extensions signed by Debian and myself - but not mozilla (in iceweasel). RedHat (or other vendor) might want their unbranded ff fork to only use RedHat extstensions by default; maybe with an option to also allow upstream ff signed exstensions.
Without that; I see no point in signing support in a free software product?
Well, that's more regarding Noscript and Tree Style Tabs, actually -- it only mentions vimperator/pentadactyl in passing. Either way, thank you for the link -- hopefully the development of new APIs won't lead to a regression wrt. the add-on ecosystem :-)
> ... [cross-process object wrappers] are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions.
"This post really marks the final end of Firefox. The end of a truly robust Add-On model is the only thing remaining at all that sets Firefox apart. The Foundation’s constant running after being a Chrome-alike has finally run the browser into the ground fully."
This comment hit the nail on the head.
Really in general the browser vendors are all killing the web day by day. Maybe ~2004 to around 2013/2014 or so will be remembered as the golden age of web browsers. NPAPI worked in major browsers, you were allowed to install extensions without Mozilla or Google's permission, and Firefox had yet to mutilate its interface in an attempt to be a Chrome lookalike.
"To make sure that some of our users are more secure, we're going to implement a change that will cause some of our users to refuse to update their browser - potentially making them less secure."
I've disabled updates in FF.
Palemoon removed Tab Groups and the addon is extremely buggy and doesn't restore properly when the browser crashes. Waterfox had several issues with plugins I use.
I guess it's time to fork FF and maintain my own version, implementing security patches as they come in?
Is Iceweasel able to be compiled on Windows? I don't see why they would distribute/maintain it outside of Debian/*Nix distribution. Although maybe they decided not to touch the makefile? (And any currently available "Iceweasel for Windows" is hosted on malware sites.)
GNU IceCat could also be an alternative along the same lines, and I know for sure that IceCat can be compiled on Windows and they distribute a Windows binary.
The only problem being GNU IceCat doesn't seem to work on my work computer..
I want control over what my browser does, not necessarily my operating system.
I'm highly selective over my software as I require it to fulfill very precise goals in the exact manner of my choosing. If it fails to do so, I'll find better software.
For example, I have yet to find an image viewing software that is satisfactory for my usage that exists for Unix distribution. I use an extremely niche, unheard of software that is 'Windows Only'. It's so niche that searching for the name of this software on Google only results in posts of me talking about the software. (I decline to name for privacy reasons.)
My operating system is a platform to run software. I'd hop to Debian or Arch in seconds if I could find existing software that meets my needs. While the image browser is one example, there are more that do not exist to my desired standards outside of Windows applications.
My desire for software that performs certain functions and in the manner I want outweighs my desire for privacy from my government and control over every system of my operating system.
ps:
I know your question was probably meant rhetorically.
>Palemoon removed Tab Groups and the addon is extremely buggy and doesn't restore properly when the browser crashes. Waterfox had several issues with plugins I use.
You know, I had plenty of reasons to list about how useless signed extensions are for what they're trying to achieve...
I'm even _already_ running an "unbranded" firefox in all my devices (iceweasel, fennec), for the same reasons I have to run chromium, so I won't even be _directly_ affected....
But there's only one thing I really want to say to Mozilla right now, as a developer:
Fuck you Mozilla.
And there's another, as an user of which most extensions are unsigned:
When Mozilla will decide, apple/google style, what is and what is not acceptable as an extension for their browser, people will maybe realize that this is just the tipping point.
But maybe that won't be necessary anyway. By adopting a very limiting standard for extension development and dropping xul (which might be a good idea for other reasons though), there won't be any significant difference between firefox and (say) chrome. A few tweaks in the browser frame won't attract masses of people. Switching from Chrome to Firefox on Android require a pretty big incentive.
Right now, I'm on firefox only for the extensions. I have really no other compelling reasons.
It's only surprising if you don't understand that Mozilla's core mission now is to promote a permanent JavaScript monopoly. Mozilla has committed to blocking any technology which could ever offer equal support to any other languages. Now they cannot even allow plugins unless they are based on JavaScript. "The Web" used to mean web pages and HTTP, now "The Open Web" and "Web Technologies" mean we are forced to work with a growing mountain of ill-considered, weird and unsafe "bad parts" forever.
In a strikingly similar parallel dimension, vendors have applied pressure to ensure that networked PCs would only run COBOL, and other languages could only be supported by compiling to a subset of COBOL that inherited its semantics so that nothing would ever be faster than COBOL. In that parallel dimension, this restriction is known as "Open Web", although nobody knows what is open about it.
It's not about that. Even if I liked COBOL, I wouldn't want a world where only COBOL can be used. And it doesn't make sense that this world has to be artificially enforced when there is demand for variety.
Not sure what you mean by the "same basic semantics". I think the semantics of Go and Elm are quite far away from JavaScript. Dart less so, but it's enough to change the developer experience quite a bit.
I don't particularly like x86 instructions, but they also don't bother me that often.
Granted that JavaScript isn't sufficiently hidden yet, particularly in debuggers. That will take a few years. On the other hand, it's significantly more readable than assembly and getting better, so as a compiler target language, I think it will work out okay.
The forces here are no more artificial than the ones that made the industry standardize on x86 and (later) ARM. Popular, accepted standards become more popular when the barriers to alternatives are very high, as can be shown by the people who tried and failed with strong alternatives.
"BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello.
Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install."
And a more serious comment from a developer of DownThemAll!:
"I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention…
But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys.
To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer."
https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...