Page tree
Skip to end of metadata
Go to start of metadata

Outdated page

We're leaving this here for the discussion it contains, but please help us update the new FireBreath 2.0 section of this website.

The Beginning of the End of NPAPI (last updated in 2014)

Many of you have no-doubt seen the news that Chrome will be phasing out support for NPAPI in the next year.

The FireBreath team thinks that that is a Really Bad Idea and welcomes any of the browser vendors to contact them directly via phone or email to discuss the reasons.

Unfortunately, we at FireBreath can see the writing on the wall. NPAPI is going away.  It shouldn't – there isn't a good replacement.  It's frustrating, infuriating, and implies a frightening disregard for the innovation that plugins allow on the web (to be confirmed after a review of PPAPI). Recent decisions by the Mozilla and Chrome teams, however, point a very clear finger that the browser development teams are declaring a relatively quiet war of attrition on plugins and they will be gone soon.  In addition, Windows 8 and later contains a modern mode (formerly called Metro) of IE that disables almost all ActiveX controls.

The conclusion is inevitable: We will need to change our approach.

EDIT: To clarify, FireFox has made it more difficult for NPAPI plugins, but when used properly Click to Play isn't that much of an impediment.  It definitely shows that they want NPAPI plugins gone, but they haven't (yet anyway) made any announcements that indicate any sudden or imminent demise of NPAPI support. Chrome is the only browser that has, and there is not much so far to indicate exactly when that will happen.

TL;DR:

FireBreath 2.0 will support current protocols as well as Native Messaging, but hypothetically could support any of the following

  • NPAPI
  • ActiveX
  • Native Messaging (using FireWyrm)
  • NaCL/pNaCL (if we can make it build, and will use FireWyrm)
  • Web Sockets (using FireWyrm)
  • HTTP Ajax PULL (using FireWyrm)
  • Telnet (using FireWyrm)
  • IP over Avian Carrier (https://tools.ietf.org/html/rfc2549) (using FireWyrm)

Major changes will include:

  • Everything will be asynchronous!

  • Calling a function on the plugin will return a Promise
  • Getting a property from the plugin will return a Promise
  • Calling into the DOM from the plugin will also be asynchronous
    • We have FB::Deferred<T> and FB::Promise<T> types which are based (very) loosely on the Promises/A+ spec
  • Drawing models will need to be developed, but will essentially be browser-based
    • WebGL, Canvas, possibly NaCL/pNaCL and/or emscripten, etc
    • Drawing models will also be asynchronous
  • FireWyrmJS will provide a simple abstraction for using a FireWyrm plugin from Javascript
  • FireWyrmJS will require that a WyrmHole (transport mechanism) be provided
    • The most common WyrmHoles we anticipate seeing would be ones for Native Messaging and js-ctypes
    • Many of these may require a browser Extension; we could probably create a FireBreath extension which would be usable by all

Other improvements:

  • Better cmake support (run cmake on your project, not on FireBreath)

The basic plan:

FireBreath 2.0 attempt to address several long-standing complaints about the framework as well as adding a whole new type of plugin support.  With the collaboration of the employees at GradeCam and other members of the community we've developed of the FireWyrm protocol.  This name was carefully chosen using the same naming methodology as FireBreath itself, which is top secret.  The point, though, is that the FireWyrm interface will allow a whole new type of plugin transports.

Adding support for the FireWyrm protocol involved a fair bit of complexity, but at its core it is actually a distinct thing from FireBreath -- it could be used in other projects, if someone wanted to.  In essence, FireWyrm is an advanced (but suprisingly simple) mechanism for performing RPC calls over an essentially text-based asynchronous transport protocol using JSON.

What does this mean?

You have three pieces to this system:

  1. FireWyrm client (FireWyrmJS will be our initial javascript implementation)
  2. FireWyrm provider (FireBreath's third plugin type, a sibling to ActiveX and NPAPI)
  3. A tranport mechanism for communicating between them, known as a WyrmHole

FireWyrmJS connects over a WyrmHole to the FireBreath plugin (through the provider) and gets information about the root JSAPI object; it then constructs a javascript object wrapper which can create a payload, send it over the WyrmHole, and return a Promise for all plugin calls.  (If you aren't familiar with the Promise pattern, and in particular the Promises/A+ spec, you may want to read up on it a bit).

What this means is that any transport mechanism that you can find that will connect the two points of code and send strings back and forth can be used to connect to this plugin.  On the C++ side a new set of FireWyrm provider entrypoints have been created which make it relatively easy to create the c++ side of the WyrmHole.  The initial implementation of a WyrmHole (nearly complete) uses Native Client in order to instantiate the plugin.  We'll essentially create a thin executable which will load your FireBreath 2.0 plugin using the FireWyrm entrypoints and will communicate with the browser, allowing you to use your same plugin.

Limitations:

I'm sure any of you that is actually thinking about what I'm proposing has already noticed that there are some deviations and challenges with this idea.  I'm not sure I've identified them all, but here are the things I can think of off-hand that will change or need to be addressed:

  • Initially, there will be no drawing model.
    • I expect this to change soon, particularly if others in the community help, but initially there will be no drawing model available to plugins using FireWyrm.
    • The first drawing model I expect to see will be implemented by sending a pixel buffer to the browser where it will be drawn on a Canvas
    • Eventually I expect that we will develop other drawing methods, such as:
      • WebGL proxied through the WyrmHole
      • Canvas proxied through the WyrmHole
      • Some other RPC-driven mechanism (perhaps we can find an existing one) compiled with emscripten and proxied through the WyrmHole
      • Some other HTML-based abstraction (controlled through the WyrmHole)
  • All operations will be Asynchronous
    • We will be relying heavily on the Promise pattern, both in C++ and JavaScript
    • We will be requiring C++11 (Primarily for lambda support) in order to make this hurt less
  • This will apply to NPAPI and ActiveX as well! This will be a relatively HUGE change
  • All property get calls will return a Promise
  • *All* method calls will return a Promise, though ones that return void it will only tell you it completed
  • Eventually we will attempt to find a way to allow calls to be batched in such a way that a series of operations can be sent at the same time and the code will continue when it's complete

--- Below is the previous version of this page containing brainstorms and info which was used to develop the above plans. It has not been updated in awhile ---

The alternatives, as presented by the browser manufacturers

The browser development teams seem to feel that dropping NPAPI support is acceptable for a number of reasons.  One of the main reasons is that a very small percentage of people use plugins; unfortunately, for that small percentage, there are no other good options (PPAPI may be a good option - to be confirmed).  Here are the options that they feel we should be able to use in their place:

(this list focusses primarily on Chrome since that's the most immediate, but the goal is to find a solution or conglomerate of solutions that can be combined to make a long term multi-browser solution)

Pepper Plugin API / PPAPI (without NaCL) (link)

We have confirmed that PPAPI will not work because while Chrome supports it they don't provide any way for third parties to install PPAPI plugins.  The only method of doing so involves a command-line argument, which is unsuitable for most purposes.

However, PPAPI can be used in conjunction with NaCL - see below.

Google Native Client / NaCl (link)

  • What it is: 
    • NaCl uses a special C/C++ compiler and the Pepper API (PPAPI) to allow the creation of mostly-native code that can run "safely" in your browser.
  • Pros:
    • Code should run pretty much at native speed
    • Sufficiently powerful graphics capabilities to run Flash
    • Can be packaged fully inside an extension and thus doesn't require a traditional installer
    • They are working towards a portable version (PNaCl) for mobile devices in the future.
  • Cons:
    • Only works on Google Chrome
    • Does not allow direct hardware access. Although WebRTC now allows access to video and audio capture hardware, and is becoming implemented in most browsers
    • 3-D graphical abilities exist (OpenGL ES2), but not full OpenGL capabilities
    • Does not allow raw TCP/UDP
    • Other browser vendors seem to have no interest in adding support
    • No synchronous javascript API; all communication with the web page is through asynchronous "messages"

Google Native Messaging (link)

  • What it is:
    • Native Messaging allows a Chrome Extension to exchange messages with native applications.  From the docs: "Native applications that support this feature must register a native messaging host that knows how to communicate with the extension. Chrome starts the host in a separate process and communicates with it using standard input and standard output streams."
  • Pros:
    • Allows running of native code, which presumably has full hardware access, native TCP/UDP access, etc
    • It should be possible to create an asynchronous bridge and abstraction to make this fairly painless from Javascript
    • Launches the application from the browser, so the user does not have to start anything themselves
  • Cons:
    • Only works on Google Chrome, no analogue in Firefox, Safari, or Internet Explorer
    • Two separate installers; the application (native code) has to be installed, and the extension needs to be installed.  The same installer could probably install the extension, but it then needs to be accepted by the user in the browser.
    • No easy way to get video back to the browser; could be a good solution to replace hidden plugins, but not anything with video.

Mozilla Extensions js-ctypes (link)

  • What it is:
    • js-ctypes allows application and extension code to call back and forth to native code written in C. Basically it allows you to call into a DLL or similar from your javascript extension.
    • The probable method of using this would be to create an analogue for Google Native Messaging that works in Firefox
  • Pros:
    • Allows calling native code from a Mozilla add-on without using NPAPI
    • Libraries may be included in the add-on bundle or located on the host system
    • Supports Javascript callbacks
  • Cons:
    • Only works on Mozilla products (Firefox/Thunderbird)
    • Requires shims for executing C++ methods
    • Life-cycle of library objects initialized within the "shims" is per method execution (deconstructor for objects is called after each method execution)
    • No support for large chunks of binary data
    • No drawing support

Web Sockets and an external application

  • What it is:
    • In theory, we could use websockets to connect to an application running on the local system and communicate with it, thus allowing that application to provide us with services that are otherwise unavailable in the browser, such as native TCP/UDP socket access, hardware access, etc.
  • Pros:
    • Allows us to communicate with native code
    • Works on the latest versions of the major browsers (Chrome, Firefox, IE, Safari, Opera, and their mobile derivatives) Source
  • Cons:
    • The application would need to be launched some how
    • No good solution for providing video
    • Possible security warnings with SSL sites since local server wouldn't be SSL
    • Only works on newer web browsers (TODO: what browsers support?)

--- This page is under construction ---

 

Features and capabilities needed that nothing above can address:

 

  • Capturing and displaying video from an unsupported (by the browser) hardware device

  • document scanning, used for document management both internal and customer-facing - requires access to TWAIN API (a 3rd party DLL).
  • What else?
  • No labels

52 Comments

  1. What about support for PPAPI (Pepper Plugin API)  https://code.google.com/p/ppapi/wiki/GettingStarted

    In reading some of the articles on Chromes dropping NPAPI support is seems this was their alternative solution. 

     

    1. That's Google Native Client / NaCl. The first alternative on this page. That 'alternative' only works for Google Chrome.

  2. At the moment (warning) Chrome has no security problems with accessing a local WebSocketServer from an SSL-Website. FF and IE do have!

  3. Why would the local WebSocketServer not be SSL?

    1. Because in order to make it SSL you'd have to package an SSL certificate, which anyone could then use to do some sort of man in the middle, which is a big security issue.

  4. I would like to reiterate what John Sokol said - Google is dropping support for NPAPI in favour for PPAPI (Pepper Plugin API) https://code.google.com/p/ppapi/wiki/GettingStarted 

    PPAPI and NaCl are not the same - they are just closely intertwined - hence the two related names of NaCl (i.e. salt) and pepper. NaCl is a was of running Native Code in a browser sandbox (in both Chrome Web apps and PPAPI Plugins) whereas PPAPI is a cross-platform API for plugins for web browsers (direct quote from https://code.google.com/p/ppapi/).

    This is good news - Chrome is not killing the idea of browser plugins, they are just dropping support for one form of plugins (NPAPI) in favour of another form (PPAPI).

    NaCl Chrome Web apps can be installed as a Chrome browser app or downloaded and run dynamically without installing, but neither of those options allow you to do what plugins offer - to install extra software alongside the browser that control rendering/performance of parts of a browser page. That is why PPAPI is separate and still very valuable in its own right.

    When I heard the news of Chrome dropping NPAPI, my first reaction was to check if FireBreath now enabled plugins to be created in the PPAPI format as well as NPAPI and ActiveX. Unfortunately, that is not yet the case, but I hope it will become the case. FireBreath has always been focused on making plugin creation an easier and more consistent experience, so enabling us to create both NPAPI and PPAPI versions of our plugins would be a godsend. The other technical point that will need to be addressed is detecting which browsers are installed and installing the appropriate plugin types, as is currently done with NPAPI and ActiveX.

    In light of this, is there any chance FireBreath will enable creation of PPAPI plugins in the future?

    1. If I can get a definite confirmation that PPAPI is a valid option for us to use without NaCl (which was not our original understanding) then this is the approach I will absolutely be pursuing.  I need to know that for sure, and so far I haven't heard more than speculation.  We're working on it.

  5. Unknown User (jenzinas)

    What's the current status for this? The thread on PPAPI on the dev list back in Oct. seems to imply that PPAPI is not going to work but this page has not been updated. Is that due to lack of time or lack of information?

    1. PPAPI will not work as there is no way to install a PPAPI plugin – they have to be installed by Chrome, and there is no way for third parties to do that.

  6. PPAPI will not work for me. We use a Firebreath NPAPI plugin to augment access to OS specific functionality for a document management system. Simple things like checking the modified timestamp of a file on disk, checking out files to the users profile folders, exporting a folder structure from the document management system to the disk (creating any needed folders on disk), etc... While some JS API's support such operations, they only do it in a browser sandbox.  Our users need to edit these files with applications like Excel, Visio and Autocad, so the files need to be on their filesystem, not hidden away in a sandbox. Looks like IE will be browser to use from now on. I never though I would be responsible for an app that "runs best" or "supported only" on IE. Other simple things like showing a progress bar on download, saving the downloaded file to a desired folder and not the downloads folder, putting text on the clipboard were only possible with an NPAPI plugin or Flash. Think long and hard for simple business applications before you make them a web app, unless you can commit to IE only. You can get 99% of the way there, but the last 1% without ActiveX and NPAPI will kill you. Business users do not care or know that their app runs in a browser or the desktop, only that it works like their Outlook, Word or Excel, and they wil lnot understand why your app has degraded functionality.

    Richard, I appreciate your efforts, but the advantage of Firebreath was that one code base supported all browsers.I am not about to be suckered into any Chrome only or Firefox only solution, especially since the corporate standard in IE, and I for one will not be pushing to change it.

    1. Note that most of what you're talking about can be done using Native Messaging. You can't pass binary data well, only json encodable, but it does give you communication with a native app with access to filesystem and devices.

  7. Unknown User (ofer)

    Where did you see that js-ctype "Life-cycle of library is per method execution (deconstructor is called after each method execution"?

    I see that they have load and close , so it make sens they keep it open as long as you use it.

    1. If you have additional information, please feel free to edit the page and add it (along with links)

    2. Yes, the wording is wrong - what was intended to be said is that the life-cycle of library objects initialized within the "shims" is per-method execution. I will edit the entry.

    3. Fixed.

      I realize that the particular "con" in question is not really a "con" per se; it is due to the nature of js-ctypes only supporting C methods. The reason I included that is because - in the context of this page - developers are most likely seeking to port their exiting codebase over to utilize a compatible solution, and in the case of js-ctypes I felt it important to note that the nature of how objects are handled will factor into using js-ctypes to interact with a C++ library.

      1. Unknown User (ofer)

        That's a big difference (smile)

        You can change your objects to be "global" so going in/out a c method will not deconstruct them

  8. Unknown User (jj11238)

    Hello.

    I use the firebreath, and with Google is dropping support for NPAPI, I need to change my application.

    I have a doubt. Firebreath intends to implement support for PPAPI?

     

  9. Unknown User (spike0xff)

    Looks like we are heading down the Native Messaging path too.  Our requirement is to provide document scanning (through TWAIN) on desktop machines.
    The data bandwidth can be large, but at least it doesn't need to be real-time or particularly smooth like video. 

    Maybe we can find a way to collaborate.

    We considered the web server/web sockets approach, and several competitors do use this as a solution.  The Captiva Cloud Toolkit installs an HTTP server that runs as a Service, accompanied by an SSL certificate so browsers will talk to it with HTTPS.  I'm just highly averse to installing a web server that runs all the time on an end-user machine.

    Does Chrome actually prevent us from installing an PPAPI plugin, or they don't document or support it, or we could technically do it if.. if... if... ?

    1. In short, we don't know the answer to this for sure.  Chrome does not provide any method of installing it as a third party, which may mean they hardcode a list somewhere and may mean they just keep the install methods secret.  Either way, it means that if you did manage to use it and they decide they aren't happy about that they can turn it off at any time.  To me, that nixes it as a possibility.

      1. Unknown User (mateli)

        Actually this also are a Chromium feature which means that however this is done, should be there in the Chromium sourcecode. Generally Chromium/Chrome lacks a lot of documentation and I had to dig a lot in order to figure out even how PPAPI and NaCl actually works. Perhaps some think that the code repository are documentation enough.

        Perhaps it will actually be less work to fork Chromium into a browser that keeps up with Chrome but have better plugin support? Adding FireBreath support directly into Chromium may be easier than adding Chrome/Chromium support to FireBreath. Also it would be really cool to have a browser that directly support a modern C++ API like FireBreath.

         

      2. Unknown User (mateli)

        This one is ugly but what about doing a classic DLL hook? Rename the flash plugin, install a proxy in its place that loads the flash plugin and any other configurable plugin? They could of course start check-summing the plugin but that could probably be dll-hooked to. 

  10. Excuse me if I am being a bit dim, but why is it a deal killer that PPAPI plugins need to be able to be installed manually by 'us'?

    I thought one value of firebreath is that we can develop one plugin that works across multiple browsers. This is not changed is it?

    Sure, firebreath did also streamline the packaging into a single installer - I can see how that would be broken. But do we need to throw the baby out with the bathwater?

    I would still be very happy if I could use firebreath to have one plugin codebase that works across ie and chrome etc. I would also be very happy if firebreath could help me create the unique plugin installer for chrome - even if I have to upload that to the chrome web store myself.

    I am in a similar situation with other software already - having a single codebase that has to be recompiled and deployed separately for various targets. That is as good as it gets with traditional installed software, and having the single codebase is the important part. 

    1. We don't know of a way to install a PPAPI plugin at all.  It's not just that we can't do it automatically, or that it requires a special installer – Chrome doesn't let you do it at all.

      PPAPI w/out NaCL is undocumented and not in any way supported or encouraged for use for anyone other than Adobe (for flash) and internal Chrome plugins, as best I can tell.  As I said above, I don't know exactly how the chrome PPAPI registration mechanism works, whether it's by file location, hardcoded list, or something completely different, but the point is that the Chromium team don't seem to want anyone third party to use it.

      If you can find a way around that little problem then I'm more than happy to see if we can find a way to build a firebreath wrapper for it =]

      1. Aah - my apologies - it has been a while since I had all the intricate details fresh in my head.

        I assumed PPAPI was what was used for their chrome web store, but that was wrong. I forgot that their web store supports NaCL, and NaCL uses PPAPI, but you can't use PPAPI w/out NaCL. And while I am clarifying, it is worth mentioning that https://developers.google.com/native-client/dev/overview says you can use NaCL for both web-store apps, and also for web applications that presumably require no installation at all.

        So could firebreath work with NaCL to help with creating web apps and maybe also with packaging apps (but not installing) for the developer to upload to the chrome web store? In retrospect, I suspect the answer is: yes it could, but it would come with the limitations listed above, and therefore, it is not yet clear if it is the best choice.

         

        1. I'm also not clear on what problems FireBreath would be solving at that point; NaCL doesn't have a way to directly interact with javascript, only to send and receive messages from the page.  Thus, I'm not sure if FireBreath would actually gain you anything.

          Basically this is waiting on someone giving me enough info or me getting time to actually work on the port of GradeCam's plugin to NaCL.

  11. Unknown User (spike0xff)

     

    So we've started prototyping with Native Messaging. We expect to basically proxy the plugin API across the NM pipe, using JSON or similar.  We will start with some experiments to understand the available bandwidth, and how synchronous and asynchronous communication interact: We need both (synchronous for methods, async for events) and they need to not interfere with each other.

    So question for Richard: Is it crazy to think about implementing our Native Messaging host as something like an NPAPI host, i.e. a fake/proxy browser?  We could even, I suppose, load the plugin dynamically.  The NPAPI host would have to serialize and deserialize JSON from and to local objects.

    I expect it to be much messier than that description sounds. For example, our plugin hands complicated objects, with native-code methods, out through its API to javascript.  Those objects can't just be 'serialized' over the pipe.  We could proxy them, but... javascript doesn't have destructors or finalizers, so it seems we have no way of knowing when an object dies on the javascript side.

    1. The mailing list/google group would certainly be a better place to discuss this, but in principle I don't know of any reason that we couldn't create some sort of a JSAPI-adapter for native messaging.  Basically on one side we could take a JSAPI object and serialize it to JSON (there is actually a function to do this already) and on the other side you could have javascript create an interface for dealing with that data.  Since if you're using native messaging you can assume a recent ECMAScript version which would make it possible to create a javascript object that would automatically "create" method calls that would get sent across; they could then throw an exception if a matching method wasn't found on the other side.

      1. Unknown User (mateli)

        What about graphical plugins that would need a part of the web page to draw on, would it be possible to somehow pass on a window handle or something? 

        1. From my understanding there is no way to expose an HWND through native messaging.  You could probably come up with a lightweight JSON API for drawing using canvas and/or webgl across it, but there is nothing built-in that I am aware of.

          1. Unknown User (mateli)

            Using Native Messaging + canvas/WebGL was discussed on the Chromium group and as the Native Messaging are quite inefficient that would become a problem. 

            One problem here are that Chromium are not using heavy-weight windows so there may not be a HWND to export, except for the entire web page component. 

            Perhaps doing something similar to Chrome Frame would be workaround here. Like grabbing the entire tab and use some lightweight but plugin-sporting browser component?

        2. Unknown User (hicla)

          Does the flash plugin create a HWND on windows chrome? That would be a good candidate to 'borrow' the HWND from

          1. Unknown User (mateli)

            As tabs run in separate processes, I assume that at least each tab have a handle, sending all graphics data to the main tread would be quite an overhead. Also the flash plugin are a separate process, so that to would have a handle.

            I am actually thinking about figuring out how to insert a plugin API in Chromium without any changes to the API. That code could be put in a so/dll and injected into Chrome, either by "dll injection" or a patching loader. Both PE (Exe) and ELF (Linux) executable quite easily be modified that way.

            If we could tap into the creation of a new browser tab, we could replace the entire engine with for example Qt WebKit which supports plugins, perhaps after loading the page and searching for object tags.

            As Chrome starts new processes for each tab this probably could be achieved by tapping into that and start a proxy process that either loads the chrome engine or a plugin-friendly engine.

            Another alternative would be to simply create a new Chrome-compatible browser based on Chromium. The Qt team are already working on a Chromium based project called Qt WebEngine, which probably will be far more enterprise-ready than Chromium. I would suggest tapping into that project. Perhaps we could even get them to add FireBreath as built in plugin API so we don't have to go trough that horrible NPAPI crap.

             

            1. Unknown User (christopher)

              I hate to chime in with bad news without an alternative idea, but I've been down this road with Chrome.  

              It might be different in the ELF case, but on Windows it will be difficult to get anywhere with DLL injection unless you start chrome with its sandbox disabled (which most people won't be doing).

              Each tab / subprocess, wrapped in this sandbox, guards its api function addresses pretty well.  It may be different now, since it has been a couple of years since I last inspected, but chrome was already patching / hooking its windows API calls, and would verify the expected hooks were in place (eg. compared the in-memory version with the on-disk image, only allowing restricted calls against known targets, etc) before allowing the call.  

              So, it won't just be the api calls you'll be trying to hook, but also hooking the already hooked hooks.

              Of course, with effort it's possible... but will be tricky (and likely fragile, once it is working – e.g. living in dread of auto-updates).  You'll be effectively trying to bypass the chrome sandbox, and will see plenty of "Aw snap!" windows during the attempt. (smile)

              Though, they do have that brief mention of launching with "--safe-plugins".  I don't know anything about that option, but it sounds friendly.  Maybe that could be a "blessed path" somehow?

               

  12. Hello everybody,

    I have been using FireBreath for quite some time, and this NPAPI deprecation was really a showstopper in our case. Eventually, I went with WebSockets, and here is my experience:

    • I built a javascript library that is going to take care of interfacing with your plug-in.
    • I used an installer to install the 'plugin' on every system (WiX Toolset for windows, Packages for OSX, RPM/DEB packages for linux)
    • I registered my 'plugin' as a system-wide URI handler
    • From the javascript library, I try to contact the known localhost websocket, if it's not alive, I create an invisible iframe with the URL pointing to your custom URI (ex. my-plugin://launch).
      • The browser will ask the user to allow launching of that application (THAT's the annoying part), but if you click 'always allow' it's completely transparent.
    • I wait until the websocket comes alive and I start communicating with JSON messages.

    (I used mongoose for the webserver library.)

    Perhaps FireBreath could evolve in these two sets of libraries? The javascript library plus the websocket abstraction layer?

    Cheers!

    1. I designed the same architecture as Ioannis. The problem I have encountered is that from HTTPS sites, web sockets (without TLS/SSL) are blocked, as well as XMLHttpRequests, iFrames or whatever you can think of. Even if your local server has an SSL certificate self-generated it will silently fail because it is not a trusted authority. You can add manually the certificate for the client, but you would need admin rights when installing the plugins.

      I haven't found a way yet to overcome this (I am going to use PNaCl for Chrome when they drop NPAPI), but I guess I'll have to do an extension for each browser if I want to access some functions (in this case contacting to a HTTP/WebSocket server in localhost from HTTPS sites).

  13. This is really bad news to me.  Last year I finished developing a NPAPI plugin for digital signature using Firebreath. The plugin allows the user to select  a certificate stored in the pkcs11 module and generate a PKCS#1 digital signature. This allows the user to digitally sign web forms and documents using CaDES, XaDES o PaDES.

    My plugin is used by a few thousand people in Costa Rica who are required to digitally sign some transactions and documents because of legal reasons.  We don't even publish the plugin in the Play Store because it is a very localized user base. As far as I know there is no standard for digitally signing inside the navigator. 

    Before starting developing the plugin I discarded the idea of using applets because I didn't want the user  to download and install the Java RT and also at the time it seemed that running applets was getting complicated because of security constraints in the browser.

    Now I'm considering again using applets instead of NPAPI plugins, but am not sure if the lack of support of NPAPI will also stop applets from working given that applets are run by a plugin.  As far as I know Chrome disables by default the java plugin due to security concerns.  I wonder if applets will suffer the same fate that NPAPI plugins. 

    I've read some of the technical options available in Chrome but I am concerned about cross browser support and about long time support.  I don't want to invest more time developing the plug again using another technology like Native Messaging just to find out that Google will phase out that technology in a few months.  

    I will appreciate any suggestion.

    1. Hello,

      I am working with a solution for digital signature too.

      I am trying NPAPI plugin, and I have some problems, is your project open source?

      Is there any simple code for digital signature to get some reference?

      1. Hello,

        My project is not open source, however the plugin part is standard code around Cryptoki API (Pkcs11) in Mac and Linux, and CryptoApi in Windows.  If you don't requiere smart cards then maybe the new Web Crypto standard fits the bill for you. 

        The following reference shows how to generate a Pkcs#1 signature using Pkcs11:

        https://nlnetlabs.nl/downloads/publications/hsm/hsm_node9.html

        The following reference shows how to generate a Pkcs#1 signature using CryptoAPI

        http://www.microsoft-questions.com/microsoft/Platform-SDK-Security/33770305/using-cryptoapi-for-generating-digital-signature.aspx

         

         

        1. Thank you.
          I am now working out it with WinCrypto, and it works.
          By the way, is it easy to keep the code out of firebreath? It is too heaven.
          It make a 100KB dll to 5MB..

          1. Well, my activex dll is just 1211KB and msi installer weights 636KB so I think maybe you are compiling in debug mode or something

            1. You are right.

              Under the release build, the DLL is only 1199KB.

        2. Thank you!

          I am now using Wincrypt API to do my job.

          Since my project would be used on any version of Windows, the Web Crypto my now be fit.

    2. Well, finally managed to reimplement my digital signature plugin for Chrome using native messaging.  My experience is that From the user point of view installation is more complicated cause user has to install extension from Chrome Web Store ( in Windows extensions can not be installed anymore from your own web site) and has to install host application in a separate step. From developer point of view implementation feels hackey.  In my case I had to implement an extension with a content script and background js.  Communication is done using Chrome messaging API.  Content script has to intercept all of the messages from the browser and forward them to background js, which forwards them to native message.  Responses from native messaging host go the other way around.  Page code has to change to work fully asynchronous, even for reading the most trivial property.  I my case I had to support syncrhonous and asynchronous mode in order to support NP-API/Actives, and Chrome.

      I wonder how long it will take before Chrome kills the ability to intercept browser messages from an extension's content script.... that technique doesn't feel particularly secure.

      1. There is reportedly a way to set something so that the user will be prompted to install the extension. It won't be installed automatically, but it's the next best thing.

        1. I detect whether extesion is installed or not using this code 

          $.ajax({ type: "GET", url: 'chrome-extension://xxxxx/manifest.json, async: false, cache: false});  

          This also allows me get the extension version

          manifest.json has to be declared in its own web_accessible_resources field

          If the extension is not installed or is outdated I show the instructions for the user to install the extension from the Chrome Web Store.  The user has to navigate out of my page, install the extension and then manually come back to my page.  Chrome also provides an inline installation technique, but I didn't to try it.

          To detect if the native application is installed basically I send a ping message as soon as my extension is initiated when the page finishes loading.  There could be timing issues with the previous technique if the response from the host application takes too long, specially if the browser has to launch it for the first time, so I wait 500 milliseconds in my page before using the extension.  If I don't receive an answer I asume the host application is not installed, but you can not rule out other causes like an antivirus interfering or the application crashing.

          There should be a more automatic way to do this ... like the way plugins use to work, sigh...

    3. Hello, Billy!

      We are trying to solve the same task. We developed NPAPI pluging for digital signing through pkcs#11 library on Windows, Mac and Linux.

      We faced with the problem that we don't still have sollution that would work without NPAPI.

      You've wrote, that you've already solved this issue using Native Messaging. 

      I want to give you offer. What do you think about licensing your Native mesaging solution for using in our product ? We could pay you for that.

      1. FireBreath 2 (in the refactor branch on github) already supports Native Messaging and is in use in production for a couple of companies now.  The documentation stinks and there is some work that needs to be done, but the functionality is all there if you're willing to do a little work on your own, particularly if you're willing to help with some of the documentation efforts

        1. Hello Richard,

          Thank you for your quick response and good news. We'll try to use Firebreath 2.0. I'll ask our developers for sure if they could help with documentation.

      2. Hello Nicolai,

        The functionality of the component I developed for Chrome is very specific for the needs of my applications therefore it probably would need some customization to match your requirements.  Installers definitely will have to be customized for your application. Next follows a short description of my component for you to see if it match your requirements.  If you are still interested send me an email to [email protected]

        The native messaging application I developed has the following functionality:

        • List X509 certificates in pkcs11 module.  Pkcs11 module is statically linked against the native messaging application therefore it means it can only handle one type of smart card.
        • Get an X509 certificate from Pkcs11 module
        • Generate Pkcs1 digital signature using pkcs11 module

        Besides the native messaging app you will have to install an extension from the Chrome Store. That extension mediates between the native messaging application and scripts in the web page that implements the UI.

        You can get a feel of the installation process in app.firma-digital.cr

        Also if you are still interested I can provide you a test certificate for you to try the full functionality of the component.

         

        Regards

  14. Thank you Rich for summarizing Pros and Cons of each approach!  

    After Chrome, Firefox also announced ending NPAPI support by next year.  As per official communication released by on Oct 10th 2015, "Firefox dropping NPAPI plugins by the end of 2016"   

    we seem to have reached to deadlock situation on proving alternative to one of client post NPAPI support by majors browsers. Let me start on my Question with honest disclosure that I somehow landed on FireBreath page somehow while searching for alternative solution to Java Applet currently being supported by Firefox but for limited time. 

    Little background - We have healthcare device data reading functionality implemented in Browser application for specific client need - ActiveX for IE and Java Applet for other two major browsers Chrome and Firefox

    1. ActiveX - Microsoft already announced ending support to their own creation with Edge , their new browser
    2. Java Applet - most of the Browser vendors announced their support to NPAPI. Chrome already ended support on SEP 2015 and Firefox ending support by end of 2016

    In view of no support for both the technologies, we are left with no other option but to explore / look for if HTML 5 Standard can support this need or Something other plugin based solution again.

    If anyone can provide more insights if Firebreath can be of help to us would be great

    Thank you in advance

     

    1. The firebreath-dev forum would be a much better place for this question / discussion.

      Note that Firefox has indicated that they will support Native Messaging, so FireBreath 2 should work fine with that as well.  Most likely your needs could be satisfied using a FireBreath 2.0 plugin.

      We just put up a new section on this site with FB2.0 info.