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:
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.
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?