FileOpen Document Security Blog

Should you migrate from Adobe LiveCycle ES to FileOpen DRM?

Tweet  

  

  

  

 delicious  

  

See how the two solutions stack up, feature by feature.

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.

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

FileOpen Client 0917 Released

Tweet  

  

  

  

 delicious  

  

We have released an updated FileOpen plug-in for Adobe Acrobat and Reader on Windows. The Client, Build 0917, implements a few patches and bugfixes. Specific improvements include:

• Improvements to Dynamic Watermarking functionality including the addition of finer-grained color management and imposition of control over fill and stroke, plus a new mechanism for handling page content with complex content arrays.

• Support for retrieval of cookies in the Google Chrome browser.

• Improvement to the retrieval of Offline Permission under Reader X protected mode.

• Additional modifications to eliminate known conflicts with other applications when kernel-level screen capture prevention is invoked.

• Modification to the .msi installer mechanism to improve detection of Acrobat/Reader.

This update replaces the 0914 release from October 2011.

New FileOpen Client for Adobe Acrobat and Reader

Tweet  

  

  

  

 delicious  

  

FileOpen Systems has released an updated plug-in for Adobe Acrobat and Reader on Windows. The Client, Build 0914, implements minor new functionality, along with multiple patches and bugfixes. Specific improvements include:

• Addition of new font, color and placement options for Dynamic Watermarks, including an option to store watermarks in Offline Permission with logic to insert current date/time and other data while offline.
• Improved management of Reader X “protected mode” and Internet Explorer protected mode, enabling full operation including retrieval of cookie data when both programs are in protected mode, also improved cookie handling under Firefox.
• Architectural modifications to enable the Broker process to operate under Reader X for multiple users on thin-client systems (Citrix XenApp, MS Terminal Server)
• Modifications to eliminate known conflicts with other applications when kernel-level screen capture prevention is invoked.

FileOpen Systems Releases Updated Client Plug-in

Tweet  

  

  

  

 delicious  

  

FileOpen Systems has just released the 0900 plug-in to Adobe Reader and Acrobat for Windows, which introduces important new functionality including real-time watermarking, tightened control over screen capture, and full compatibility with Adobe Reader X.

Adobe Reader X on Windows includes a new security feature, "protected mode," which is designed to limit the ability of malicious code to infect systems via PDF files. The new FileOpen plug-in operates fully in protected mode, which is the default configuration of Adobe Reader X.

Importantly, Adobe released a security advisory on March 14, 2011 (http://www.adobe.com/support/security/advisories/apsa11-01.html) describing an exploitable vulnerability in the Flash player. The same vulnerability can also affect Adobe Acrobat and Adobe Reader 9, which bundle the Flash player, and Adobe Reader X if operating outside of protected mode.

According to Adobe, "this vulnerability (CVE-2011-0609) could cause a crash and potentially allow an attacker to take control of the affected system." They go on to say that while Adobe Acrobat and Reader have not been directly targeted, "Adobe Reader X Protected Mode mitigations would prevent an exploit of this kind from executing."

As a precaution, we strongly recommend that all publishers of FileOpen-protected PDFs distribute this new client to their end-users. Recipients of secured PDFs may also install the new plug-in directly from http://plugin.fileopen.com, then confirm that the box is checked at Edit>Preferences>General>Enable protected mode at startup.

Documents distributed with older versions of the FileOpen plug-in are forward-compatible with the new plug-in, so end-users do not need to obtain new documents or permissions from the publisher.

Digital Rights Management Do's and Don'ts

Tweet  

  

  

  

 delicious  

  

Having developed DRM software for the last fourteen years, we have seen our share of customer implementations. Although we provide just one piece of the puzzle, we have seen how our customers build end-to-end secure document delivery systems, with varying degrees of success. The success of a project most often can be tracked to the early planning stages, and is often more about preparation and attitude than about specific technology. We thought we'd synthesize what we've observed over the years into a handy list of ten do's and don'ts.

1. DO: Put some mechanism in place to protect your information if you expect others to value it, or if sharing that information would violate your corporation’s or an individual’s privacy.

This may seem obvious coming from us, but in almost every discussion on the topic I’ve seen, a DRM cynic will chime in informing everyone that any encryption can be broken and so there no point in implementing DRM. It’s certainly the safe and easy argument to make, since securing digital information is indeed a hard problem; however the same logic could lead someone to leave their house unlocked, since all locks can eventually be broken. Most reasonable people recognize the advantage of making it harder to break into your house, and of making it clear that unauthorized entry is prohibited. Without going into too much detail here, DRM can and does work by:

• Thwarting the most obvious (and some more sophisticated) attempts to access and share restricted documents
• Logging and alerting you about attempts to access your secure documents
• Watermarking end-user data onto views and prints of secure documents
• Declaring your version of a document to be the “official” version
• Establishing a “circle of trust” between you and your users, who may share your concerns about piracy or privacy.

2. DO: Consider if your content is a good fit for DRM.

DRM works best with content that is valuable to a professional niche, or timely, or both (e.g,. distribution of financial research.) In such markets, the high cost of the content makes the paying customer a willing participant in the control process ("I paid for this information so that I would have a trading advantage; I don't want some other guy getting it for free!"). As a general rule, mass-market products at low price points aren't a good a fit for DRM, such as commercial MP3 distribution. The reason for the failure is a mix of consumer expectations, the perception of "lock-in" to one of many devices available for playing the content, the cost of the content itself, and other factors.

3. DO: Research your user base before settling on a DRM scheme.

Which platforms and devices are they on? How are they using your content—for up-to-the-minute information on their phone or tablet, or printing it out to read at leisure? Will they have access to the internet at all times?  Are they in a corporate environment where installing any sort of client software requires administrative intervention? Or on a college campus where the risk of redistribution is high? Answering these questions before you deploy DRM will dictate which technology you choose and the degree of security you place on your files, and save you a great deal of customer angst later on. Some DRM solutions allow a range of security from CIA-level to simply monitoring usage.

4. DO: Look for ways to scale the protection to the environment

As new platforms emerge for the consumption of content – tablets, phones, etc. – they enable the development of new methods (for authentication, for instance), data formats, and user experiences. Where possible it is worth considering how a given piece of content can be displayed in different ways on different devices, with the amount of control modulated by the capabilities of the device: the less functional the display environment, the less DRM is required to control that environment.

5. DO: Design your DRM implementation to be as flexible as possible.

Complexity is a good thing when it comes to information security. Having a single point of access, such as a password to open a document, is the easiest security method to break. That’s not only because it depends on one thing, the password (which is the same for everyone and can be shared), but because in most cases it is permanent. Look for a DRM solution that lets you define permissions policies for both users and documents, and which lets you revoke access after you have distributed the document. The best way to do this is to link your DRM system with your customer database, so that changes in customer status can translate instantly to their permissions.

6. DON'T:  Make it harder than necessary to view the protected content.

There is an inevitable tradeoff between ease-of-use and protection: the more protected the content, the more complex the protection system will be to install and use. As above, the "right" amount of protection depends on the content being protected, but the right protection mechanism is usually the one that imposes the fewest new behaviors on the user. A DRM system that works within the same applications used to view unprotected content will normally be better received than one that requires the downloading, installation and training on new applications. The best DRM is invisible to the legitimate user.

7.  DON'T:  Assume the most expensive solution is necessarily the best (or the cheapest, for that matter).

There’s no denying that most DRM software carries a hefty price tag with it. The reasons for this include the intensive engineering resources required to develop and maintain a credible DRM product; licensing and royalty costs associated with supporting the more popular formats and devices, and the coalescing of the market around corporate and financial users (since the technology has had less success in mass-market applications.) The top “enterprise rights management” solutions have a starting price in the six figures and include a buy-in to specific server and document management products. However there are some smaller developers (my company included) who offer DRM functionality in a hosted environment by annual subscription, as well as in standalone server modules for companies who need only a few key pieces of the secure information sharing puzzle. Don’t be seduced by companies offering very inexpensive DRM however—in most cases you will find the inflexibility of those systems or the inexperience of the company will end up costing you more later on.

8.  DON'T:  Attempt to go it alone with a custom, in-house solution.

Distributing files to hundreds or maybe thousands of end-users on diverse platforms and devices is a complicated business, and a big reason DRM software companies are able to demand high prices for their technology. DRM companies, for the most part, have also been at it for a long time and seen hundreds of customer implementations, both successes and trainwrecks. Many of them also have special licensing relationships with document viewers which aren’t available to companies not directly in the DRM software producing business. Also consider that the more customized your DRM implementation, the more difficult it will be to maintain going forward, as newer versions of viewers, formats and devices continue to proliferate. If your core business is anything other than DRM software development, stick to your knitting and leave that to the experts.

9. DON’T: Try to protect static content

In the days before copyright laws were introduced and/or enforced, publishers had little incentive to bring out complete works, as these would immediately be re-issued by other publishers. So publishers developed ways to serialize content, to minimize their risk and increase the workload of the copiers. It may be that the current market for high-quality complete works (e.g. books, recorded songs, films, etc.) is devolving into a commercial environment similar to that of post-revolutionary France (or pre-revolutionary America, see Mark Stefik’s work for details) and if so the best approach is probably to keep producing new content. This also makes the DRM process easier, as a focus on new content permits the DRM to evolve as needed. The key is to produce content that is perceived as more valuable than a blog post, usually because it is timely, attractively displayed, and focused like a laser on your target market.

10. DON’T make your implementation more complex than it needs to be.

There are many variables involved in creating a system to deliver encrypted content: users and documents must be identified, rules and policies must be established, integration with others systems (e.g. eCommerce) may be required, etc. Sometimes the design process results in a specification that while technically possible is too complex to be implemented in the timeframe available. Or the requirement might include desired features, e.g. real-time creation or customization of documents, that imposes excessive demand on the server process and can limit scalability or customer responsiveness. DRM is inherently complex, so the simplest possible implementation is frequently the most successful.

We'd love to hear your suggestions to add to this list. Have you been involved in a DRM implementation before? What did you learn? If you haven't been using any DRM, what have been the consequences?

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

Tweet  

  

  

  

 delicious  

  

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

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

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

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

RIM's "PlayBook" Will Extend FileOpen's Reach on Handheld Devices

Tweet  

  

  

  

 delicious  

  

This week Research in Motion announced a tablet device, named the “BlackBerry PlayBook”, that appears to exceed the specifications of the iPad in every respect other than screen-size. The device, which will debut in the second half of 2011, will have a dual-core processor and 1Gb of memory, a variety of input/output ports, and two cameras (i.e. the ability to videoconference).

Most important for our customers, the PlayBook will run Flash 10.1, and therefore should support both the FileOpen Viewer and our recently released BlackBerry client. This would enable distribution of the same FileOpen-encrypted document to the BlackBerry, PlayBook, and on standard Windows/Macintosh/Linux computers.

The PlayBook will work immediately with BlackBerry Enterprise servers. It runs a Unix-derived microkernel operating system (QNX) that RIM acquired along with the company of the same name earlier this year. Reports describe the OS as extremely secure and capable of true multitasking, something the iOS can’t currently provide. The seven inch screen is smaller than the iPad’s by two inches, but this may be intentional (there are rumors that the next version of the iPad will include a model with a seven-inch screen). 

Check out our press release announcing our support of the BlackBerry platform for document distribution, and stay tuned for more announcements as we extend secure document sharing to the world of smartphones and tablets.

FileOpen for Handhelds

Tweet  

  

  

  

 delicious  

  

This week FileOpen Systems is releasing FileOpen Document Control for 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 (www.slgmobile.com) and RepliGo (www.cerience.com). 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™!

Computerworld Interviews FileOpen Customer for ERM Article

Tweet  

  

  

  

 delicious  

  

We'd like to thank Elisabeth Horwitt for her mention of FileOpen Systems in a recent Computerworld article, "Enterprise rights management and keeping data in-house," and also to thank Paul Chow of BCA Research for his comments about his company is using FileOpen software in the same piece. 
 
The article describes some of the challenges around Enterprise Rights Management from an IT perspective. It also illuminates one of the important trends now emerging, the interplay between Digital Loss Prevention (DLP) and ERM/DRM. FileOpen has just made available a whitepaper on that subject, "FileOpen and Data Loss Prevention," which explores how the two approaches can complement each other.

Computerworld approached FileOpen customer Paul Chow at BCA Research, who explained why they chose FileOpen's DRM over alternative solutions;

BCA, for example, stopped using LockLizard's IRM product because it required installing a proprietary PDF reader that was not Adobe's, Chow says. "For our client base, that just wouldn't work." In contrast, FileOpen supplies a plug-in to users' existing Adobe readers that can be installed in 30 seconds, he adds.

The article underscores the importance of choosing DRM software which provides tools for managing users and permissions policies, a feature FileOpen has long provided and is soon to release in a web-based interface.

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

Tweet  

  

  

  

 delicious  

  

We are not big on generating a lot of press releases here at FileOpen, preferring to 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.