info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
NPAPI replacement for those of us who still need system API access
595 views
Skip to first unread message
Richard Bateman
Oct 9, 2015, 4:38:23 PM10/9/15
to
Greetings =]
First of all, I realize that this is not going to be a popular topic for the firefox developers; the push has long been to have a more secure, more stable, and more sandboxed web experience in all browsers. Allowing access to system APIs and native code opens a large can of worms and can be dangerous. Many NPAPI plugins could actually be rewritten using emscripten/asm.js, html5 javascript APIs, and better infrastructure.
However...
As the principle developer of FireBreath, I can tell you that there are still many things that FireFox users need that cannot be done inside the browser. Because of this we've been forced to add support for FireBreath plugins which can be accessed through Native Messaging to allow continued support with Google Chrome; it's hacky, it's an ugly interface, and it's far from ideal in many ways, but it's the only way we've been able to provide the features which our users need.
At GradeCam, my current place of employment, we primarily have two requirements which cannot met in any other way (that I am aware of) than an NPAPI plugin in Firefox: a) access to a brand of camera which is used in thousands of schools in the US alone, which doesn't provide standard USB camera drivers, and access to our gradebook export library which interfaces with gradebook applications used by teachers throughout the world.
We have already built an emscripten / getUserMedia solution which works adequately well on Firefox for our primary use, and to be perfectly honest I would *love* not to have to deal with plugins, but dropping support for those other cameras would require thousands of teachers to discard their expensive document cameras and purchase new ones -- I'm sure you are as aware as I am of how unlikely that is. In addition, our software provides those teachers with an easy way to export the data into their gradebook, whatever that gradebook may be. The latter question I hope will some day be less important as we work to create an HTML/Javascript solution, but that solution will never be as powerful or flexible as our current system, nor will it ever allow us to cleanly export to arbitrary gradebooks which are not web-based. Keep in mind that it is not practical for us to try to convince every gradebook vendor to help us solve this problem.
My point is that we aren't alone in these types of needs; no matter how many features you may add to the web, and no matter how awesome that is or how much I would love not to have to deal with native code, there are a huge number of niche use cases which simply aren't satisfied without some access to it.
What is your strategy going forward with that? Google has given us Native Messaging. It's a terribly obnoxious API to deal with and extremely inefficient in a lot of ways, but it does provide us with a method of communicating with a native application. Does FireFox have something similar? If not, do you plan to add something similar or at least something that could be used for a similar purpose by the time that NPAPI is deprecated?
If you have something, I'd love to know what it is and we will try to add support for it in FireBreath to assist with the transition; if you don't, but are open to adding it, I would love to be part of those discussions to help make sure that the use cases that I have seen are addressed.
I look forward to your thoughts!
Richard Bateman
FireBreath principle developer
GradeCam Lead Software Architect
First of all, I realize that this is not going to be a popular topic for the firefox developers; the push has long been to have a more secure, more stable, and more sandboxed web experience in all browsers. Allowing access to system APIs and native code opens a large can of worms and can be dangerous. Many NPAPI plugins could actually be rewritten using emscripten/asm.js, html5 javascript APIs, and better infrastructure.
However...
As the principle developer of FireBreath, I can tell you that there are still many things that FireFox users need that cannot be done inside the browser. Because of this we've been forced to add support for FireBreath plugins which can be accessed through Native Messaging to allow continued support with Google Chrome; it's hacky, it's an ugly interface, and it's far from ideal in many ways, but it's the only way we've been able to provide the features which our users need.
At GradeCam, my current place of employment, we primarily have two requirements which cannot met in any other way (that I am aware of) than an NPAPI plugin in Firefox: a) access to a brand of camera which is used in thousands of schools in the US alone, which doesn't provide standard USB camera drivers, and access to our gradebook export library which interfaces with gradebook applications used by teachers throughout the world.
We have already built an emscripten / getUserMedia solution which works adequately well on Firefox for our primary use, and to be perfectly honest I would *love* not to have to deal with plugins, but dropping support for those other cameras would require thousands of teachers to discard their expensive document cameras and purchase new ones -- I'm sure you are as aware as I am of how unlikely that is. In addition, our software provides those teachers with an easy way to export the data into their gradebook, whatever that gradebook may be. The latter question I hope will some day be less important as we work to create an HTML/Javascript solution, but that solution will never be as powerful or flexible as our current system, nor will it ever allow us to cleanly export to arbitrary gradebooks which are not web-based. Keep in mind that it is not practical for us to try to convince every gradebook vendor to help us solve this problem.
My point is that we aren't alone in these types of needs; no matter how many features you may add to the web, and no matter how awesome that is or how much I would love not to have to deal with native code, there are a huge number of niche use cases which simply aren't satisfied without some access to it.
What is your strategy going forward with that? Google has given us Native Messaging. It's a terribly obnoxious API to deal with and extremely inefficient in a lot of ways, but it does provide us with a method of communicating with a native application. Does FireFox have something similar? If not, do you plan to add something similar or at least something that could be used for a similar purpose by the time that NPAPI is deprecated?
If you have something, I'd love to know what it is and we will try to add support for it in FireBreath to assist with the transition; if you don't, but are open to adding it, I would love to be part of those discussions to help make sure that the use cases that I have seen are addressed.
I look forward to your thoughts!
Richard Bateman
FireBreath principle developer
GradeCam Lead Software Architect
EL
Oct 9, 2015, 6:01:09 PM10/9/15
to
Am Freitag, 9. Oktober 2015 22:38:23 UTC+2 schrieb Richard Bateman:
> My point is that we aren't alone in these types of needs; no matter how many features you may add to the web, and no matter how awesome that is or how much I would love not to have to deal with native code, there are a huge number of niche use cases which simply aren't satisfied without some access to it.
>
+1 for that.
> My point is that we aren't alone in these types of needs; no matter how many features you may add to the web, and no matter how awesome that is or how much I would love not to have to deal with native code, there are a huge number of niche use cases which simply aren't satisfied without some access to it.
>
I have a plugin that *needs to* draw native windows in the browser and otherwise interact with the web page. The plugin is sandboxed, runs in a very restrictive and safe context (per default, that can be configured individually by the user).
I don't care much about platform independence for that use case. It is fine when it runs on windows PC only, because the environment where it is supposed to be used is windows PCs. But I care a lot about accessing native resources (communication with a service on localhost via a proprietary, speed optimized protocol), and I care about drawing a native window inside the current document in the browser, with real time images streamed from the service.
All this has worked fine so far and made users (customers) happy. But it is taken away when NPAPI is taken away, leaving me with just the only option to go back to a fat desktop client with all its disadvantages.. besides the time it takes to re-develop everything from scratch.
--
EL
Chris Peterson
Oct 9, 2015, 8:07:30 PM10/9/15
to
On 10/9/15 1:38 PM, Richard Bateman wrote:
> What is your strategy going forward with that? Google has given us Native Messaging. It's a terribly obnoxious API to deal with and extremely inefficient in a lot of ways, but it does provide us with a method of communicating with a native application. Does FireFox have something similar? If not, do you plan to add something similar or at least something that could be used for a similar purpose by the time that NPAPI is deprecated?
The proposed solution is to create a Firefox extension that talks to
> What is your strategy going forward with that? Google has given us Native Messaging. It's a terribly obnoxious API to deal with and extremely inefficient in a lot of ways, but it does provide us with a method of communicating with a native application. Does FireFox have something similar? If not, do you plan to add something similar or at least something that could be used for a similar purpose by the time that NPAPI is deprecated?
native code. The APIs listed below are some options.
Mozilla really ought to create some example extensions demonstrating
these approaches. They would be a good starting place for developers
wanting to port their NPAPI plugin to an extension.
* child_process API
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
* ctypes
https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes
* WebUSB API (available on Firefox OS, but not yet available to desktop
extensions)
http://reillyeon.github.io/webusb/
https://github.com/alexsalas/WebUSB
bna...@gmail.com
Oct 9, 2015, 11:48:46 PM10/9/15
to
Hello, I have some use cases, which currently are "solved" with Java Applets:
1 - Control a Twain scanner. (kodak scanner i2800)
2 - Control a fingerprint reader (Nitgen Fingkey Hamster I DX).
3 - Control a barcode reader.
All of these involve access dll's (or .so ) via JNI.
What technology Firefox provides so I can migrate and continue to access/control hardware as i can now via dll's + JNI + Java Applets?
--
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul
1 - Control a Twain scanner. (kodak scanner i2800)
2 - Control a fingerprint reader (Nitgen Fingkey Hamster I DX).
3 - Control a barcode reader.
All of these involve access dll's (or .so ) via JNI.
What technology Firefox provides so I can migrate and continue to access/control hardware as i can now via dll's + JNI + Java Applets?
--
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul
EL
Oct 10, 2015, 2:37:19 AM10/10/15
to
Am Samstag, 10. Oktober 2015 02:07:30 UTC+2 schrieb Chris Peterson:
> On 10/9/15 1:38 PM, Richard Bateman wrote:
> The proposed solution is to create a Firefox extension that talks to
> native code. The APIs listed below are some options.
>
What about drawing native windows in the browser? I mean windows which really need to be native?
> On 10/9/15 1:38 PM, Richard Bateman wrote:
> The proposed solution is to create a Firefox extension that talks to
> native code. The APIs listed below are some options.
>
And, since it it a major argument that NPAPI is insecure, because it makes it possible to call native code with access to the system - how much more secure is the approach to create an extension that calls native code? It seems to lead the argument ad absurdum, that NPAPI is insecure (which I think is not really true anyway, because it is the same as saying: "all computer programs are insecure, because the C/C++ API has access to the system").
--
EL
mark.regi...@gmail.com
Oct 10, 2015, 2:35:47 PM10/10/15
to
On Saturday, October 10, 2015 at 11:07:30 AM UTC+11, Chris Peterson wrote:
> On 10/9/15 1:38 PM, Richard Bateman wrote:
> * child_process API
>
> https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
Thanks for linking to this.
> On 10/9/15 1:38 PM, Richard Bateman wrote:
> * child_process API
>
> https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
I develop control systems for machines, where a browser is the UI (dynamic HTML is a good language for this), while the machine logic and machine I/O is written in Java (Java PLC). I currently connect the two through Applets. There's an invisible Applet for the main control program, and I once had a separate graphing Applet, which I've had to convert to JavaScript, because unlike IE, Applets print blank in Firefox on Linux. This was hard to do because the LiveConnect interface between Java Applets and JavaScript is extremely inefficient, forcing me to send the large amounts of graph data as encoded strings rather than arrays.
Now the Java plugin is going away, I'll have to run the Java control program in a separate process, and find a way to communicate with JavaScript. What's really needed is a Firefox extension and Java class that when paired emulates the LiveConnect API (DOM manipulation and bi-directional remote procedure calls), but implements it through inter-process messaging. This will save many people developing their own custom replacements.
rbat...@gradecam.com
Oct 12, 2015, 3:57:12 PM10/12/15
to
Is js-ctypes still a viable method? For some reason I was under the impression that we weren't allowed to include a binary in an XPI.
What restrictions will there be on use of the child_process API? I assume you can't just launch any arbitrary executable, so how does the security model work? This is shown as experimental; is it already usable in FireFox or does it require a development version?
With either case, is it possible to communicate from the extension into the page (possibly using window messages like in Chrome?) so that the functionality can be exposed to the page?
I appreciate the information; I have been trying to find this information myself, but some of the pages look potentially out of date and others seem to lack the relevant information (such as which version the child_process API is available in and security models).
Richard
Benjamin Smedberg
Oct 12, 2015, 4:38:27 PM10/12/15
to Richard Bateman, dev-tech...@lists.mozilla.org, Kev Needham
On 10/9/2015 4:38 PM, Richard Bateman wrote:
> What is your strategy going forward with that? Google has given us Native Messaging. It's a terribly obnoxious API to deal with and extremely inefficient in a lot of ways, but it does provide us with a method of communicating with a native application. Does FireFox have something similar? If not, do you plan to add something similar or at least something that could be used for a similar purpose by the time that NPAPI is deprecated?
addons ecosystem on WebExtensions, which is designed to use compatible
APIs with Chrome where possible. So I do believe that we will have
native messaging which is compatible with Chrome. I'm cc'ing Kev
Needham, our product manager for addons, to provide more details if he
has them.
The Addon SDK already has something similar, the system/child_process
API which allows pipe-based communication with an external binary:
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
Also, we expect to implement the USB interface so that extensions have
direct access to USB devices via a stream API. I don't know whether that
will help your particular use-case, since you'd still need to know the
USB protocol details for the devices, but that might be a solution
available to you.
I'm sure our addons team would appreciate any assistance with building
and testing the native messaging or USB APIs. I'm happy to make
introductions if you like.
--BDS
[1]
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
Benjamin Smedberg
Oct 12, 2015, 4:42:04 PM10/12/15
to EL, dev-tech...@lists.mozilla.org
On 10/9/2015 6:01 PM, EL wrote:
> I have a plugin that *needs to* draw native windows in the browser and otherwise interact with the web page. The plugin is sandboxed, runs in a very restrictive and safe context (per default, that can be configured individually by the user).
> I don't care much about platform independence for that use case. It is fine when it runs on windows PC only, because the environment where it is supposed to be used is windows PCs. But I care a lot about accessing native resources (communication with a service on localhost via a proprietary, speed optimized protocol), and I care about drawing a native window inside the current document in the browser, with real time images streamed from the service.
any form (plugin, extension, etc). If you require that level of
OS-specific behavior, you should switch to a native application.
--BDS
EL
Oct 12, 2015, 6:15:13 PM10/12/15
to
Am Montag, 12. Oktober 2015 22:42:04 UTC+2 schrieb Benjamin Smedberg:
> A native window is specifically something we do not intend to allow in
> any form (plugin, extension, etc). If you require that level of
> OS-specific behavior, you should switch to a native application.
Ok thanks.
> A native window is specifically something we do not intend to allow in
> any form (plugin, extension, etc). If you require that level of
> OS-specific behavior, you should switch to a native application.
I found out in the mean time that Googles PPAPI provides sandboxed plugins and lets draw windows in the browser. Trusted plugins outside the sandbox are possible, although cumbersome and complicated to load. At least as it seems, according to the documentation here:
https://code.google.com/p/ppapi/
I guess I'll try that first.
Sadly Mozilla is not interrested in PPAPI, according to the statement here:
https://wiki.mozilla.org/NPAPI:Pepper
:(
--
EL
miao...@gmail.com
Oct 13, 2015, 2:15:38 AM10/13/15
to
bna...@gmail.com wrote:
> All of these involve access dll's (or .so ) via JNI.
>
>
> What technology Firefox provides so I can migrate and continue to access/control hardware as i can now via dll's + JNI + Java Applets?
I agree with Fabio and I am very worried about the future, and the way we will deal with this.
> All of these involve access dll's (or .so ) via JNI.
>
>
> What technology Firefox provides so I can migrate and continue to access/control hardware as i can now via dll's + JNI + Java Applets?
We embed some applets that use that kind of features (If I can call this, a feature). Using JNI calls to enable access to scanner (TWAIN driver), smart cards (holding user certificats) and direct access to printer (which I should admit is something very specific, but we still need to have this possibility to make our application smooth and more user-friendly).
I am waiting for any help/sample showing us how to enable those features/capabilities again, but I am afraid you (mozilla) forgot the professional domain (versus public one).
Nicolas
0 new messages