NPAPI Has Left the Building: What WingScan Users Should Know

February 9, 2015 "Spike" McLarty

Currently, our web-based scanning solution, Atalasoft WingScan, uses Mozilla’s COM technology NPAPI to run native code in the browser. Before now this was the only way to do any kind of TWAIN based scanning hosted in a webpage. Starting with Atalasoft SDK version 10.5.2, we are moving away from this technology and helping you do the same.

Why? Well the simple answer is this: Google is removing NPAPI support from their Chrome browser. Our goal here at Atalasoft is to have what we call “working software,” so we are taking this change very seriously. We have known this was coming since the announcement and Google appears to be staying on schedule. Read on to learn about the changes and about our new release to address this.

Google NPAPI timeline WinGScan

 

The next big change comes later this month, when Google plans to remove the whitelist (which doesn’t really affect us, as we are not on the whitelist).  Come April, they plan to disable the support altogether, unless the browser is in “developer” mode.

 

Google expects that by removing NPAPI support, their browser will become “Faster, More Stable, and More Secure” which is true.  I am sure there have been attacks on data using NPAPI, and I believe them when they say that a majority of their crashes occur when NPAPI is involved. Coincidentally, I also believe that this is part of a larger initiative to “aggressively encourage” developers to move to newer technologies that are actively maintained so that they can support on all Chrome-based devices. Any web application that depends on NPAPI can’t run on Android or Chromebook and that’s not what Google wants to see.

We can brag about all the time we spent investigating different technologies, but that isn’t conducive to tell you what is coming.  We have decided to move to a MSI that installs a tiny webserver on the client, which takes advantage of the fact that any browser can send HTTP/HTTPS requests to a webserver.

Once WingScan is installed, a very lightweight localhost webserver runs on the client machine, when a website makes a call to initialize, all of the resources and API are loaded dynamically.

                        

 

With the resources in place, the scanning transaction can begin. Here is a graph showing the complete transaction with the scanner:

 

 

A couple of the big wins that help all of us:

 

  • MSI Installer– Everybody has used an MSI. Users prefer that all browsers be supported once something is installed. As a result, we now support all current browsers (and whatever comes next) that can send HTTP requests.
  • IT Departments – Because we have switched to an MSI, IT managers can now push the installation to their entire network with a single action. This is a good solution for places where users are not allowed to do their own installs.
  • No more “Ancient Tech” – This change removes dependencies on Microsoft’s ActiveX as well as NPAPI, which are large legacy frameworks, with many known issues, and expensive to maintain.
  • Session Integrity – The new control allows for utilizing the original session from the browser. The image is submitted to the server using whatever HTTP/HTTPS stream originally started the interaction. Fun Fact: you would think it would be faster to go directly from the local server to the webserver, but it turns out not to be (We tried it!).
  • Unified Solution – Now, Wingscan has a single code path across all browsers. All browsers are handled the same and no browser sniffing is required; which should make our customer’s developers much happier.

This also results in some structural changes for WingScan developers. The first is that a localhost port is opened on the client machine. This is a fixed port and it only accepts traffic from a local browser and requires private key authentication from our server side controls (so it is not an additional security issue).  However it might raise alarm from some threat prevention software. Additionally, and unfortunately this also requires some breaking changes to our original WingScan API, as some of our functions now require standard asynchronous callback parameters, to allow for control of the entire scanning transaction.

This has been an exhilarating project for me, personally, as I worked with our parent company’s (Kofax’s) very talented engineering and QA resources, from all over the world, to deliver what I believe to be a high quality solution to the complex problem of scanning directly from a webpage. 

 -Spike_/\_

About the Author

"Spike" McLarty

Spike joined Atalasoft at the start of 2011, fresh from a decade running his (one person) company Dosadi, creating tools for TWAIN scanning and image processing, and writing the odd TWAIN driver. Before that, Spike climbed the technical ladder at Logitech for about 14 years, building compilers, image editors, TWAIN drivers, and a variety of applications. It adds up to about 20 years of Windows development experience. Spike has a BS and MS in Electrical Engineering from Stanford.

More Content by "Spike" McLarty
Previous Article
Why Writing an Emulator is Fun and Why You Should Too
Why Writing an Emulator is Fun and Why You Should Too

Steve discusses the process of writing an emulator and why you should.

Next Article
An Introduction Is In Order…
An Introduction Is In Order…

Hello – My name is Brendan Day and I am the Sales and Marketing Director...

Try any of our Imaging SDKs free for 30 days with Full Support

Download Now