The Web browser you are reading this article on is a small wonder of engineering. Its origins can be traced back almost a quarter of a century, and is now one of 100+ available browsers serving over 360 million internet users. With those statistics one can only imagine the rate of change when it comes to browser development. Most of the time browser development improves user experience; making it faster, safer or more secure to surf the Web. However, sometimes those advancements cause users to change their workflow or expectations on how a browser should behave. In this post we are going to take a look at recent developments that affect users opening FileOpen-protected PDFs in a Web browser and how FileOpen is adapting to this change.
Say goodbye to NPAPI and ActiveX plug-ins
The presentation of PDF files in Adobe Reader within browsers has always been a somewhat odd and complex system. It works by Adobe installing a plug-in to the browser, generically the “Acrobat Helper”, which registers for the MIME type PDF and when the user clicks a link to a file of that type the helper launches or invokes the installed Adobe Acrobat/Reader program giving it the coordinates of the browser window. Acrobat/Reader then opens the PDF in an external window overlaying the window of the browser, such that the PDF appears to be displayed by the browser. When the file is encrypted using FileOpen the same thing happens with an added step of the FileOpen plug-in performing authentication and key retrieval prior to Acrobat/Reader displaying the file.
The above architecture was introduced somewhere around 1999 and has remained relatively unchanged except for some minor developments over the years. Recently, Chrome and Firefox have both deprecated NPAPI plug-ins, i.e. the mechanism by which the Adobe Helper operates, and both have integrated a native PDF viewer into the browser. It is still possible to configure Chrome to use the Adobe Acrobat/Reader as a PDF handler outside of the browser, but this advanced configuration will also be deprecated before the end of the year. Further, the new Microsoft Edge browser does not support any plug-ins, so Adobe cannot inject a mechanism to invoke Acrobat/Reader for PDFs opened in that environment (though Windows 10 also ships with IE 11, which does support Adobe integration). The bottom line is that Adobe or any other PDF Viewer that operates as a Plug-in is being excluded from the latest browser releases, and therefore FileOpen is being excluded as well.
No, the Web isn’t going in reverse and losing features. Instead, browsers are now supporting PDF files natively in the browser; they are just not quite there yet. In nearly all cases this support does not include handling of complex PDF structures like forms, multimedia, or Security Handlers. So the user experience with PDF has become unpredictable, and demands system configuration, in ways that affect not only our solution, but every solution including Adobe’s own DRM. While FileOpen offers support for a number of other viewers (Foxit, Nuance, Nitro, Bluebeam, Tracker, etc.), neither we nor any other vendor can open encrypted files in the native Google Chrome, Apple Preview, Microsoft Edge or Mozilla PDF.js viewers. We expect that this situation will only get worse over time, so alternative approaches should be considered.
Anticipating this, some years ago, we developed a set of technologies to convert PDF in real-time to renditions in Flash (.opn) or HTML5 (designed for clientless mobile delivery). FileOpen customers are provided with a set of tools to do browser fingerprinting and detection which in combination with their defined policies, determines which format is most appropriate to the requesting user and device. Alternatively, we have added support for “encapsulation”, in which the encrypted PDF is placed into an unencrypted cover page that will display in any viewer and can be used to give the user some explanation of what needs to be configured and/or a link to the same content in one of the Web-friendly formats.