At SPAB 2016, FileOpen CEO Sanford Bingham Asks Standards Publishers: "What Would a Standard for DRM Look Like?"

Posted by Sanford Bingham

Last week I had the honor of speaking to an international group of standards organizations at the Standards Publishing Advisory Board (SPAB) annual meeting, hosted by our partner IHS. Standards Developing Organizations, or “SDOs”, are responsible for disseminating the documents that describe their industry’s or their country’s standards for building, manufacturing, military equipment, and so on (in the U.S., you may have heard of ANSISAE, and ASME standards). Thanks to standards, we have consistency and interoperability in the products and systems we use every day. 

Because of the mission-critical nature of their content, standards publishers are among the most exacting customers a technology company can have, and the choices they make can influence which innovations are successful in the publishing industry at large. Our host, IHS, is one of the largest resellers of standards documents, aggregating the work of hundreds of SDOs and expanding their reach with ecommerce portals and other technical enhancements.SPABlogo.jpg

This may seem like a quiet, boring segment of the publishing industry, but it is anything but. At the heart of standards publishing is a conflict between making essential information widely available to the technicians whose jobs depend on it, and the necessity of earning and protecting revenues for the standards bodies and the publishing companies that serve them.

Opinions run strong among the different SDOs as to how to achieve these dual goals—use DRM technology to prevent unauthorized sharing and uploading to sites with pirated documents? Or pursue copyright enforcement through legal channels, after a breach has been discovered? These questions have led to heated debates among SDOs and standards publishers, but as a community they resemble the U.N., ultimately seeking consensus on important issues (which is, after all, what standards are about). 

From the Format Wars to the Race to Be Everywhere: 20 Years of DRM 

The SPAB audience included many long-time FileOpen customers, as well as DRM skeptics and smaller SDOs who are just beginning to explore technology to protect their intellectual property. Rather than get into a philosophical debate about DRM, I presented a history of digital publishing and the facts of where we are today:



The upshot of this 20 year history is that the publishing landscape has become so complex, it is impossible (or would be foolish) for a publisher to choose one distribution channel or file format to distribute their content. Worldwide, the market share of viewing devices and web browsers is fragmented and in flux, with no clear winner (for example, Windows still dominates the desktop OS market, Android vastly outpaces iOS in smartphone operating systems, and Chrome is inching out the competition among Web browsers).

Even Adobe Reader’s market share of the PDF viewer market is being challenged by a long list of 3rd party viewers, many of them implemented without full adherence to the published PDF specification, which can lead to unpredictable changes in document display and behavior. The fracturing of the PDF landscape is both forcing and enabling publishers to provide content in other formats. For example, the Chrome browser does not support complex or DRM’d PDF files, but does include the Flash runtime (even on Linux). Likewise, nearly all mobile devices now have an HTML5-capable browser, so the explosive growth of those devices also creates an enormous new delivery platform. But on non-mobile devices, the HTML5 environment is less secure than either Flash or PDF, so the new environment also imposes a requirement that delivery software positively identify mobile devices as such.

Playing Whack-a Mole with Copyright Infringers

Meanwhile, piracy of standards documents continues to run rampant. Several SDOs described efforts to scan the web for illegally uploaded copies of their content, then sending DMCA (Digital Millennium Copyright Act) takedown notices to the owners of the host websites. One SDO reported having sent more than 150,000 such requests with a compliance rate of less than 50% (most of the sites are outside of the US so not governed by the DMCA legislation). 

So what is a standards publisher to do, and what role can DRM possibly play? The complexity of the publishing landscape poses a big challenge, but also an opportunity to embrace that complexity and use technology to serve the widest possible viewing audience. We’ve been working with a select group of standards publishers to develop a protected publishing system that is invisibleflexible and future-proof. 

FileOpen DocServer (currently in beta) will enable publishers to deliver content seamlessly to the widest range of devices and viewers, with the degree of security they choose, for the best possible end-user experience. Instead of publishing documents based on predictions of users’ devices and platforms, DocServer is based on a “detect, encrypt, deliver” model that serves documents dynamically based on the end-user environment. 

Ultimately, our goals are aligned with those of the standards publishing industry—to enable a frictionless experience for the users consuming documents, while employing technology quietly in the background to preserve the intellectual property and revenues of SDOs and publishers. I closed my talk with a question for the audience: “What would a standard for DRM look like?” We are looking forward to working with our partners to solicit feedback and help define a standard for DRM—because often real progress is the product not just of competition, but of consensus. 


Contact Us for a sneak preview of "The New DRM"--FileOpen DocServer

Topics: FileOpen, drm, pdf, Rights Management, Standards Publishing, SDOs

Accessing FileOpen-protected PDFs in a Web browser

Posted by FileOpen DRM News

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.


Contact us if you are interested in learning more about this functionality, or request a free trial.


Topics: Secure Document Viewer, pdf, Browser

FileOpen Client 0926 for Adobe Acrobat/Reader (Windows)

Posted by FileOpen DRM News

We have released an updated FileOpen Plug-in for Adobe Acrobat and Reader, Build 0926.   This new client implements support for the latest Adobe Acrobat/Reader on Windows. Specific improvements include:

    •  Bug fixes related to Offline Permission and enhanced support for Acrobat/Reader XI
    • Assorted minor improvements and enhancements

 This update replaces the Windows 0925 release from October 2012.

FileOpen Client 0926 is backward-compatible to Adobe Reader/Acrobat 7.  While not always necessary, we encourage users to uninstall previous versions of the FileOpen Plug-in prior to installing the latest. 

Topics: Client Release, pdf, plug-in, Adobe Reader 11, Acrobat 11, adobe

How to send PDFs securely by email (a step-by-step guide)

Posted by Diana Holm

We are frequently asked by prospective customers how to prevent “forwarding” or “saving” a PDF file attachment. Our view is that attempting to actually block a PDF file from moving around is doomed to fail, given that the format’s first name is “Portable.” Furthermore, there are times when forcing users to enter a document-specific password, or to remember a login to a secure website, is impractical and not terribly secure either.

So we invite these prospective customers to try out our FileOpen RightsManager system and tell them to follow these steps to send emails securely:

    1. Select a PDF or group of PDF files and encrypt them from the File>Encrypt New File menu.
    2. Import your list of email recipients (Users) using Outlook or a spreadsheet.
    3. Organize your Users into Groups if not all users should have the same permissions
    4. Organize your Documents into Groups if not all Documents should have the same permissions (remember that Users and Documents may be in more than one Group)
    5. Apply permissions policies to your Groups (expiration, printing restrictions, etc.)
    6. Send your users a one-time registration PDF, which will register the User on the device where they open it. If those users have not already installed the free FileOpen plug-in they will be prompted to do so by Adobe Acrobat/Reader.
    7. You are now free to send your secure PDFs to your users, which they will be able to open seamlessly with no additional passwords on the registered machines.
    8. The nefarious user who tries to save an unencrypted copy or forward the file to a friend will be foiled, as the recipient’s machine is not registered. 

Here's a screenshot that shows the policy management interface in FileOpen RightsManager:

FileOpen Hosted Screenshot resized 600For more details on how FileOpen enables secure PDF email attachments, check out our new whitepaper, “Using FileOpen to Prevent Pass-Along of Emailed Documents.” 

Topics: pdf, email, security

FileOpen for Handhelds

Posted by Sanford Bingham

This week FileOpen Systems is releasing FileOpen Document Control fileopenbbfor Blackberry™, the first of several implementations of our software for handheld devices. This product release is the first example of general architecture that we expect will permit the expansion of the FileOpen footprint to include a variety of devices and systems. The key idea behind this design can be summed up as “Adapt to the incumbent viewer.”

This is not a new idea, of course: FileOpen has always adapted to the incumbent PDF viewer on the PC/Mac/Linux platform, which is Adobe Acrobat/Reader. However, there currently is no Adobe Reader for Blackberry™. Adobe has released a viewer for the Android OS, which also uses the Java language, so the possibility exists that we’ll see an Adobe Reader for Blackberry™ in the near future. At the moment there are two incumbent viewers on the BlackBerry™ platform:  BeamReader ( and RepliGo ( Neither product is free (both cost about $15 for a perpetual license), but both do a good job of rendering a PDF entirely on the local device.

Our initial intent had been to create a “FileOpen PDF Viewer” for the BlackBerry™, i.e. to display documents in our own application. However, as the development got underway we discovered that the BlackBerry OS doesn’t permit more than one application to be registered for a particular file type, so if we were to deliver a FileOpen PDF Viewer any user who installed that application would be forced to use it to display all PDFs (even those not encrypted by FileOpen). We could also have changed the file extension from PDF to something else, but doing that violates some of our core design principles (we work with native formats) and doing so for only one device would be a recipe for end-user confusion.

Even if we could, FileOpen Systems has no desire or incentive to displace the incumbent players in the BlackBerry™ PDF viewer market, or even to favor any single player over any other. So we decided on an approach that would allow our application to work with any and all viewers that support the required Java Mobile Edition (JME) functions for interapplication communication. On BlackBerry™ devices where a compliant PDF viewer is present, PDF files encrypted by FileOpen can now be authenticated and modified by our application, then opened and displayed in the incumbent viewer.

Going forward we think this approach will simplify the development of solutions for other handheld devices. Look for more announcements in this space in the coming weeks.

Find out more about FileOpen Document Control for Blackberry™

Request a 30-Day Free Trial of FileOpen Document Control for PDF and Blackberry™!

Topics: document control, FileOpen, blackberry, drm, pdf security, pdf encryption, pdf, RIM