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

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 invites you to our upcoming webinar: "Is BYOD the weak link in your document security strategy?"

Posted by Amanuel Tsighe


The FileOpen team is excited to announce our third webinar in a monthly series: "Is BYOD the weak link in your document security strategy?"Join us on Tuesday, November 19 at 10:00 am Pacific/1:00 pm Eastern to see why leading corporations choose FileOpen to secure their documents in the era of BYOD. 

describe the image

Managing the BYOD (Bring Your Own Device) phenomenon can be challenging, but with the right security policies and technology, you can strike the right balance between enabling mobility and security.

Discover how organizations in your industry use FileOpen DRM to:

  • Support corporate “bring your own device” (BYOD) initiatives
  • Authenticate users and protect documents on PCs, Mac OSx, iPad, iPhone, and Android
  • Securely share documents by email or via the cloud (e.g. Dropbox)
  • Expire or revoke document access at any time — even after delivery
  • Keep users happy with a hassle free user experience
  • Track when and where your documents are being viewed, and for how long

Register Now Button Orange resized 600

Have a question you would like us to answer during the presentation? Ask below!



Topics: drm, document security, live webinar

Minimizing Insider Threats: The Unwitting Disclosure

Posted by Amanuel Tsighe

In our last post, Minimizing Insider Threats: The Rogue Employee, we looked at how organizations can implement effective security measures to thwart a determined effort to leak private information. But insider threats are not limited to employee sabotage. With the accidental click of a button, a well-intentioned employee can cause a disaster of rogue-employee proportions. One may argue that there’s a fine line between deliberate data loss and unintentional data loss. Even if we’re all prone to making mistakes, isn’t it the responsibility of IT administrators to prevent an accidental leak of data that easily could have been prevented with the proper safeguards? 

describe the imageAccidental data loss has the potential to divulge trade secrets and intellectual property, strain client relationships, and ultimately compromise your revenue. So what’s a CIO to do? To minimize the risk of an unwitting disclosure, let’s identify and remedy four common threats:  

1.  Outgoing Email With Wrong Recipient – Encrypt, encrypt, encrypt. Last September we witnessed the calamity an accidental data loss can bring when the Georgia Department of Labor accidentally emailed the Social Security numbers of more than 4,000 individuals. Labor officials later requested the 1,000 email recipients “please delete the email and attachment immediately.” It can happen to the best of us. Implementing a DRM solution, like FileOpen RightsManager, assures that only authorized users can view a document. FileOpen's RightsManager is closely integrated with Microsoft Outlook so you can email documents securely and know they can't be forwarded or shared. Store your sensitive information in secure documents in lieu of email bodies and spare yourself the “please delete” email.

2.  BYOC (Bring your own cloud) – Share files securely. According to a new survey from Usamp, 41% of employees admit to using unsanctioned services like Dropbox, Box and Google Docs on mobile devices to share files. The estimated annual cost to remedy the data loss is about $1.8 billion. Once documents are encrypted, prevent or circumscribe document sharing with permission policies that preclude forwarding, expire access, and monitor document access. Need to remotely access documents outside of the LAN? With a secure file hosting service like FileOpen Viewer, you can still use Dropbox and Box to host your documents, but be certain that only users you specify can view them.

3.  Unfettered document access – Control printing and enforce a machine limit. As discussed in our first installment of Minimizing Insider Threats, enforcing a “need to know” policy is imperative in preventing an internal data breach. Once employees are limited to the least number of documents required to do their job, enforce a “need to print” policy. Printing sensitive documents opens a world of vulnerabilities, since unauthorized copies can’t be tracked. Minimize these threats by controlling who can print which documents, and how many times - if any at all. Applying watermarks can ensure the traceability of sensitive documents by overlaying key metadata, such as the username, date, time, and location of printing, to any printed copies. Also, on how many machines does employee X need to access document Y? Her office workstation only? Multiple machines around the office? To prevent an employee from accessing sensitive information on unsecure networks, enforce a machine limit and ensure that she may only access the document from a specified number of machines.

4.  BYOD  Instantly Revoke Access. BYOD is here to stay. According to a recent Gartner study, by 2017 half of employers will require employees to use their own devices for work. The convenience of BYOD also brings the concomitant risk of physical data loss. So how can we assure data security on a device that we’ve lost? Simply applying passwords to documents is not a scalable solution for BYOD. Using a comprehensive DRM solution that supports iOS and Android, you can link all of a user’s devices to their company login. If one of their devices is lost or stolen, the IT admin can instantly revoke all document access specifically for that device.

Encrypt, share files securely, control access, and revoke access. Share these tips and let’s help our IT admins get a better night’s sleep. Also, check out our whitepapers and demonstration documents to discover how FileOpen DRM can help you realize your security objectives.

Topics: document encryption, drm, document security, data leak

FileOpen invites you to our upcoming webinar: "Share files securely – anytime, anywhere"

Posted by Amanuel Tsighe

The FileOpen team is excited to announce our second webinar in a monthly series: "Share files
 securely – anytime, anywhere". Join us on Tuesday, October 15 at 9:00 am Pacific/12 Noon Eastern to see why leading corporations choose FileOpen to secure their documents.  

webinar quote bubble3333333 resized 600

We’ve all heard it — another day, another data breach. The need to share information securely across boundaries has never been greater, and a robust security program has proved to be a distinguishing factor among market leaders.

Discover how organizations in your industry use FileOpen DRM to:

    • Control printing, apply watermarks and edit/revoke access at any time
    • View protected documents without client plug-ins
    • Support document delivery to PCs, iPad, iPhone, and AndroidBYOD...instantly
    • Send documents by email or host in the cloud (e.g. Dropbox)
    • Track when and where documents are being viewed, and for how long

Have a question you would like us to answer during the presentation? Ask below!

Topics: drm, document security, live webcast

Minimizing Insider Threats: The Rogue Employee

Posted by Amanuel Tsighe

No company wants to believe they may have a rogue employee on their payroll.  However, Eric Snowden's leaking of top-secret NSA documents has raised awareness of internal threats in organizations worldwide. It’s not easy to detect an insider threat, and it’s nearly impossible to stop a determined rogue employee. Companies can however enforce effective security controls to minimize such threats.

The more recent in-house breaches at Vodafone and Holy Cross Hospital are a testament to the flaws of many internal security systems. Merely passing compliance requirements isn’t helping IT professionals sleep any better at night, and even the strongest firewall won’t prevent a legitimate employee from sharing documents outside of the organization.

So what are the common security mistakes that could enable a rogue employee in your organization?

The Rogue Employee

  1. Overly-generous document access policies. Too often we see companies offer their employees unnecessarily privileged access to sensitive documents and data. And with greater access comes greater risk, of course. Enforcing a “need to know” policy, in which employees are limited to the least number of documents required to do their job, can great reduce the threat of an insider breach. Pinpoint which documents are in most need of protection, then limit access.
  2. Decentralized storage of sensitive documents.  Organizations may minimize the amount of access an employee has to sensitive information by following the vault paradigm of document security. Offer employees the option to request document access and require a reason for access.
  3. Allowing legacy access to documents. In the wake of the NSA scandal, we are seeing organizations adopt DRM solutions that enable administrators to revoke user access to a document anytime, anywhere. Using FileOpen’s RightsManager solution, for example, if an employee no longer needs access to a particular document to effectively do her job, system administrators may simply revoke her access to said document. If she later requests access to the document, but her task only requires limited access, system administrators can enforce a policy that limits her access to select portions of the document.
  4. Allowing unfettered access on take-home devices (BYOD). With the profusion of tablets and smartphones comes the heightened risk of employees using company documents on their personal devices. To manage such activities, administrators should enforce a machine limit on more sensitive documents. For example, FileOpen RightsManager enables setting a machine limit of “1” to ensure that an employee may only access the document from her office workstation.
  5. Trusting high-level employees with too much. Limiting document access to lower-level employees is important, but what about executives? Granting exceptions for higher-level employees can put companies at risk. According to a 2013 Data Protection Trends Research study, among companies with secure programs in place, 24% allow exceptions for executive-level employees. This poses an especially dangerous threat as executive-level employees are often granted access to the most sensitive information at a firm. Realizing impregnable document security requires you enforce a “need to know” policy across the board. Limit the number of documents to which your “superusers” have access, and consistently monitor their access. Snowden, of course, was a system admin who was permitted access to an NSA file sharing location on the NSA intranet to transfer sensitive information. Enacting a “two-person” rule to accessing highly sensitive documents can further thwart lone-wolves. Additionally, before a system administrator is handed the keys to the kingdom, be sure to conduct a thorough background check.
  6. Failing to monitor document usage. No security program is bulletproof without a system of quickly identifying and containing a data breach. Applying a document monitoring solution (track number of times opened, location of access, etc) can help your IT department quickly identify and stop any unusual activities.  Document tracking is highly effective in identifying both rogue employees and former employees. For instance, after an employee leaves your company, your legal department will be empowered to request a list of documents the employee accessed to more effectively monitor any leaked trade secrets to a competitor. Stay tuned for the official release announcement of FileOpen’s document tracking solution.

Encrypt, limit access, monitor access, educate, and iterate. Reaching the promised land of security doesn’t need to be elusive. Stay tuned for our second installment: “Minimize Insider Threats: The Unwitting Disclosure.” Also, check out our whitepapers and register for our live demo on October 15th, 2013 to discover how FileOpen DRM can help you realize your security objectives. 


Topics: document encryption, drm, document security, insider threat

FileOpen News: Predominant Enabling Technology to VDRs

Posted by FileOpen DRM News

FileOpen Systems Inc., the document rights management (DRM) developer, today announced a significant surge in the licensing of their DRM technology to Virtual Data Room (VDR) providers, positioning the company as the predominant enabling technology for VDRs to date.  The company's broad customer base in publishing, financial services, manufacturing, healthcare, education and government now includes 8 of the top 10 VDR platform providers.   Check out the full press release and join the conversation on twitter @fileopen #fileopenvdr.

Topics: VDR, drm, document security, Virtual Data Room

Should you migrate from Adobe LiveCycle ES to FileOpen DRM?

Posted by FileOpen DRM News

See how the two solutions stack up, feature by feature.Adobe LiveCycle Rights Management ES

Adobe made some pretty big announcements over the last year.  First was the news that Adobe retired its “LiveCycle” brand; the enterprise suite which encompassed document workflow and rights management features. They further explained that all LiveCycle capabilities are now incorporated within Adobe Digital Enterprise Platform (ADEP), their customer experience management (CEM) platform. Most notably, a post issued last month in Adobe's Enterprise Blog stated, “The Adobe LiveCycle business will continue to pursue enhancements and new customers in select verticals such as government and financial services” and that “we will continue to support customers in all verticals.” 


Our interpretation is that Adobe is now maintaining current LiveCycle customers while encouraging them to upgrade to newer versions of the software.  Customers are still able to upgrade to the latest capabilities available for their specific LiveCycle module, as well as purchase additional modules to expand their applications. 

What does this mean for customers who just need to deploy DRM functionality in the Adobe Reader? ADEP is a comprehensive content management system for enterprise customers who need an end-to-end solution; but it can be overkill for someone just looking to distribute documents securely. 

As one of a select few Adobe Security Partners licensed to load “security handler” plug-ins in the free Adobe Reader, FileOpen offers a targeted DRM solution which you can integrate into your existing workflow. As we demonstrate below, there is quite a bit of overlap between Adobe LiveCycle’s DRM feature set and FileOpen’s. We’ve put together a comparison chart to help in determining if migrating from LiveCycle to FileOpen makes sense for your organization.


FileOpen DRM Solutions
Adobe LiveCycle Rights Management ES
Licensing Methods
Client/Server Based Licensing
Software as a Service (SaaS)-Based Licensing
 Yes  Yes
User-Based Identification
 Yes  Yes
Computer-Based Identification
 Yes  Yes
Domain Authorization
 Yes  Yes
Smart Card Authentication
 No  Yes
Cookie-Based Authentication
 Yes  Yes
Policy Management
User/Role/Group-Based Access
 Yes  Yes
Create New Policies
 Yes  Yes
Change/Revoke Access
 Yes  Yes
Usage Logging & Metering
 Yes  Yes
Copy/Delete Policies
 Yes  Yes
Add/Remove Policy Administrators
 No  Yes
Offline Viewing
 Yes  Yes
Open/View Rights
 Yes  Yes
Print Count
 Yes  Yes
Copy/Paste Rights
 Yes  Yes
Embargo/Expiration Rights
 Yes  Yes
View/Print with Watermark
 Yes  Yes
Screen Grab Protection
 Yes  No
Protected Changes
 Yes  Yes
Version Control
 Yes  Yes
Encryption Levels
128-bit RC4, (128/256-bit AES Q1 2015)
128-bit RC4, 128/256-bit AES
Key Management
Pseudo Random Number Generator
Pseudo Random Number Generator
Enterprise Directory/LDAP Integration
 Yes  Yes
Client side integration (components, plug-ins, etc.)
Solutions available with and without client integration.
Website’s certificate must be installed to access Rights Management ES through the client applications.
Operating System (Encryption)
Microsoft® Windows Server®, Sun™ Solaris™, Linux ®, freeBSD®, HP_UX®, .NET, JAVA
Microsoft Windows Server, Sun Solaris SPARC®, IBM® AIX®,Red Hat®,SUSE®
Application Server
Any Application Server
IBM WebSphere®, Oracle® WebLogic, JBoss®
Operating System (Client)
Windows, Mac OS , Linux
Windows, Mac OS , Linux
Supported File Types
PDF, Excel, Word (Powerpoint Q1 2015)
PDF, Excel, Word, Powerpoint and CAD files
Supported Devices
Desktop and Mobile OS (iOS**, Android**)
Desktop and Mobile OS (iOS, Android, Blackberry and Windows Mobile)
Direct Licensing
FileOpen DRM Solutions are available as a hosted solution,  a licensed server, or through individually licensed modules.  View all>>
Available as core functionality within the Adobe Digital Enterprise Platform Standard Edition or as individual components to Government or Financial markets.
Indirect/Partner Licensing
FileOpen DRM is available on a limited basis through these partners.
Available indirectly, as core functionality within the Adobe Digital Enterprise Platform Standard Edition, or as individual components to Government or Financial markets only.
*With respect to Non-FileOpen Products, the information presented is based on publicly available information. We accordingly make no representations with respect to the accuracy or validity of the information, but merely provide it for comparison purposes.

If you have anything to add or correct about this analysis, please leave a comment.

Topics: drm, DRM comparison, Rights Management, Adobe LiveCycle, document 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

The British Library Adopts FileOpen DRM as a User-friendly Solution

Posted by Diana Holm

We are not big on generating a lot of press releases here at FileOpen, preferring toBritish Library logo stick to our knitting so to speak, but every so often a customer will take it upon themselves to evangelize FileOpen software, and we'd be ungrateful not to share their enthusiasm (if a little belatedly).

The British Library, one of the world's largest document repositories, issued a press release in November 2009 entitled "The British Library Improves Electronic Access with New DRM Platform from leading provider, FileOpen Systems." Their announcement emphasized the greater flexibility FileOpen DRM would provide to end-users, with the library's head of sales and marketing quoted as saying, "The decision to add FileOpen to our Document Supply delivery options was driven by customer demand, they wanted a choice of electronic delivery options....Customer feedback from the testing phase was very positive, and we are pleased to announce that we are now recommending FileOpen as our preferred electronic delivery option to all customers."

We were also pleased to see the British Library's official response to "An open letter to the British Library" posted by Richard Mitchell of the University of York on the British Library's Facebook page. Mr. Mitchell had written to the library to express his "disappointment at the British Library's decision to use proprietary, DRM-encumbered software to distribute journal articles, whilst other institutions and publishers happily distribute their articles in the much more accessible PDF format." He also bemoans the lack of support for Linux.

It turns out, Mr. Mitchell was referring to the British Library's prior use of Adobe's Digital Editions DRM platform, which necessitates the download of a separate viewer and does not support the standard Adobe Reader. Nor does the Digital Editions viewer run on Linux. The British Library's Barry Smith thanks Mr. Mitchell for his comments and informs him the British Library will be launching "an additional DRM facility in early 2009 that will be compatible with Linux (and most other open source platforms) called FileOpen." Mr. Smith goes on to say that "From April, we will be encouraging our academic users to switch to FileOpen, as it will offer more flexibility for many of our customers."

FileOpen's relationship with The British Library goes back to 2000, and after many damp and chilly train trips from London to Boston Spa to meet with their information services management and understand their complex requirements, it is especially gratifying to have the support of both the Library and their end-users.

Topics: FileOpen, british library, drm, pdf security, pdf encryption, digital editions