5 ms·

The transition to WebExtensions is absolutely necessary though, from both a security standpoint and developer friendliness standpoint. The current Firefox exte

The transition to WebExtensions is absolutely necessary though, from both a security standpoint and developer friendliness standpoint. The current Firefox extension model is simply too powerful. The API surface (and thus attack surface) is humongous, and extensions can literally change and replace any part of the browser's native UI with little restrictions, leaving the browser open to all sorts of phishing attacks from extensions and making it a nightmare to ensure extensions compatibility because any change whatsoever to the UI can break something. This is a large part of the reason why Firefox extensions still require manual audits while Chrome extensions don't. The status quo is not simply sustainable for Firefox, especially when considering how little resources Mozilla has to spare compared to tech giants like Google. In addition, XUL is an archaic technology that should eventually be replaced by proper web standards in order to leverage the skills and knowledge of the entire web development community like Chrome has done. Quite a few of my web developer colleagues maintain Chrome extensions in their spare time, and when I ask why they don't offer a Firefox version as well, 9 out of 10 times the answer boils down to not wanting to work with XUL. WebExtensions will alleviate not only the problems with XUL itself, but will also offer great compatibility for building extensions that work across browsers, making the lives of extension developers even better, which will only help make the extension ecosystem even more vibrant than it is today. The people at Mozilla have been working with extension developers however they can to enable them to port extensions to WebExtensions. If some extension developers simply choose to abandon their extensions instead of working with Mozilla to port them, that's their decision to make, but I feel it's rather unfair to blame Mozilla for this. I use Firefox as my main browser mostly for the extensions, and needless to say, I'm a huge fan of Firefox's current ecosystem of extensions myself. The potential of losing some of my favorite extensions does suck a lot, so I understand where a lot of the frustration is coming from. However, I'm also extremely optimistic about WebExtensions and the future of the budding cross-browser extension ecosystem, and have no doubt that even if some of my current favorites end up being abandoned, a new wave of great extensions will come to replace them in due time.

rndgermandude 11y ago
Just to clarify, I'm not all all against WebExtensions. You made some good points in particular regarding developer mindshare. Yes, (mostly) cross-browser extensions are the way to go, and it's rather unfortunate that the a lot earlier JetPack/Add-on SDK failed in that regard, among other things. There is no reason for WebExtensions not to exist, and plenty good reasons for them to exist. But that has nothing much to do with the question of whether WebExtensions should be the only supported extension type in Firefox. I'm not convinced about the other points you make, though. Extensions right now are extremely powerful indeed and there are certainly security considerations to be taken into account. But Chrome extensions have most of the same issues: There have been tons of extensions ex-filtrating sensitive user data or doing other shenanigans in the Chrome Store, mostly because the Chrome review model is "automatic review everything after some piece of software tries to check some basic things and ask questions later". You might get a smaller attack surface with a more limited API, but to make sure users don't install malware you'll still need a human to catch malicious people trying to game the system. Given that mozilla plans additional/extended APIs for a lot of things that might be quite powerful in their own right, manual reviews might be still a necessity after all for lots of extensions. XUL might be archaic as you call it but XUL is not even the point. If Firefox transitioned away from browser.xul to browser.html today, extensions would break but most of the porting would involve replacing <toolbarbutton /> with <button class="toobarbutton"/> or something like that. Most of the "native" XUL can be replaced by web components without anybody noticing, and in fact parts of XUL is already html underneath even today. The power of current Firefox extensions comes from XUL having a DOM (just like HTML, just with other element names) combined with access to the low(er) level stuff, mainly the browser.xul javascript scope (just like a browser.html javascript scope) and XPCOM scripting (and a browser.html will still need XPCOM or equivalent access). WebExtensions take away that power in favor of a more well-defined but thusly more constrained and limited API. I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers. Add-on developers wanting "easy" or a single cross-browser codebase would be still free to use WebExtensions, which would also give mozilla a break, while the more/most powerful add-ons could still hack deeply into the browser. I don't blame mozilla for developers abandoning their add-ons because they lack the resources, motivation or APIs to do a port (or any combination thereof), however developers abandoning their add-ons is still a reality and should not be disregarded just because mozilla might try their best to keep the fallout somewhat low. mozilla, however, made a decision to break existing add-on en masse, and that decision and the reasons and effects should be allowed to be critically inspected.
- lewisl9029 11y ago
  > I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers. It looks like our disagreement boils down to this single tradeoff. Firefox's virtually unlimited extensibility definitely resulted in some amazing extensions that wouldn't have been possible with any less flexible system. However, I don't believe the security and maintenance costs imposed by such a system can be justified in the case of a web browser used by millions of people where security and iteration speed is paramount. Those looking to experiment without limits can still fork the browser codebase itself to build proof of concepts that way. If the proof of concept is compelling and gains enough traction, it would then become much easier to propose the necessary extensions to the WebExtensions spec and have them accepted and built. There is definitely a lot of friction to this process, but the alternative of maintaining Firefox's status quo with respect to extensions is just not going to be viable, in my opinion.

rndgermandude 11y ago

Just to clarify, I'm not all all against WebExtensions. You made some good points in particular regarding developer mindshare. Yes, (mostly) cross-browser extensions are the way to go, and it's rather unfortunate that the a lot earlier JetPack/Add-on SDK failed in that regard, among other things. There is no reason for WebExtensions not to exist, and plenty good reasons for them to exist. But that has nothing much to do with the question of whether WebExtensions should be the only supported extension type in Firefox. I'm not convinced about the other points you make, though. Extensions right now are extremely powerful indeed and there are certainly security considerations to be taken into account. But Chrome extensions have most of the same issues: There have been tons of extensions ex-filtrating sensitive user data or doing other shenanigans in the Chrome Store, mostly because the Chrome review model is "automatic review everything after some piece of software tries to check some basic things and ask questions later". You might get a smaller attack surface with a more limited API, but to make sure users don't install malware you'll still need a human to catch malicious people trying to game the system. Given that mozilla plans additional/extended APIs for a lot of things that might be quite powerful in their own right, manual reviews might be still a necessity after all for lots of extensions. XUL might be archaic as you call it but XUL is not even the point. If Firefox transitioned away from browser.xul to browser.html today, extensions would break but most of the porting would involve replacing <toolbarbutton /> with <button class="toobarbutton"/> or something like that. Most of the "native" XUL can be replaced by web components without anybody noticing, and in fact parts of XUL is already html underneath even today. The power of current Firefox extensions comes from XUL having a DOM (just like HTML, just with other element names) combined with access to the low(er) level stuff, mainly the browser.xul javascript scope (just like a browser.html javascript scope) and XPCOM scripting (and a browser.html will still need XPCOM or equivalent access). WebExtensions take away that power in favor of a more well-defined but thusly more constrained and limited API. I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers. Add-on developers wanting "easy" or a single cross-browser codebase would be still free to use WebExtensions, which would also give mozilla a break, while the more/most powerful add-ons could still hack deeply into the browser. I don't blame mozilla for developers abandoning their add-ons because they lack the resources, motivation or APIs to do a port (or any combination thereof), however developers abandoning their add-ons is still a reality and should not be disregarded just because mozilla might try their best to keep the fallout somewhat low. mozilla, however, made a decision to break existing add-on en masse, and that decision and the reasons and effects should be allowed to be critically inspected.

lewisl9029 11y ago
> I think the pro of having virtually unlimited extendability as demonstrated by tons of great and creative extensions outweigh the cons of larger attack surface and higher maintenance costs for both mozilla and add-on developers. It looks like our disagreement boils down to this single tradeoff. Firefox's virtually unlimited extensibility definitely resulted in some amazing extensions that wouldn't have been possible with any less flexible system. However, I don't believe the security and maintenance costs imposed by such a system can be justified in the case of a web browser used by millions of people where security and iteration speed is paramount. Those looking to experiment without limits can still fork the browser codebase itself to build proof of concepts that way. If the proof of concept is compelling and gains enough traction, it would then become much easier to propose the necessary extensions to the WebExtensions spec and have them accepted and built. There is definitely a lot of friction to this process, but the alternative of maintaining Firefox's status quo with respect to extensions is just not going to be viable, in my opinion.