Closed Bug 1425229 Opened 7 years ago Closed 7 years ago

WebExtensions suggestion: embedded node.js

Categories

(WebExtensions :: Untriaged, enhancement, P5)

57 Branch
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: michel.gutierrez, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171129230835 Steps to reproduce: Right now, the main issue with WebExtensions for add-ons is missing APIs. The APIs for interacting with the browser UI and behaviour are to be discussed on a case-by-case basis, depending on their usefulness and potential of confusion toward users. But there are also a bunch of APIs that are relatively independent from the browser and still very needed by add-ons. Filesystem and Sockets APIs come to mind, but also many hardware related APIs, server abilities, unrestricted HTTP requests, ... What if Firefox would embed node.js as a special native app. This instance of node.js would be setup to load its required modules from within the add-on package itself, and would communicate with the add-on using standard native messaging. This would make available virtually anything an application may need as available libraries. Of course, the feature to make use of this node.js native app would require a specific permission, possibly an extra warning to tell the user the add-on now has potentially all user's rights on the system. Note it's no more right than what an add-on could do using the late add-ons SDK. But this will turn Firefox into an application framework that would compete very well against Electron and NW.js (both relying on Chromium), and would make an ideal platform for developing and distributing multi-platforms applications.
Something close to this idea is Niklas native-ext project: https://github.com/NiklasGollenstede/native-ext But of course he has to do with current WebExtensions/NativeMessaging constraints, so this made the installation too complicated for average users.
Severity: normal → enhancement
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
We can go through the regular community process here but I'm personally quite opposed to this. One of our goals with WebExtensions is getting rid of access to the local machine since the number of things that malicious extensions can do with that sort of access is virtually unlimited and we can't effectively review that code or give users the opportunity to make an informed choice. People often suggest some version of "just give users a really scary warning that they have to read and accept before using this feature" which I don't believe is adequate.
Whiteboard: design-decision-needed
What we all want is that a user who installs an extension on Firefox can feel reasonably safe. But I think we have already gone too far in restricting what an add-on can do, so that many extensions just cannot carry out what they are supposed to by just using the services offered by the WebExtensions API. As a result, either the extension just dies, leaving its former users **** of, like DownThemAll, or this extension now uses a native companion application to perform the missing services like Video DownloadHelper. And since we allow native applications (which are not reviewed), why not making things simpler by providing the right tools. But ok, living with the current policy, why not adding a fourth category of add-on: in addition to Extensions, Themes and Plugins, adding Applications (or whatever smarter name Mozilla marketing can come with). The user will know the application she installs has no guarantee to be harmless, just like any application she may decide to install from a Web site. Except that at least if it is a Mozilla-distributed package, there is a place for users to share reviews, and potentially the ability to remotely uninstall applications that are notoriously harmful. People install programs anyway. If we decline to provide a bit more safety to them while we could, just to cover our asses saying "if they get a trojan, at least it won't be through our platform", then we fail our mission. With that node.js addition, Firefox would be in a situation to provide the best environment for developing, distributing and running multi-platform applications: just like NW.js and Electron, it offers a Web API based UI, node.js to address almost any need, but in addition, thanks to WebExtensions, it would also provide a nice, safe and documented way to interact with the application people use the most: their browser. If we want Firefox to gain back market shares against Chrome, that is one way. Last, being over-protective toward the users might have the opposite effect: people will get the apps they need anyway, but from sources that are absolutely uncontrolled.
I may not have been clear, a deliberate decision with native messaging was to require that native applications be installed through some process external to Firefox (obviously many people will download native applications with Firefox, but those generally run some native installer that is external to the browser). Mac and Windows both have systems for verifying native applications. Those systems are far from perfect, but I don't think that building something into Firefox that (partially) duplicates those systems is going to make the overall situation any better.
Sorry Andrew but i don't get it. As far as i know, Mac and Windows do not have anything special to enforce native applications verification nor any way for users to exchange experience running a particular application. So building something on Mozilla servers would definitely improve the situation. Also, speaking by experience, distributing a separate native application with its own installer for each of the available platforms, is a tedious task for the developer and an inconvenience for the user. Having node.js access from within Firefox would make things as smooth as they could be: both the native app and the WebExtensions-based piece of code (i don't want to call that last one an extension) would be installed in one shot. My point is: either we forbids something (here making use of native applications) or we allow it (and make things as simple as they can possibly be). It looks to me that we picked the wrong strategy to make this possible but cumbersome.
Priority: -- → P5
cc'ing Myk because I remember him talking about something similar to this a while back.
Whiteboard: design-decision-needed → [design-decision-needed]
(In reply to Michel Gutierrez from comment #5) > Sorry Andrew but i don't get it. > > As far as i know, Mac and Windows do not have anything special to enforce > native applications verification nor any way for users to exchange > experience running a particular application. So building something on > Mozilla servers would definitely improve the situation. Both of those platforms do code signing, I don't know the details of how they verify keys or what sort of capabilities they have for revocation. And the Apple App Store has reviews and ratings, etc. I don't use Window regularly so I don't know what sort of features it offers. However, that's not really the point. Distributing general native code through Firefox and AMO would be a massive expansion beyond what those systems are designed for. > Also, speaking by experience, distributing a separate native application > with its own installer for each of the available platforms, is a tedious > task for the developer and an inconvenience for the user. Having node.js > access from within Firefox would make things as smooth as they could be: > both the native app and the WebExtensions-based piece of code (i don't want > to call that last one an extension) would be installed in one shot. Sure, and the flip side of this is that making it easier for extension developers also makes it easier for malware distributors, and it would open up an enormous number of new ways for malware to do very bad things. We don't have a great solution here but forcing installation of native applications to take place outside of the browser is about the strongest indication we can give to users that the consequences of agreeing to install a native application are significant. > My point is: either we forbids something (here making use of native > applications) or we allow it (and make things as simple as they can possibly > be). It looks to me that we picked the wrong strategy to make this possible > but cumbersome. I completely disagree that the only two options are the two extremes. I understand that you don't like the decision we made but I've explained why we made it and you haven't raised anything new that wasn't considered when that decision was made.
(In reply to Andrew Swan [:aswan] from comment #7) > Both of those platforms do code signing, I don't know the details of how > they verify keys or what sort of capabilities they have for revocation. And > the Apple App Store has reviews and ratings, etc. I don't use Window > regularly so I don't know what sort of features it offers. However, that's > not really the point. Distributing general native code through Firefox and > AMO would be a massive expansion beyond what those systems are designed for. I am neither a Mac nor a Windows expert, but i can tell for sure that you don't need to put a native application on a platform like the Apple Store nor whatever distribution solution Windows may offer, for it to be available as an extension companion app. In my case, the application installers (7 flavours depending on platform, architecture and packaging format) are hosted as a github release but as far as i know, they could as well be on whatever evil server anywhere on the Web. It turns out that i sign my app on Windows and Mac, but here again, there is nothing mandatory. > Sure, and the flip side of this is that making it easier for extension > developers also makes it easier for malware distributors, and it would open > up an enormous number of new ways for malware to do very bad things. This is true for any platform that allows people to express creativity by providing programs, starting with OSes, compilers and environment like node.js or Python. > We don't have a great solution here but forcing installation of native > applications to take place outside of the browser is about the strongest > indication we can give to users that the consequences of agreeing to install > a native application are significant. If an extension takes you to a site to install a required app, there are little chances this site tells you "hey, be careful, there are security risks installing this app". If the install is made from Mozilla servers, we can do so. > I completely disagree that the only two options are the two extremes. I > understand that you don't like the decision we made but I've explained why > we made it and you haven't raised anything new that wasn't considered when > that decision was made. When that decision was made, i was also told many times, privately and publicly, that Mozilla will provide the APIs that are necessary for my add-on to work properly. That has not been the case. Since Firefox 57 was released, i have received hundreds (well, thousands) of bad comments and insults because things were no longer what they used to be. And this was not my fault but the consequences of this decision, so i feel entitled to give my opinion about how things should be improved. Disclaimer: i filled this bug entry because i really think this is the best way to go for Mozilla and Web users in general. Implementing my suggestion will not give me any benefit: i took it the hard way with the current policy, developing from scratch my own native app solution that have been installed to date over 2.6 million times in a little bit more than a month. If things remain what they are, so be it. It's just that as a Mozillian, i would feel sad that we don't seize the opportunity to offer an innovative solution that people really need and would make Firefox shine.
I don't have anything to add to what's already been said, I stand by the observation that this is just arguing about a decision we already made without adding any new information that wasn't available when the decision was originally made. I'm not sure how the remark about APIs is relevant here, that sounds like a different issue than the topic of this bug.
I guess the new thing is that now that Firefox Quantum has been released, we can better measure how much the add-on ecosystem has been hurt. My remark about APIs was that a decision that was "we provide a Chrome-like restrictive API AND additional APIs add-ons need" became "we provide a Chrome-like restrictive API". So it sounds relevant to me to question either the decision or its implementation.
About new things, i read today that Wladimir Palant, the original author of AdBlock Plus, leaved his project. In his goodbye note at https://palant.de/2017/12/20/taking-a-break-from-adblock-plus-development, he wrote: """ As damaging as this move [to WebExtensions] inevitably was for our extension’s quality and reputation, it had a positive side effect: our original Adblock Plus for Firefox codebase is now legacy code, not to be worked on. """ Not mentioning Nils Maier's DownThemAll who ran away months ago. And it's just about a few people i personally know, not an extensive investigation on the "decision" collateral damages. It's good to make decisions and it's what Mozilla did, but it would be foolish to ignore their consequences now that they can be observed and just don't think of how things could be improved. There is obviously no way to step back on WebExtensions, but bending the rules by offering a new, more open, and yes, less secure, type of add-on deserves to be discussed.
(In reply to Andy McKay [:andym] from comment #6) > cc'ing Myk because I remember him talking about something similar to this a > while back. Here's a firefox-dev conversation in which we discussed integrating Node.js into Firefox: https://groups.google.com/d/topic/firefox-dev/MWE-_1xkokk/discussion And here's a dev-addons conversation in which we discussed exposing it to extensions: https://mail.mozilla.org/pipermail/dev-addons/2016-November/002149.html
These are interesting discussions. Note that my proposal is way less ambitious than what is discussed here: it is not about running node.js within the add-on's thread, nor having a specific API between node.js (running in its own thread) and the add-on. It is just about using the existing native messaging mechanism and a Firefox-provided plain minimal instance of node.js to avoid the need for the user to install separately a companion app and for the developers to provide installers for each platform. This swipes away most concerns raised in those discussions. Only one remains: security. This can be addressed in 2 ways: 1/ reviewing the add-on AND the app. This may look like an overwhelming charge for add-on editors, but keep in mind node.js apps are written in javascript, just like add-ons. And taking Video DownloadHelper as an example (it is by far the most used addon+app system being used on Firefox), if you had to review it, you would spend 5% of the time on the app and 95% on the add-on. 2/ presenting differently to the user regular add-ons and add-ons+app systems, with appropriate warnings As Noit stated in a former conversation, the current status is that we tell developers "host the exe on your website, so we can look the other way, and let you do whatever you want to our users". This is in no way better.
Hi Mig! This has been added to the agenda for the March 13, 2018 WebExtensions APIs triage. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1b4r8z964_Est_mbSYUx9jtRt-HTtXgu-EAzM_3yr7ww/edit * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
> I guess the new thing is that now that Firefox Quantum has been released, we can better measure how much the add-on ecosystem has been hurt. We have tracked add-on usage very closely since the launch, and the outcome has been largely positive. Certainly not something that would make us radically change direction or revert to the previous model.
> Hi Mig! This has been added to the agenda for the March 13, 2018 > WebExtensions APIs triage. Would you be able to join us? Hey Caitlin ! Sure, i'll be there. > We have tracked add-on usage very closely since the launch, and the outcome > has been largely positive. Certainly not something that would make us > radically change direction or revert to the previous model. My proposal was not to "change direction" nor to "revert to the previous model", but to offer in Firefox a new capability: running fully fledged applications using Web-technologies-based user interface by capitalizing on the existing WebExtensions development and documentation efforts, and giving people more reasons to use Firefox by offering an alternative to Chromium-based NW.js and Electron.
Hey Michel (and others), Sorry for dragging this on, but after Caitlin added this to the design meeting agenda, the addons team discussed it briefly, and concluded this is something none of us are open to doing. As Andrew and Jorge have explained above (and other times similar things have been proposed), this is completely out of scope set out for Web Extensions, and incompatible with the new (mostly automated, post-publish) review process. It has been shown time and again that users mostly click-though and ignore "Special Permissions", and those who actually _could_ understand what this permission might allow, are very well capable of installing the helper native messaging app (or even node.js). We are not comfortable with exposing Firefox users to the potential security risks of a vast number of node modules and dependencies, nor can we be reasonably expected to review them all. (And speaking more broadly, the bigger Firefox team has decided developing an "application framework that would compete very well against Electron" is beyond the resources that Mozilla has, and chosen to focus on making Firefox the best browser possible). Sorry again for jumping the gun, but I think it's better to remove this from the agenda, and leave time to discuss another issue where we don't already know the outcome.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed]
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.