Microsoft RMS: Standard or Stranglehold?

Posted by Sanford Bingham


pdf.pngSave a print-friendly version of this post (PDF)


“Standards allow different layers to evolve independently and therefore faster and better.”

- Sir Tim Berners-Lee, Founder and Director of the W3C


The World Wide Web is built upon standards, at every level. Because of Web standards, users can access information from multiple different browsers on a variety of platforms and operating systems, and organizations can choose from a diverse set of servers and databases to host content. This arrangement has worked well for more than twenty years, encouraging innovation and competition—as long as the information being served is intended to flow freely and without restriction. However if the contents’ owners want to control access to their information through encryption and authentication, the interoperability of the Web breaks down. The means of decrypting content for secure viewing has always required a separate, proprietary viewer or plug-in, because there is no Web standard for rights management at the file level.w3cSmall.png

Opinions differ on the wisdom and feasibility of implementing DRM for consumer content on the Web (although the channeling of rights-managed content into closed platforms such as Amazon Kindle and Apple iBooks has rendered opposition somewhat futile), but the absence of a security standard in the enterprise has created a vacuum into which a private corporation (namely Microsoft) could come to dominate the creation, distribution and consumption of information from end-to-end. Imagine a scenario in which the entire document workflow of the Fortune 1000 is beholden to a single vendor for its authoring applications, user identity management, decryption keys, usage data and other private and proprietary information.

Aside from wiping out entire categories of cloud storage platforms and security vendors, a private monopoly in rights management technology would prevent its customers from choosing among workflow and server technologies, and put their data at risk of a potentially catastrophic security breach if any vulnerabilities were exploited. The vast majority of encrypted documents would be secured with a single proprietary method. Further, such a monopoly would threaten the fundamental framework of the Web, which was originally designed to enable servers and clients on different platforms, from different vendors, to speak to each other in a common language. Without a published standard for handling encrypted documents on the Web, it becomes possible, even necessary, to limit usage to a single viewer or editor—the one sold by the same vendor of the productivity suite, identity framework and encryption tools.


The Mirage of Cloud Security

How could we be at risk of a rights-management monopoly, when the cloud era has disrupted incumbent vendors and the dominant players now encourage integration via open APIs? In his blog post from 2013 “The Rise of The Cloud Stack,” Aaron Levie of Box proclaimed “From this diversity of systems, customers will get choice, and with this choice we’ll see better applications and solutions emerge. At a lower cost, and at a higher quality.” The cloud stack was supposed to free us from single-vendor “ecosystems” so we could migrate between increasingly sophisticated platforms. But as we will see, the lack of a standard document security protocol has instead resulted in a Babel-like city of secure towers that don’t speak the same language, and therefore can’t interoperate.


First, let’s look at how cloud services handle user identity management, because any workable rights management scheme depends on user identity to determine whether or not to decrypt a file. One of the keys to the evolution of the cloud stack is the availability of what Gartner Group has named Identity and Access Management as a Service (IDaaS). Using an IDaaS service, a company can create a Single Sign-On (SSO) system for a variety of different, and often interconnected, cloud applications. With a single login, a user might now update a record in Salesforce, triggering an alert in Slack, updating a spreadsheet in Google Docs and a report in Box.

From the perspective of a network administrator, it is necessary that these new workflows also be auditable and their use controlled. So the “Access Management” part of IDaaS has become an important new element of the information security toolkit. In the example above, it is also critical that the administrator be able to revoke access to all the applications in that workflow all at once. In the current environment the granularity of IDaaS is normally at the application level; i.e. the IDaaS vendor controls access to the cloud provider itself, with that cloud provider managing access internally based on the identity provided.

In some cases, the cloud vendor may implement access control at the document-level, but the identification and permissioning of documents is specific to that environment. That is, there is no mechanism exposed by IDaaS vendors by which a document exported from Google Docs and imported into Box or Dropbox can be tracked or controlled as it moves from one environment to the next. Every cloud provider that offers some form of DRM is an island, and every protected document is trapped on that island.


RMS: Bundling Security and Identity

If there is no standard for document-level security in the cloud, what about behind the firewall, in the enterprise? There are multiple competing approaches to Enterprise Document Rights Management (EDRM), including the one developed by my company, FileOpen Systems. Each is functionally a silo; there is no standard for DRM interoperation. Among the EDRM solutions, the largest (by installed base or market share) and best-known framework is Microsoft Rights Management Services (RMS). It can certainly be argued that RMS is the de facto standard for controlled distribution of MS Office documents; the question is whether it can or should be the basis of a more formal web standard.

Microsoft RMS is a framework for DRM implemented natively in the Microsoft Office suite of products and also by third parties for some PDF viewers. The RMS software was introduced in 2003, evolving from and ultimately replacing an eBook DRM system, Microsoft Reader, which was introduced in 2000 and discontinued around 2007. Today RMS is predominantly, perhaps exclusively, focused on enterprise use-cases and workflows. The functionality was originally bundled into Windows Server 2003 and remains a part of the core Windows Server product. The RMS system is also tightly integrated with Microsoft's Active Directory product, indeed is formally named "Active Directory Rights Management Services" (AD RMS).


The tight integration of RMS with Windows Server has impeded adoption by entities not primarily using the Microsoft stack; RMS cannot be implemented directly in environments using Linux, or other Unix derivatives, at the server. Further, the reliance upon Active Directory has reduced the utility of the system for external document distribution, insofar as the Active Directory environment of the document creator and that of the document consumer are rarely integrated. Microsoft is now addressing this concern via the federation of Active Directory networks using Azure Active Directory (Azure AD) and the cloud version of RMS (Azure RMS). These cloud-based systems for identity management and DRM are intended, among other things, to simplify the process of distributing encrypted content outside the firewall.

Microsoft has also integrated the RMS functionality into a number of clients on desktop and mobile platforms, under the banner “Office everywhere, encryption everywhere.” This initiative addresses both document security in the MS Office suites and message security in the Microsoft mail clients, via S/MIME. Viewing of RMS-protected documents on iOS can now be done in third-party viewer applications or with Azure RMS in the Microsoft Office applications for Mac, iOS and Android.

Support for PDF files in the RMS environment is implemented via partners, including Foxit, Nitro and Nuance, and in Adobe Acrobat/Reader via a plug-in from GigaTrust. RMS-encrypted PDF cannot be opened in the Microsoft Reader application, which is the default handler for PDF on Windows 8.1 and later, nor by the embedded PDF viewer in Microsoft Edge (or any other browser).


Standard or Stranglehold?

The presence of the RMS client in the primary Microsoft Office applications enables workflows in which effectively any user can distribute encrypted content to any other user, without a requirement that either install new software. No other DRM system can make that claim. And while this situation is reminiscent of Microsoft’s bundling of Internet Explorer with Windows, which was ultimately sanctioned by the US courts, the integration of Microsoft’s DRM into Microsoft’s Office applications has not been the subject of any antitrust actions. So it is likely that the bundling will continue, and continue to be an advantage for Microsoft in the enterprise, as long as Office remains the primary vehicle for document creation and collaboration.

Similarly, the bundling of RMS with Windows Server and Active Directory is not optional, as the RMS functionality depends upon proprietary logic in the Microsoft Server stack. Use of RMS with any alternative webserver is not supported. We assume that Microsoft tightly integrated the RMS client and server functionality in order to increase the security and reliability of the system rather than as a competitive strategy, but the result is indistinguishable. There is no set of APIs and no licensing framework that would permit an independent vendor to create an alternative to the Microsoft implementation of RMS in Windows Server, or a cloud service that could be used as a replacement for Azure RMS.

While the original on-premises version of RMS required use of Active Directory for identity provision, the Azure RMS product offers the option of a federated identity mechanism, meaning that other IDaaS vendors can be integrated into an RMS workflow. However, by design, all DRM interactions involving the Azure RMS client/server exchange require a token from the Azure RMS server. So while an alternative identity provider may be provisioned, there is no mechanism in either RMS or Azure RMS for that identity provider to also manage the permissions on the document. In short, the RMS client and server cannot be decoupled.


As a result of these Microsoft design choices, it is not possible for an entity that chooses not to use Microsoft Server to implement RMS inside the firewall, nor is it possible for an entity using Azure RMS to operate with full independence from Microsoft. An IDaaS vendor can provide primary identity management, but cannot independently provide access control at the document level, as this capability necessarily involves the sharing of user and client data with Microsoft.


An Alternative: Standards-Based DRM

Microsoft’s approach is fundamentally at odds with the core design of the World Wide Web, which is premised on the loose coupling of client and server functionality. It is, for example, inconceivable today that a browser vendor would attempt to require use of a particular, and proprietary, server in order to implement SSL. An entity publishing data on the World Wide Web today can exert complete control over the code used at the webserver, to the point of having the option to write that code anew in any language and run it on any hardware, provided that the result properly implements the required protocols, all of which are public.

It follows that any attempt to create a standard system for DRM on the World Wide Web would, at a minimum, need to support this degree of client/server independence. However, DRM systems are rarely designed around open interfaces, at least partly due to a tendency to think that the most secure system is one in which the developer has control over both ends of the client/server interaction. Moreover, DRM differs from standard cryptographic implementations because one side of the interaction, the client, is not necessarily a willing participant in the secrecy of the conversation, and indeed may be an adversary.

So a completely open source DRM system is likely to be impossible. What can work, as demonstrated by the implementation chosen for the W3C Encrypted Media Extensions (EME), is the combination of a compiled binary client library and an open interface to an arbitrary key management system. EME is now embedded in multiple applications and platforms, and allows content distributors to manage protected video files using one or a combination of key management and delivery systems (Google Widevine, Apple FairPlay, Microsoft PlayReady, Adobe Primetime, etc.)


The FileOpen Rights Management Layer

The original design of the FileOpen DRM software, first articulated in 1997, described the same general architecture. FileOpen rights management was explicitly designed to work with any external identity provider, and to permit the entity encrypting documents to specify all relevant metadata (e.g. document identifiers, encryption keys). In the company’s early years, the only way to implement FileOpen software was to develop a custom server to manage customer and document identities and to implement business logic governing usage. Today, commercial "PermissionServer" implementations are available in .NET and PHP, and multiple cloud services are built around the FileOpen Client and protocol, which is published.

The architecture of FileOpen rights management is such that is not tied to any particular document format or viewing application. This differs markedly from Microsoft’s approach, which developed RMS for its own Office applications and has demonstrated a clear bias toward those applications with respect to competing tools (e.g. LibreOffice) and formats (e.g. PDF). We believe that decoupling the rights management protocol from the document format and viewer vendor enables organizations to share documents securely with the broadest set of users, inside and outside the firewall. It also protects publishers and document creators from a potentially costly “lock-in” to the format vendor, who would control the keys to encrypted documents and store private data about their end-users.


Moreover, because the FileOpen software does not rely upon any particular identity provider, it can be implemented natively by any IDaaS vendor. All such implementations are independent and private, in the sense that information about users/documents/permissions is fully controlled by and visible only to that vendor. Interoperation between IDaaS implementations, or between IDaaS vendors and cloud application providers, or between different cloud application providers, is likewise possible without direct involvement of FileOpen Systems, using the published interfaces of the system.

While FileOpen rights management is not yet a standard, it was designed and continues to be developed around the principles that underlie Web standards. In fact, one of the first and largest sectors to standardize on the FileOpen software is the community of Standards Developing Organizations (SDOs; e.g. ANSI, ASME, Afnor, DIN, etc.). Ultimately, the FileOpen software was designed not to be an end-to-end secure publishing system, or even a complete system for DRM, but a flexible component that can be integrated to extend the functionality of such systems--one thread in a larger, interconnected, Web.


Learn more about FileOpen rights management architecture and implementation options for Microsoft Office documents

Contact us for a demo of FileOpen Rights Management for Office



Topics: document control, drm, Rights Management, cloud, Microsoft RMS

FileOpen Client 0971 Released (Win Plug-in to Adobe Reader)

Posted by Diana Holm

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

  • Modifications to behavior of messageboxes and dialogs.
  • Modifications to print dialog and controlled-print functionality.
  • Modification to behavior of watermark imposition on editable documents. 
  • Additional bug fixes and enhancements.

This update replaces the Windows 0969 release from November 2015.

FileOpen Client 0962 is backward-compatible to Adobe Reader/Acrobat 9.  We recommend that you encourage users to upgrade to the 0971 client.



How to Track Printed Documents Using FileOpen Dynamic Watermarks

Posted by Diana Holm

When Adobe announced the PDF file format as an open document standard in 1993, it was meant finally to usher in the era of the “paperless office.” Despite the success of PDF as a platform-independent document format, we are still printing to paper—a lot. According to The Paperless Project, paper usage is increasing in American businesses at a rate of 22% a year, and the average office worker uses a “staggering” 10,000 sheets of copy paper annually.watermark200.png

This poses a unique challenge to publishers, who increasingly depend on the usage data and analytics which digital documents can provide, but not printed documents. For example, if a publisher sells a subscription of valuable research reports to one employee at a company, how do they know that employee isn’t printing out hundreds more copies, depriving the publisher of that additional subscription revenue?

Encrypting those research reports so that only the original subscriber can access them makes it harder for a user to share access to the digital version. FileOpen makes it possible to disable printing entirely, but if you allow the document to be printed and want to solve the rogue printing problem, you’ll need to take advantage of FileOpen’s advanced printing restrictions and watermarking features.

In this post we’ll walk you through how to limit printing of FileOpen-protected documents, and how to impose unique watermarks on each printout with user-identifying data. Using “dynamic” watermarks, you can auto-generate watermarks at the time of encryption and delivery, to include rich data which could be used to track a printout back to the user, time and device on which a document was printed.

How to Control Printing 

In FileOpen RightsManager and RightsServer, you set printing permissions according to the access control policies you define for your different groups, or recipients. So rather than assigning printing restrictions to the actual documents, you can give different recipients different levels of printing privileges to the same document.

Your options for restricting printing are:

  • Enable/disallow any printing
  • Set a notification when a document has been printed
  • Set the maximum # of print copies allowed
  • Specify which pages or page-ranges can be printed
  • Restrict printing to only physical devices (no print-to-file), or only to specific “whitelisted” printers
  • Set a percentage of the document you will allow to be printed
  • Print documents as lower resolution images so they are a degraded version of the original
  • Simply monitor printing activity, without limiting # of prints or prohibiting any print drivers

All of the above printing permissions require that the end-user be online. RightsManager and RightsServer also have offline permission settings, which can be used to allow or disallow offline printing, and to cap the number of prints allowed while the user is offline.


FileOpen RightsManager offers a great deal of flexibility over printing, including the ability to render printouts in a lower resolution. 

You don’t have to set printing restrictions in order to use watermarks, but they add an additional layer of control to your valuable documents. Now, let’s move on to adding watermarks.

How to Add Watermarks

Prior to the development of the current FileOpen watermarking mechanism, some implementations of the system added watermark text to a PDF prior to encryption, then encrypted that PDF uniquely for a specific user. We refer to this as Static Watermarking and Dynamic Encryption. That is, the watermark text is static (always remains the same as what was imposed originally), and the encryption is done in real-time, or dynamically.

The current system implements Dynamic watermarks, and can be used either with Dynamic or with Static Encryption. That is, the text of the watermark can change each time the document is opened, and this can be the case whether the same encrypted PDF is opened by multiple users, or a unique encrypted PDF is created for each user.

Within any particular watermark policy, there is a similar distinction between static and dynamic text, both of which can be used simultaneously on the same document:

Static Watermark Text: These contain information you define in advance when you are setting up permissions policies for your recipients. They can contain a copyright message or any text you please. This text is literal, i.e what is specified in the policy is imposed into the watermark.

Dynamic Watermark Text: Dynamic watermark text is generated “on-the-fly” when a user opens or prints a document. This text typically contains information specific to the user, e.g. name or email address. This information is retrieved from the PermissionServer database and sent to the Client as part of the document open or print control event, so can be changed even after document delivery, e.g. for example to notify an end-user that a newer version of the document is available. FileOpen SDK licensees can take advantage of a rich syntax to dynamically place watermarks using data such as the machine ID of the user, IP address, and printer name/port that they used.

For the purposes of this post, we’ll walk through the process of generating watermarks using the WebUI of FileOpen RightsManager and RightsServer.

1. Create a Watermark Layout Template

The first step is to configure a Layout Template for your watermark (Watermarks > Layout Templates > Add Layout Template). Here you can choose whether to make your watermark a “Stamp”, in which case it will be superimposed on top of the document contents, or a watermark that is imposed beneath the text of the document. You can also define the watermark’s type (header, footer, diagonal up, diagonal down, vertical left up or vertical right down), the font (also the size/fill-color RGB, stroke width, stroke color RGB) and the aligment (left/right/center).

2. Create a Text Template

Next, create a Text Template to define the content of your watermark (Watermarks > Text Template Sets > Add Text Template Set). Here you can choose whether to date and time stamp each printout, include user-identifying information, etc. User-identifying information can include their email address, username, full name, company, IP address, printer ID, and many more data points.

Together, your Watermark Layout Template and your Text Template make up a Watermark Set.

3. Apply a Watermark Set to a Policy

Navigate to Policies > Watermarks. Click on the Policy Set you want to apply your Watermark to. For example, you might have a Policy Set for a site-license subscription, and want to add the watermark to all documents associated with that policy.

Applying watermarks at the Policy level frees you from having to create multiple different versions of the same document, because the watermark floats above the document as a separate object, and can be changed or removed even after delivery. When you assign your watermark to a Policy, you can define a different watermark for digital viewing and print, or only include the watermark on the printed version.

Here is an example of what your watermarks will look like on the resulting document:


This example shows a printed PDF with both static and dynamic user-generated watermarks, visible in the header and footer of the page.

You can make your watermarks as noticeable or unobtrusive as you like using the design controls in Watermark Layout Template dialog.

The Result: Smart Printed Documents

By leveraging FileOpen’s print controls and watermarking features, you can close the loop on unwanted printing and reproduction of your documents. Including unique user-identifying data in your watermarks will render every printed copy of your document traceable back to the original user—even copies made with a photocopier. Because the watermarks appear below the text, they cannot be “whited out” without visible degredation of the document content. Watermarks not only reinforce your permission policies on the printed page, they provide you with actionable data on how your valuable and confidential documents are being used.

FileOpen’s print control and watermarking features are bundled with our RightsManager, RightsServer and SDK products for encrypting and controlling access to documents. FileOpen watermarks can be used on native PDF files for viewing/printing in Adobe Acrobat and Adobe Reader(end-user plug-in required), and on OPN files for viewing/printing in any web browser with no plug-in required.

Contact Us for a demonstration and consultation of FileOpen's watermarking and security features. 


Topics: document control, watermarks, watermarking, printing control

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

FileOpen Plug-in Update Available for MAC OS X

Posted by Diana Holm

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

  • Support for Adobe Acrobat Reader DC (64-bit architecture, with Broker process).
  • Modified and improved installation program.
  • Improved multi-language support.
  • Various bug fixes and other enhancements.

Note: This version supports Adobe Acrobat/Reader versions 8 through DC and 2015, and OS X versions from 10.6 through 10.11 (El Capitan), however B967 is installed only for Adobe 10 and up on OS X 10.9 and up. The installer delivers B958 for the remaining Adobe and OS X versions where B967 cannot be used.

This update replaces the MAC 0958 release from April 2015.

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

Revoke or expire document access with FileOpen DRM

Posted by FileOpen DRM News

Today we are very much digital citizens with the world’s information at our fingertips; we are always on, operating in real-time.  The amount of data we produce is staggering.  Every time we share, copy to the cloud, re-name, edit and redistribute a file, we are scattering data. Often times this choice is made out of convenience rather than security or future data management work-load.  To put this into context, I logged into my personal Google Drive this morning.  I found sensitive and proprietary information in documents shared with me from former co-workers, bankers, lawyers and agencies that was no longer of great importance to me, but could cause significant damage if stolen, given to a competitor or otherwise abused.  While my example may not make big headlines, there is ample cause for concern.  As of this morning, there are 39,100 PDF files indexed by Google that have “not for public release” in the title.

While all of these documents may not truly be a security concern, they are just a result of one Google search,  and do indicate the magnitude of each document owner’s data sprawl; which, as a whole adds up to a serious vulnerability.   A vulnerability that can lead to lower business productivity, loss of competitive advantage, irrecoverable data loss or compliance violations; which, after all, is a fundamental responsibility of a document owner

So what can be done to address this? 

FileOpen document security and rights management solutions provide military-grade document encryption along with granular access and usage controls, enabling the document owner to share documents without giving up control. Today we will talk a little bit about core functionality within FileOpen software that allows document owners to expire file access based on predetermined usage, timeframe or date.  Additionally we will show you how to revoke document access, Mission Impossible style.   

How to revoke document access with FileOpen DRM

If the document owner determines business conditions warrant a change in who can access a FileOpen-protected document; the owner can instantly revoke a specific user’s access or access to a specific document by all users.   All changes take effect instantly.

Let’s look at an example. You send out a proprietary research to a number of people then later discover a critical error. In the meantime, that document has been edited, renamed, and saved locally to hundreds of devices. As the document owner, you can revoke access instantly with a simple tick of a checkbox. Now none of the recipients will be able to open any copy of that protected document. You can then send out an updated copy without the embarrassing error.

Here’s another example. You protect sensitive legal information in a document and send it to business partners and select staff. After a falling out, you are no longer business partners with one particular company. You can revoke access for the users in that particular company alone. All other users can still access the document without interruption.

How to Expire Documents with FileOpen DRM

In addition to instant revocation, FileOpen software can be configured to expire document access on a predetermined date, after a given timeframe or after a certain count of opens or prints.    To demonstrate, let’s look at another example.  You are preparing my company’s quarterly financials and need to distribute early drafts to a small group of staffers and outside legal counsel.  All access to this draft is to cease on October 5st, the day before earnings are made public.  You start by creating a Group within the FileOpen PermissionServer; a collection of authorized users, your protected files, and the policies that govern the usage of those files.  Within the Group you specify the permissions that will govern the usage of the documents. For this situation, you will set an absolute expiration date of October 5, 2015. 

After preparing the permissions for the Group, you add all authorized Users into the same Group through a quick pull down menu. As a side note, this step could be automated depending on your use case or workflow requirements; FileOpen integrates with existing ADS/ SSO system, eCommerce systems, enterprise file-sync-and-share or learning management tool; making it easy for administrators to centrally manage users and permissions. 

The next step is to protect the draft documents and add them to the Group.  You simply drop the source files into a watched directory on your local machine and FileOpen software does the rest. 


An encrypted version of your source document is created and placed into a corresponding Encrypted folder on your machine.   The only thing left to do is to distribute the document to the authorized Users.

On October 5th all access to the protected drafts is cut off, no matter where authorized users have stored the document.  The only way this draft can be opened after the expiration date is if/when the document owner re-enables the document from within the PermissionServer by modifying the expiration date.

Would you like to learn more?  Request a quick demo or get a free 14-day trial to test expiration and revocation for yourself.


How to Protect PDFs without Passwords

Posted by FileOpen DRM News

How many times per day do you have to remember your username and password to access an application or Web page? According to a recent TeleSign study, consumers have an average of 23 online accounts, and more avid Internet users have a much higher number.  In my own experience, as of noon today, I’ve already logged into 9 different applications - all of which have required username and password authentication. To make matters worse, I had to reset a password to a website I hadn’t used in a while.  That said, we at FileOpen know just how frustrating it is to manage what seems is a never ending list of credentials in your head.  So today’s post will cover how you can protect your high-value documents without some of the inherent pain points and security issues associated with username and password authentication. 


The problem with passwords

Passwords are the most common way users confirm their identities.  However, passwords are also considered a weak form of authentication.  The truth is that there’s nothing wrong with passwords; the problem is the user. Users experience what is known as password fatigue; they select passwords that are too simple, too predictable, they re-use the same passwords across systems, they fail to change their passwords on a regular basis, and much to our disbelief, users log credentials in notebooks usually kept alongside their machine.  As you can see, the Personal Internet Address & Password Log Book retails for $6.49 and is currently a #1 Best Seller on Amazon. 


In addition to password fatigue, users fall victim to cybercriminal’s phishing and spoofing scams.  And finally, what is to keep a user from lending their credentials to someone else?


FileOpen Approach: Securing documents, without passwords

FileOpen document security software offers businesses a variety of authentication modes designed to alleviate the pain and insecurity of traditional username and password authentication. 

The first out-of-the-box mode of authentication is device or machine authentication.  With this mode, users authenticate once by opening a FileOpen Registration PDF on their desktop, laptop or iOS device with the FileOpen Client.  Once opened, the FileOpen Client sends a list of machine identifiers, unique to that user’s device, to the governing PermissionServer which then logs the information within the user’s profile as a registered device.  After opening that registration PDF, all subsequent access requests by that user are permissioned by validating the user’s machine identifiers with the governing PermissionServer.  This means the whole identification process is invisible to the user and is exactly the same as opening a non-protected PDF file.  All permissions are obtained from the document owner’s PermissionServer in real-time, and are specific to that user’s device. Permissions are not portable in any way that the user can control; permissions are locked to the original device. 


The FileOpen software may also employ additional means of authentication.   FileOpen integrates with existing ADS/ SSO systems, eCommerce systems, enterprise file-sync-and-share or learning management tools. These options make it easy for administrators to centrally manage users and permissions, without requiring users to manage yet another password.  In addition, custom configurations can be deployed to support cookie-based authentication, domain authentication, and user log-in authentication. 


While businesses truly dread the challenges and problems posed by passwords, it still remains a core authentication and security technology. And, as mentioned above, we don’t believe passwords are the root of the problem, we believe it’s the human element.  With that being said, FileOpen does support username password authentication and includes features to ensure security.  These features include:

  • Device limits: Owners may designate the maximum allowable count of devices that user may access a protected document from.  The smaller the number the more secure the system.
  • Revocation:  Allows owners to instantly disable access by document, user or user’s device.
  • Tracking:  Logs all access and usage by document or user ─ even failed access attempts.  This information includes device / machine identifiers, user login, host name, IP address as well as date and time.
  • Viewing Requirements:  Allows document owners to limit document access to specific operating systems.
  • Usage Controls:  Prevent or restrict copy/paste, printing, editing, saving and screenshots.


Want to learn more?  Start a free 14-day trial to see how you can start protecting your PDFs, without passwords. 

FileOpen Viewer for iOS (v2.4.0)

Posted by FileOpen DRM News


We are pleased to release the latest version of the FileOpen Viewer for iPad®/iPhone®.  The app updates like any other app you are accustomed to.  If you don’t have automatic updates enabled you will need to manually press "update" from the AppStore.  


What's New in Version 2.4.0

  •          Updated to support wider range of PDF files
  •          Improved decryption speed
  •          Added support for location services and device identification
  •          Small bug fixes and enhancements

This update replaces version 2.3.4 posted to iTunes in Jannuary 2015.

Client-side vs. Web-based document security

Posted by FileOpen DRM News

The more things change, the more they stay the same

In the early 1990’s client server architectures were ubiquitous. Businesses managed their own servers, software, and productivity tools for their workforce.  In the 2000’s, the growing adoption of the Web introduced new opportunities and serious new threats to the IT landscape. Businesses responded by installing more infrastructure; typically more hardware in the data center. The idea was to establish a perimeter around the business to keep hackers out and intellectual property (IP) in. Fast forward to 2010, the world had completely changed: Web access was ubiquitous. Social media, collaboration tools, file sync-and-share, and mobility (BYOD) were unstoppable forces.  However, the more things changed the more the need to protect sensitive, regulated or corporate IP stayed the same.


Today businesses have embraced this new era, accepting easy-to-use, always-available productivity tools delivered to everyone in their workforce, anywhere in the world, on all their devices, in real time.  By doing so, these companies not only realize a broad array of capabilities but a distinct cost savings of no longer maintaining servers and software in-house.  However, the downside is that centralized, perimeter-based security solutions no longer make sense.  

So, the question becomes: do you trust security measures provided by third party Web-based service providers, or do you apply client-side security to persistently protect your IP? 

Client-side vs. Web-based document encryption

With Web-based encryption, documents are encrypted by the sender, at the server, so that only the receiving party can decrypt them. This approach is designed to keep files safe during transfer, but both ends are often left vulnerable.  For example, in October 2014, Dropbox was a victim of a sender side breach.  Dropbox users had their usernames and passwords released on Reddit, giving millions of Internet users access to the contents of their accounts. Because the content stored in the cloud was not encrypted, any user with credentials could access that content.


Had those same documents been encrypted prior to being uploaded to Dropbox, the damage would have been significantly reduced. With client-side encryption your documents are always protected; only authorized users can access the content no matter how the document is obtained or where it is stored.  The same goes for your third-party service providers, with client-side encryption your Web App providers have “zero knowledge” of your content; meaning they can’t access or disclose your company’s private information.  Client-side encryption is the only option that offers that kind of security.

In addition to security, client-side tools have definite business benefits.  With client-side encryption tools your workforce is equipped to apply document encryption on the machine they use to author high-value documents.  It is always available; empowering your workforce to easily apply document security measures without opening a browser, remembering credentials, or additional steps.   Furthermore, having the encryption App local to the machine increases the likelihood of it becoming part of the user’s daily routine; a constant IP protection reminder, if you will. 

FileOpen Solutions

At FileOpen, we have been building document security solutions for our customers since the early 90’s.  We were the first Adobe Technology Partner to build a third party plug-in to control access and usage of PDF documents.  The solution consists of three basic components; document encryption tools, a permissioning server to govern access and usage, and a versatile set of clients and viewers.  Customers have the option to host their own permissioning server, RightsServer, or leverage a hosted version, RightsManager.  Both solutions offer true client-side document encryption tools. Put simply, we don’t ask you to upload your source documents to our server for encryption. 

FileOpen offers several configurations for client-side encryption to meet varying business needs.  At the most basic level, users simply drop their unprotected documents into a monitored directory on their machine.  That action initiates the encryption process and within seconds an encrypted version of the same document is placed into a directory of the user’s preference.  The file can then be distributed by any means available.  If appropriate there is an option to mirror the output folder to many popular file-sync-and-share sites through oAuth or other APIs.  In addition to our basic directory monitor interface, FileOpen software can be configured to programmatically encrypt all documents created on a given machine or server, as they are created or on-the-fly, as the documents are being requested. 


Want to learn more? Contact us if for a quick demonstration or start a free 14-day trial.



Topics: document encryption, security, DRM advice, DRM mistakes