Why social DRM makes sense: Wise words from book maven Mike Shatzkin
March 24, 2009 | 8:02 am
By David Rothman
Consultant Mike Shatzkin of Idea Logical is a veteran book guy who sees the whole picture—e-books, p-books, brick-and-mortar stores, you name it, based on his decades in the business.
So I’d hope that Random House, S&&, Hachette and others using traditional DRM would pay special attention to his thoughts on social DRM, which would discourage piracy by embedding names of e-book purchasers.
Mike and I don’t always agree. But we certainly do on the basic idea of social DRM. In an e-mail exchange with me, where among other things I asked about that approach, Mike writes:
It seems to me that social DRM—placing the purchaser’s name and perhaps other data (most aggressive: their credit card number) on the files they buy would be adequate to suppress the piracy people fear. I have heard it said that these watermarks can be erased, but then it is also said that all DRM schemes can be hacked. The advantage of social DRM is that it doesn’t interfere with the kind of sharing uses (between one computer and another of mine; or letting my wife read something I’ve bought) that most reasonable people should find acceptable.
No DRM would be even better, as I see it. But social DRM, despite negatives such as privacy risks, is far, far better than traditional DRM which makes it impossible to own e-books for real. I’d buy a lot more e-books if they came with social DRM rather than the traditional variety. The longer Kindle owners own their machines, the more likely they’ll feel like me.
Look, big publishers, it’s too late to slow down e-books by hobbling them with DRM. They’re your future market—a way to reach people who would never step into bookstores, now dwindling in number.
On the issue of Amazon’s new iPhone/Kindle-format initiative and the company’s refusal to do ePub, Mike tells me:
There is no question that Amazon’s proprietary system presents them with the key advantage of lock-in. I’m sure that’s why they do it. I agree that it is something publishers should fear, but a) I’m not sure why Amazon should act in anybody’s interests but their own and b) it undercuts the argument that open standards are necessary to achieve useful device interoperability.
Separately but in a very related vein, Nick Bogaty of Adobe says as quoted in a Stanza Twitter: "There is no technical reason for Amazon not to support epub."
In other words, Amazon is less interested in openness than in herding people into its format.
Detail: eReader is already using a credit-card-number-based system—with the numbers scrambled—to discourage piracy. Alas, this still means that different versions of eReader are required to read the same file on different kinds of devices. But at least eReader is less obnoxious than, say, Mobipocket. Random House and other majors are letting books appear in eReader former. But they might want to consider working with Fictionwise (eReader’s owner, recently bought by Barnes & Noble) on a version without credit card numbers involved—just straight ePub files embedded with owners’ names.
Related: Social DRM vs. traditional Mobipocket-style DRM: Time for a switch?
And speaking of Mike: See his thoughts and Adam Hodgkins’ on biz models on Google, Sony, Apple and Amazon. Key sentence from Mike: "…as Hodgkin sees it, Google and Apple are pursuing directly opposite strategies to bring the ebook business to themselves. Google is betting that the future is licensing whole libraries in the cloud and Amazon is betting that it is buying ebooks one at a time to download to your device."
Image credit: CC-licensed photo by caseywest.



Previous

SUBSCRIBE TO RSS
Comments:
Since social DRM can be scrubbed out of a file, it is essentially pointless… it will not stop those who want to share files, nor those who want to find them. So why bother?
The best social DRM is to sell a product in a way that makes your customers appreciate you enough to shun the idea of taking advantage of you. It’s called “value-added” products.
On a related note, there should be no technical reason why HTML files need to undergo conversion to *.azw files in order for the Kindle to display them.
My RSS delivery service, kindlefeeder.com, goes through a circuitous process of generating an HTML file from RSS feeds and sending it off to Amazon for conversion into an *.azw file that the Kindle can display.
Even before sending off the HTML to be converted, Kindlefeeder does extensive pre-processing on RSS content, stripping out tags that the Amazon Digital Text Platform doesn’t allow, and converting everything into safe ASCII to be compatible with ISO-8859-1, the character encoding required by DTP.
Why does DTP-compatible HTML have to be converted to *.azw in order to display on the Kindle? I wonder. The Kindle has a web browser that reads web pages. So why can’t it directly read documents that contain a strictly controlled subset of HTML?
Just as you noted, I’m suspecting it might be because some people at Amazon — probably members of the proprietary party, as opposed to the open, forward-thinking party — want to foster lock-in. The Kindle could be a far more fertile and generative platform if you could directly send or copy an HTML document to it and read it, without going a seemingly wasteful and superfluous conversion process on Amazon’s servers.
I have some sympathy for Amazon’s lock down of the web browser against local files, because it could be a security hole. However, this would make the device more flexible.
Try renaming the .html to .txt. I have no idea what fraction of HTML markup this approach supports, but renaming has been “good enough” for simple single-file html ebooks on the Kindle. If you want multi-file HTML or images, then there is still no need to send to Amazon. Just use Calibre (say) to convert from HTML to MOBI.
My credit card number embedded in my ebook? … Not for me, thank you. Credit Card companies would not be amused. Nor will publishers be happy when the lawsuits come pouring in. Last year, more than 1.2 million cases of identity fraud were reported to the FTC. The estimated losses amounted to more than 1.8 billion dollars. If your identity is stolen, to deal with the problem, the average person must spend 330 hours of time.
You think epiracy is a problem now? … Imagine the new black market for selling ebooks — ebooks with valid names and credit card numbers inside.
Whether it is data or meta-data, whether the format is PDF or ePub or mobi — any added information can be removed from an unencrypted ebook in less time than it takes to read this sentence.
I would be honored to have my name included in every ebook I buy — especially if it could appear on the dedication page:
“To a treasured customer, an excellent ebook consumer with extraordinary taste in literature … YOUR NAME HERE.”
My name is OK to include. But please, let’s not get any more personal than that.
Michael Pastore
50 Benefits of Ebooks
Hey, Michael, as noted, there are ways to scramble credit card numbers. If eReader, which uses such an approach, had had problems with leaked numbers, I’d have known.
My own preference, if social DRM is to be used, is for credit card numbers NOT to be involved.
> My name is OK to include
Exactly. And maybe a snail address. But, hey, that’s generally public anyway.
Thanks,
David
David,
You have confused me and that is good — because after the dust settles I will understand this issue better than I did before.
It must be that eReader is using some kind of DRM system beyond social DRM, since my credit card number is used to unlock the ebook on my handheld device.
This isn’t Social DRM: it is DRM using the credit card number as the unlocking key.
Social DRM (according to a TeleRead article by David Rothman)
http://www.teleread.com/2007/02/07/adobes-bill-mccoy-on-social-drm/
is simply stamping the ebook with the name (or other information) about the buyer. Everyone who looks at the ebook can see this information; and that “social” nature of this shared information is the piracy deterrent.
With social DRM, there is no “unlocking” key required: that is DRM proper, or what has been called “hard DRM”.
True or false: eReader uses “hard” DRM, not social DRM?
I’m guessing this from reading the eReader FAQ pages: so please help me to figure this out.
Thanks … Michael
Thanks, Michael, but the definition of “social drm” is still a bit up in the air. At this point I myself am thinking of it mainly as the use of the purchaser’s name and snail address–not with the credit card info. I think that the “everyone can see” factor is the most important and most desirable.
As for eReader, it does use social DRM, in the sense that it includes “From the Library of…” But it also includes scrambled credit card numbers. For social DRM purists, that would be beyond social DRM and perhaps even be in the realm of “hard DRM.”
I’d welcome perspective on the above from others, including, of course, Steve or Scott at Fictionwise/B&N, the owners of the eReader format.
Let me add that Steve and Scott prefer that there not be any DRM. They also offer multiformat books in different formats without “protection.” Ideally publishers will catch up in time. Mike Shatzkin’s name is well known among them, which is why his comments are so helpful.
Thanks,
David
Regarding the embedding of the purchaser’s name in the book and “From the Library of….”
This idea could be turned into a really cool feature. Imagine embedded digital bookplates designed by talented–and perhaps famous–artists. The merchant could charge extra for these, the artist could make some money, and the book buyer would have bragging rights. And that’s just for openers. There are a million other neat things that could be done with social DRM that could benefit all parties involved.