I am working with the International Digital Publishing Forum (IDPF), helping them define a new type of  content protection standard that may be incorporated into the upcoming Version 3 of IDPF’s EPUB standard for e-books.  We’re calling this new standard EPUB Lightweight Content Protection (EPUB LCP).

EPUB LCP is currently in a draft requirements stage.  The draft requirements, along with some explanatory information, are publicly available; IDPF is requesting comments on them until June 8.  I will be giving a talk about EPUB LCP, and the state of content protection for e-books in general, at Book Expo America in NYC next week, during IDPF’s Digital Book Program on Tuesday June 5.

Now let’s get the disclaimer out of the way: the remainder of this article contains my own views, not necessarily those of IDPF, its management, or its board members.  I’m a consultant to IDPF; any decisions made about EPUB LCP are ultimately IDPF’s.  The requirements document mentioned above was written by me but edited by IDPF management to suit its own needs.

IDPF is defining a new standard for what amounts to a simple, lightweight, looser DRM.  EPUB is widely used in the e-book industry (by just about everyone except Amazon), but lack of an interoperable DRM standard has caused fragmentation that has hampered its success in the market. Frankly, IDPF blew it on this years ago (before its current management came in).  They bowed to pressures from online retailers and reading device makers not to make EPUB compliance contingent on adopting a standard DRM, and they considered DRM (understandably) not to be “low hanging fruit.”

IDPF first announced this initiative on May 18; it got press coverage in online publications such as Ars Technica, PaidContent.org, and others.  The bulk of the comments were generally “DRM sucks no matter what you call it” or “Why bother with this at all, it won’t help prevent any infringement.”  A small number of commenters said something on the order of “If there has to be DRM, this isn’t a bad alternative.”  One very knowledgeable commenter on Ars Technica first judged the scheme to be pointless because it’s cryptographically weak, then came around to understanding what we’re trying to do and even offered some beneficial insights.

The draft requirements document provides the basic information about the design; my main purpose here is to focus more on the circumstances and motivation behind the initial design choices.

Let’s start at a high level, with the overall e-book market.  (Those of you who read my article about this on PaidContent.org a few months ago can skip this and the next five paragraphs.)  Right now it’s at a tipping point between two outcomes that are both undesirable for the publishing industry.  The key figure to watch is Amazon’s market share, which is currently in the neighborhood of 60%; Barnes and Noble’s Nook is in second place with share somewhere in the 25-30% range.

One outcome is Amazon increasing its market share and entering monopoly territory (according to the benchmark of 70% market share often used in US law).  If that happens, Amazon can do to the publishing industry as Apple has done for music downloads: dominate the market so much that it can both dictate economic terms and lock customers in to its own ecosystem of devices, software, and services.

The other outcome is that Amazon’s market share falls, say to 50% or lower, due to competition.  In that case, the market fragments even further, putting a damper 0n overall growth in e-reading.  Also not good for publishers.

Let’s look at what happens to DRM in each of these cases.  In the first (Amazon monopoly) case, Amazon may drop DRM just as Apple did for music — but it will be too late: Amazon will have achieved lock-in and can preserve it in other ways, such as by making it generally inconvenient for users to use other devices or software to read Amazon e-books.  Other e-book retailers would then drop DRM as well, but few will care.

In the second case, everyone will probably keep their DRMs in order to keep users from straying to competitors (though some individual publishers will opt out of it).  In other words, if the DRM status quo remains, the likely alternatives are DRM-free monopoly or DRM and fragmentation.

If IDPF had included an interoperable DRM standard back in 2007 when both EPUB and the Kindle launched, e-books might well be more portable among devices and reading software than they are now.  Yet the most desirable outcome for the reading public is 100% interoperability, and we know from the history of technology markets (with the admittedly major exception of HTML) that this is a chimera.  (Again, I explained this in PaidContent.org a few months ago.)

To many people, the way out of this dilemma is obvious: everyone should get rid of DRM now.  That certainly would be good for consumers.  But most publishers — who control the terms by which e-books are licensed to retailers —  don’t want to do this; neither do many authors, who own copyrights in their books.

E-book retailers and device vendors can get lock-in benefits from DRM.  As for whether DRM does anything to benefit rights holders by improving consumers’ copyright compliance or reducing infringement, that’s a real question.  Notwithstanding the opinions of the many self-styled experts in user behavior analysis and infringement data collection among the techblogorati and commentariat, the answer is unknown and possibly unknowable.  Publishers are motivated to keep DRM if for no other reason than fear that once it goes away, they can never bring it back.  Moreover, certain segments of the publishing industry (such as higher education) want DRM that’s even stronger than the current major schemes.

The fact is, none of the major DRMs in today’s e-book market are very sophisticated — at least not compared to content protection technologies used for video content.  The economics of the e-book industry make this impossible: the publishers and authors who want DRM don’t pay for it, resulting in cost and complexity constraints.  DRM helps retailers insofar as it promotes lock-in, but it doesn’t help them protect their overall services.  In contrast, content protection helps pay TV operators (for example) protect their services, which they want protected just as much as Hollywood doesn’t want its content stolen; so they’re willing to pay for more sophisticated content protection.

The two leading e-book DRMs right now are Amazon’s Mobipocket DRM and Adobe’s Content Server 4; the latter is used by Barnes & Noble, Sony, and various others.  Hackers have developed what I call “one-click hacks” for both.  One-click hacks meet three criteria: people without special technical expertise can use them; they work on any file that’s packaged in the given DRM; and they work permanently (i.e., there is no way to recover from them).  In contrast, pay TV content protection schemes are generally not one-click-hackable.

In other words one-click DRM hacks are like format converters, like the one built into Microsoft Word that converts files from WordPerfect or the ones built in to photo editing utilities that convert TIFF to JPEG. But there’s a difference: DRM hacks are illegal in many countries, including the United States, European Union member states, Brazil, India, Taiwan, and Australia; all other signatories to the Anti-Counterfeiting Trade Agreement will eventually have so-called anticircumvention laws too.

The effect of anticircumvention law has been to force DRM hacks into the shadows, making them less easily accessible to the non-tech-savvy and at least somewhat stigmatized.  Without the law, we would have things like Nook devices and software with “Convert from Kindle Format” options (and vice versa).  The popular, free Calibre e-book reading app, for example, had a DRM stripper but removed it (presumably under legal pressure) in 2009.  A DRM removal plug-in for Calibre is available, but it’s not an official one; David Pogue of the New York Times — hardly a fan of DRM — recently dismissed it as difficult to use as well as illegal.

The US has a rich case history around anticircumvention law that has made the boundaries of legal acceptability reasonably clear.  It has shut off the availability of hacks from “legitimate” sources and ensured that if your hack is causing enough trouble, you will be sued out of existence.  I am not personally a fan of anticircumvention law, but I accept as fact that it has made hacks less accessible to the general public.

The foregoing line of thought got IDPF Executive Director Bill McCoy and me talking last year about what IDPF might be able to do about DRM in the upcoming version of EPUB, in order to help IDPF further its objective of making EPUB a universal standard for digital publishing and forestall the two undesirable market trajectories described above.  We did not set out to design an “ultimate DRM” or even “yet another DRM”; we set out to design something intended to solve problems in the digital publishing market while working within existing marketplace constraints.

So now, with that background, here is a set of interrelated design principles we established for EPUB LCP:

1. Require interoperability so that retailers cannot use it to promote lock-in.  This is what the UltraViolet standard for video is attempting to do, albeit in a technically much more complex way.  The idea of UltraViolet is to provide some of the interoperability and sharing features that users want while still maintaining some degree of control.  Our theory is that both publishers and e-book retailers would be willing to accept a looser form of DRM that could break the above market dilemma while striking a similar balance between interoperability and control.
2. Support functions that users really want, such as “social” sharing of e-books. Build on the idea of e-book watermarking, such as that used in Safari Books Online for PDF downloads and in the Pottermore Store for EPUB format e-books: embed users’ personal information into the content, on the expectation that users will only share files with people whom they trust not to abuse their personal information.
3. Create a scheme that can support non-retail models such as library lending and can be extended to support additional business models (see below) or the stronger security that industry segments such as higher ed need.
4. Include the kinds of user-friendly features that Reclaim Your Game has recommended for video game DRMs.  These include respecting privacy by not “phoning home” to servers and ensuring permanent offline use so that files can be used even if the retailer goes out of business.  They also include not jeopardizing the security or integrity of users’ devices, as in the infamous “rootkit” installed by CD copy protection technology for music several years ago.
5. Eliminate design elements that add disproportionately to cost and complexity.  Perhaps the biggest of these is the s0-called robustness rules that have become standard elements of DRMs such as OMA DRM, Marlin, and PlayReady where the DRM technology licensor doesn’t own the hardware or platform software.  Eliminating “phoning home” also saves costs and complexity.  Other elements to be eliminated include key revocation, recoverability, and fancy authentication schemes such as the domain authentication used in UltraViolet.
6. Finally, don’t try very hard to make the scheme hack-proof.  The strongest protection schemes for commercial content — such as those found in pay television — are those that minimize the impact of hacks so that they are temporary and recoverable; such schemes are too complex, invasive, and expensive for e-book retailers or e-reader makers to consider.  Instead, assume that EPUB LCP will be hacked, and rely on two things to blunt the impact: anticircumvention law, and allowing enough differences among implementations that each one will require its own hack (a form of what security technologists call “code diversity.”).

With those design principles in mind, we have designed a scheme that takes its inspiration from two sources in particular: the content protection technology used in the eReader/FictionWise e-book technology that is now owned by Barnes & Noble, and the layered functionality concept built into the Digital Media Project‘s IDP (Interoperable DRM Platform) standard.

The central idea of EPUB LCP is a passphrase supplied by the user or retailer.  This could be an item of personal information, such as a name, email address, or even credit card number; distributors or rights holders can decide what types of passphrases to use or require.  The passphrase is irrecoverably obfuscated (e.g. through a hash function) so that even if a hack recovers the passphrase, it won’t recover the personal information; yet the retailer can link the obfuscated passphrase to the user.  The obfuscated passphrase is then embedded into the e-book file.  If the user wants to share an e-book, all she has to do is share the passphrase.  Otherwise, the content must be hacked to be readable.

Other aspects of the draft requirements are covered in the document on the IDPF website.  Apart from that, it’s worth mentioning that this type of scheme will not support certain content distribution models unless extensions are added to make them possible.  Features intentionally left out of the basic EPUB LCP design include:

• Separate license delivery, which allows different sets of rights for a given file
• License chaining, which supports subscription services
• Domain authentication, which can support multi-device/multi-user “family accounts” a la UltraViolet
• Master-slave secure file transfer, for sideloading onto portable devices, a la Windows Media DRM
• Forward-and-delete, to implement “Digital Personal Property” a la the IEEE P1817 standard

Once again, we set out to design something that meets current market needs and works within current market constraints; EPUB LCP is not a research-lab R&D project.

Again, I’ll be discussing this, as well as the landscape for e-book content protection in general, at Book Expo America next week.  Feel free to come and heckle (or just heckle in the comments right here).  I’m sure I will have more to report as this very interesting project develops.