How e-book DRM could actually be a good thing: Alternatives to Adobe, Amazon and Apple

At last, at last, the US/UK e-book conversation is getting around to questions of the basic architecture of how we sell, buy, share and keep our e-books. First Charles Stross pointed out on how publishers' insistence on DRM has put them at the mercy of Amazon. Joe Wickert launched a manifesto calling for a "unified ebook market" avoiding the vendor lock-in that is one of the main problems with today's e-book reality. Eric Hellman's latest post shows how needless is the publishers' acquiescence to that lock-in, the real core of Amazon's monopolistic (but not collusive!) power. And he very usefully reminds us that e-book "portability can be implemented without eliminating DRM".

So what are the alternatives to the existing Amazon/Apple/Adobe system? One alternative that has some real-world traction is the idea that books should be read from the web, in browsers. The second alternative, not yet realized, would be to create an interoperable standard for digital certificates for encrypted epub files.

But before describing the alternatives in more detail, let's describe the high-level design of the current dominant system. (My understanding trails off pretty quickly - I welcome clarifications and corrections!)

Existing DRM systems embed in encrypted files a description of rights and encryption keys (for epub these are xml files in the META-INF folder). An e-reader using Adobe's Adept system (for example) uses a per-user key to decrypt the per-book key (which then unlocks the content). The per-user key is granted you by Adobe and linked to a set of machine IDs. Adobe's Adept allows you to "register" six devices against your Adobe account. So you authenticate to an account, and to a set of machines. (See chart below): you get encrypted files, these are opened by authenticating against your machines and your identity (and matched to your purchasing data, etc) by a central authority (Amazon, Apple, Adobe). The Adobe system allows the rights you are granted to be described in some detail, ie whether your "purchase" allows you to cut and paste the text, etc.

What are the alternatives?

The first alternative is to move away from self-contained and encrypted files, and to migrate book content to "the cloud" for once and for all. Google Books and others are already using this model, as does Amazon for its html5 offering. Google Books does not use traditional DRM because it breaks up and divides the html and assets it sends to browsers in ways that make it difficult for a browser to reconstitute the entirety of the book content (even if you dive into the browser cache, etc). You can access your books from any device, anywhere, as long as you authenticate to your account. So, in sum, you get access to files in a server, authentication is to your personal account, the authority (Google or others) not only has your personal purchase details but it tracks in detail all of your reading behavior.

The good people at Booki.sh (a Melbourne-based books-in-browsers provider recently purchased by OverDrive), argue that delivery to the browser will always be more secure than DRM that encrypts a single file. DRM-locked files have a single point of failure, and as the cliché has it, all you need are five minutes of Google searching and a couple downloads to find out how to make that point fail.

Pottermore is built on a web-based system, where access is controlled, and reading data captured, by the copyright holder, rather than a vendor. In one alternative future, e-publishing could mean creating suitably feature-rich web presences for books, with readers buying (or licensing, renting, borrowing, etc) access to that web presence. (One of the great achievements of the Booki.sh team has been to make this kind of web access look and feel like downloading a file that you "own", making use of modern browser caches to enable offline reading.)

The "books-in-browsers" model has lots of advantages and can be quite flexible. It's got some momentum now. For one thing it's useful to give content assets a permanent web address. Academic publishers have used permanent URIs for books and articles for many years now, allowing live cross-references, clickable footnotes. etc. "Appropriate copy" linking systems enable university library members to move between documents in different proprietary systems with little friction.

The second alternative architecture sticks with encrypting individual files, but builds the encryption/decryption and rights management processes on shared standards. Eric Hellman has sketched out one such architecture as follows:

«A publisher would authorize a set of authorized ebook vendors and a set of authorized ebook reading platforms, which most likely would be overlapping, but not necessarily. When you buy an ebook, you'd get a digitally signed 'proof-of-purchase' that you could redeem with any reading platform.»

Another variant of this approach would be to verify the rights via a third-party registry, run as a utility on published standards/APIs. This would free up publishers from having to authorise individual platforms and vendors.

Of course setting up an industry-wide utility is no easy effort, but such an approach would have the following advantages:
- robust portability, as the proof-of-purchase is registered with the utility, not a vendor or set of vendors
- better privacy, as only the utility needs to know when, where and how you open files
- enabling superdistribution, as we get creative in the design of the rights statements carried with the files
- providing some level of longer-term comfort to buyers, in that the key registry is maintained by a utility, designed to be more robust to failure than any individual company

How about buying a book that bundles the right to give away one copy to a friend, or sell a "used" copy, with the revenue being split between you and the publisher, while you retain the original? This architecture would give industry the incentives to empower social aspects of book culture, not fight them with restrictive DRM.

Publishers are said to be widely discussing the option of "going DRM-free", given the advantage Amazon has gained from the DOJ case. Publishers went along with Amazon's DRM-powered lock-in out of fear of piracy. Now they may abandon DRM for fear of Amazon's power. It's all so responsive!

What is needed is a consideration of how digital rights management could actually empower readers, writers and a rich digital book culture for the longer term, helping to preserve aura and authority in texts, and allow us to build rich social histories of our e-books. Each of the alternatives sketched out above could provide the basis for a better (and different) book business and book culture.

Amazon/Apple/AdobeBooks in BrowsersOpen DRM
What you getPermission to open an encrypted epub filePermission to access a websitePermission to open an encrypted epub file
How you establish that you have permissionPer-user digital certificate linked to a limited number of machines holds proof of rights for a single vendor system Account & passwordPer-user digital certificate holds “proof-of-purchase” or rights assignment, readable by many vendor systems
DisadvantagesVendor lock-in
Long term issues: your book lives only as long as the vendor maintains system and certifies your permission
Privacy concerns: vendor knows your reading behaviour as well as your personal details.
Vendor lock-in (even if vendors are copyright holders and not Google, Amazon, etc)
Long term issues: your book lives only as long as the vendor/publisher maintains its website.
Privacy concerns: vendor knows your reading behaviour as well as your personal details.
Path dependency – are we too far along different roads to move to this?
Still pie-in-the-sky: cannot sell your books now using this method
AdvantagesSell your books nowSell your books now, well, in the near future maybe.
URIs are useful, can allow linking, annotations, etc
Avoids vendor lock-in
Better privacy
Enables super distribution
Shifts long-term responsibility where it belongs (to a utility)

Tags: 

article type: