Without DRM as an option, a standard in the real world of big pubishing can’t be a standard for those people, alas. Let’s stop pretending that it can.

David, I don’t think I’m the one pretending here. I completely agree that DRM is going to be required by publishers, even though the OpenReader folks may, I think somewhat disingenuously, call it “optional”. But what that means is that dotReader (and OpenReader) is a solution to nothing much (though of course OSoft has good business reasons to create dotReader). Even if the books are published as “OpenReader Inside”, they will be coated with opaque DRM which will make them functionally equivalent to current Microsoft Reader books (which are, after all, OEBPS “inside”). By adding another DRM scheme, one might reasonably think that OSoft actually makes the eBabel problem worse, rather than better. By adding another ebook format, one might reasonably think that OpenReader actually makes the problem worse, rather than better.

By contrast, the IDPF efforts seem to be the work of a more-or-less real standards body. (Yes, it’s not the IETF or the ISO, and I realize you’re somewhat unhappy with the results of recent elections.) However, thanks to efforts by Jon and others, they seem to be on the verge of a container specification. If they follow through and produce a half-way reasonable ebook content specification, there might be a chance for the confusion of formats to be at least somewhat reduced. Designs produced by standards committees, of course, typically incorporate a great deal of compromise, and usually are somewhat technically uninspiring, sometimes fatally so. An alternative is to do what Adobe did with PDF — produce your own proprietary but open design, make it popular, then get a standards body to endorse it (PDF/A) down the road, because everyone is using it.

But I think we’ve gotten far enough down a comment thread on a review of the Pepper Pad..

Me: As noted, I’d prefer an open standard. But if the standards setters decide that isn’t the way to go, I’ve also outlined ways to protect the interests of publishers and users. The IDPF approach would not do that. Why are you spending so much time critiquing OpenReader without considering the far less attractive alternatives? Again, however, I’d love an open approach if it’s possible.

Bill: “And who’s bowing to business pressures? I thought that was clear. OSoft is bowing to them, by adding DRM, in order to get material to publish from the publish from the publishing houses. ”

Me: Try talking to publishers without mentioning the D word. They’ll just turn to the far-less-consumer-friendly IDPF approach if we don’t offer a DRM solution. Without DRM as an option, a standard in the real world of big pubishing can’t be a standard for those people, alas. Let’s stop pretending that it can.

Bill: “(That’s a weird sentence, isn’t it? Perhaps OSoft is better considered as a printer or distributor?)”

Me: Nope, that’s the point–it want to see others administer DRM.

Bill: “…It’s not a standard, though, so your argument is irrelevant. Right now, it’s their own secret proprietary scheme, just like Microsoft’s own secret proprietary scheme.”

Me: But shouldn’t the standards setters have a right to evaluate OSoft’s approach along with others? Why are you discriminating against OSoft, which would be willing to show far, far more flexibility than competitors. No good deed…

Bill: “Right now, there is no open standard for DRM. In fact, on technical grounds, I doubt whether such a standard can be constructed in any cost-effective manner.”

Me: Hmm. So you’re saying to forget about DRM standards and thus, in effect, continue the Tower of eBabel? As an eBabel victim, I’d hope you’d empathize more with readers. Bottom line: Without OpenReader involved, IDPF will end up with a closed standard or standards without the protections that OpenReader wants for publishers and readers.

Bill: “Bill: ‘I’m talking about using proprietary DRM to create a ‘locked’ book format, one that only ‘your’ reader (or one from one of your licensees) can open’ ‘Me: There will be no single reader for OpenReader.’ David, you’re shifting ground here. We were talking about dotReader, with its own proprietary “dotReader format” (OpenReader with OSoft’s proprietary DRM scheme), and how (in the DRM mode that publishers demand of OSoft) it will contribute yet another chord to the eBabel cacaphony. ”

Me: Heck, Bill, you’re the one who seemed to be blurring the difference between the reader and the format. As I’ve said, we want other readers to be involved, and the DRM is optional. If the standards setters adopt OSoft’s system, then, as I keep saying, we want safeguards in place that the IDPF won’t offer. And if instead the standards setters adopt an open approach instead, that would be great as well. Whatever’s best for publishers and consumers.

Meanwhile I’ll await your similarly skeptical analysis of the IDPF approach.

Thanks,
David

If OSoft adopts an open standard (as you note earlier, not all standards bodies are created equal, and many standards, particularly for DRM, are not open), or if they publish their own DRM scheme with sufficient detail for a third party to produce a compatible reader, I’ll believe it. Otherwise, it has to be assumed to be mere marketing-speak, I’m afraid.

And who’s bowing to business pressures?

I thought that was clear. OSoft is bowing to them, by adding DRM, in order to get material to publish from the publish from the publishing houses. (That’s a weird sentence, isn’t it? Perhaps OSoft is better considered as a printer or distributor?)

If it’s a standard–and for the nth time I would advise standards setter to consider alternatives as well and impose stringent conditions on OSoft, including the availability of the technology to most anyone–where is the lock-out?

It’s not a standard, though, so your argument is irrelevant. Right now, it’s their own secret proprietary scheme, just like Microsoft’s own secret proprietary scheme. Right now, there is no open standard for DRM. In fact, on technical grounds, I doubt whether such a standard can be constructed in any cost-effective manner.

Bill: “I’m talking about using proprietary DRM to create a ‘locked’ book format, one that only ‘your’ reader (or one from one of your licensees) can open.”

Me: There will be no single reader for OpenReader.

David, you’re shifting ground here. We were talking about dotReader, with its own proprietary “dotReader format” (OpenReader with OSoft’s proprietary DRM scheme), and how (in the DRM mode that publishers demand of OSoft) it will contribute yet another chord to the eBabel cacaphony.

The former could happen under the strict supervision of outside techies and the publishing industry, with costs kept to a minimum and opportunities for other companies to profit. Just keep in mind us end uers. I’m sick of machine-oriented DRM. Come up with a good open source technique using OSoft’s approach and just as user-friendly and reliable, and count me in–after there’s a consensus on its merits.

One way or another, OpenReader needs to avoid the present mess. I don’t trust the IDPF to be objective–not with ETI chairing both the container and format groups. That’s why we need for things to happen under OASIS-style rules with a greater range of standards setters involved than the IDPF wants.

Whether the end result is OSoft’s system or another, the end product will be far, far superior to anything that IDPF could cook up. I think the publishers eventually will go along, tearing down the Tower of eBabel once and for all. It’s plain dangerous for them to rely on either the IDPF or, say, Adobe–which as you know has had its share of security-related problems. Whatever system is chosen needs to be tire-kicked by appropriate experts, who, if need be, can sign NDAs. Again, however, I’d love for the system to be open if security can be maintained. Let the standards setters answer that question once and for all.

Some answers to specific points:

Bill: “I’m talking about using proprietary DRM to create a ‘locked’ book format, one that only ‘your’ reader (or one from one of your licensees) can open.”

Me: There will be no single reader for OpenReader. FBReader plans to be able to read us, and that’s terrific. I hope more implementers will join in. Want a BillReader to read OpenReader? Jon can help. Beyond that, keep in mind that OSoft’s dotReader does not require the use of DRM system. That’s optional.

So what about DRM for publishers insisting on it, as most of the big houses do? If OSoft wanted its DRM system to be standard and if the standards setters agreed, the standard setters could dictate the business terms to protect the licensees and also make the terms much easier on publishers than the alternatives with which Adobe would love to saddle us. Otherwise, no go. I also wonder about the possibility of foundations or the publishing industry buying up the technology, so that an industry organization rather than OSoft owns it. Again, this is assuming that the OSoft standard holds up against alternatives. We don’t know who’ll win.

Bill: “I fail to see why locking up books as a result of bowing to business pressure from business partners should for some reason be seen as more virtuous than locking up books for other reasons.”

In details above and earlier, I’ve explained the considerable differences. A Microsoft-style lockup not! OSoft does not want to administer the DRM. And who’s bowing to business pressures? OSoft has a very user-friendly system, the reason for my interest. Plus, I’m saying that it’s the standards setters who’ll decide, acting under OASIS rules–with a number of people involved. That’s the problem with the IDPF approach. ETI and Adobe are dominating.

Bill: “Won’t a consumer who buys one of these DRM’ed dotReader books be similarly locked out of their purchased content?”

If it’s a standard–and for the nth time I would advise standards setter to consider alternatives as well and impose stringent conditions on OSoft, including the availability of the technology to most anyone–where is the lock-out? Especially if the system is used with the understanding that consumers are guarateed access to their books. OSoft’s position already is, “You buy it, you own it.”

Bill: “What’s the effective difference between this and any other proprietary DRM scheme? Where’s the solution to your tower of eBabel here?”

Me: A standard in this case needs to mean one tongue blessed by a standards body–whether it wants OSoft’s DRM or another solution. Couldn’t be simpler.

By the way, Bill, in case you haven’t noticed, OSoft’s reader can be made to read most anything XMLish, including a BillReader. So if the IDPF wins out instead of OpenReader, it isn’t as if OSoft will be history. Of course, that would still leave open the DRM issue. I highly doubt that Adobe’s rates would be as attractive to publishers as OSoft’s will, especially under the arrangements I’ve mentioned if the OSoft system wins out.

Once again, Bill, the operative word is “if.” Please don’t distort OpenReader’s position or my own by saying we think that the OSoft approach is the only option. Absolutely false. It’s just one of a bunch to be considered. Ideally this note has repeated “if” enough for you.

Thanks,
David

Heck, Bill, OSoft’s DRM is there only because publishers required it. The company is originally tried in vain to do a reader without DRM. A lock-up effort not!.

A lock-up effort indeed! I’m talking about using proprietary DRM to create a “locked” book format, one that only “your” reader (or one from one of your licensees) can open. I fail to see why locking up books as a result of bowing to business pressure from business partners should for some reason be seen as more virtuous than locking up books for other reasons. Won’t a consumer who buys one of these DRM’ed dotReader books be similarly locked out of their purchased content? What’s the effective difference between this and any other proprietary DRM scheme? Where’s the solution to your tower of eBabel here?

Besides, the forthcoming dotReader has lots of good things going for it, including the willingess and in fact eagerness of OSoft to avoid a Microsoft-style DRM chokehold. OSoft wants others to administer the DRM and would even allow other companies to use the technology without gouging them. We’re talking about pragmatic people committed to standards…

Color me skeptical. Of course, if they decide to publish the details of their DRM system, so that open-source implementations of it can be constructed, or if they decide to scrap it and adopt an open published DRM scheme from some standards group, I’d be a believer. Right now, though, from the little I know of it, it looks like just another proprietary DRM scheme that will further fragment the eBabel market.

Back to the Pepper. Who knows, I may yet be won over on the built-in-keyboard issue for the Pepper–but I wonder if the board couldn’t be in a dfferent location and not split. Perhaps it could even be on the back on the unit, with an entry screen. Or if that gets in the way of true interactivity, maybe the keyboard could be an attachment at the front that could also be detached for more comfortable typing.

Update on screen brightness, 11:05 a.m. EST: It’s cloudy here in the Washington, D.C. I could see the screen comfortably when I read in the shade of a tree; otherwise, the Pepper Pad’s brightness won’t suffice. Oh, well. Perhaps it’ll still work out at the beach if you take a big umbrella.

More on battery life with WiFi: A more precise estimate would most likely be under 2 hours. But then again, the battery I’m using may not have been charged using an optimal pattern.

Thanks,
David

There are very compelling reasons to create a cryptographic infrastructure that would give each person in the world a flexible cryptographic identity using multiple public and private keys. The infrastructure necessary to accomplish this would be vast but it need not be expensive from a per capita viewpoint. In fact it would be delightfully inexpensive compared to the advantages obtainable. Here are just a few of the boons possible:

1) Electronic mail could be encrypted to substantially increase communication security. The newspapers have recently been filled with stories about eavesdropping. This is unsurprising when so much communication today is performed in the “clear” with minimal attempts to provide security.

2) Electronic mail could be digitally signed. This would raise the level of trust in communication. It would also allow a radical reduction in the amount of spam and in the number of bogus solicitations from con artists.

3) Financial transactions could be made more secure. An individual could use one of his digital keys to sign a valid financial transaction.

4) Access to governmental services could be improved. For example, taking out an item from a digital library would be facilitated. Obtaining a license online would be easier.

5) Polling data collection could be improved. For example stock proxy voting, and voting during popular television shows could be done more easily and more accurately. Spoofing and multiple voting could be reduced.

How does this relate to DRM? It would be possible to piggyback on this infrastructure by adding an additional set of keys for DRM. I do not advocate this because as I indicated about I do not think that DRM for ebooks is a good idea.

Besides, the forthcoming dotReader has lots of good things going for it, including the willingess and in fact eagerness of OSoft to avoid a Microsoft-style DRM chokehold. OSoft wants others to administer the DRM and would even allow other companies to use the technology without gouging them. We’re talking about pragmatic people committed to standards, including those orignated from other companies (for example, dotReader can deal with a number of XML-based formats and could even do DRMed PDF if Adobe allowed).

From an OpenReader perspective, however, all this is premature in some important ways. As you note, it will be up to the standards setters to decide on the best DRM system. If you want to be part of the process, then you will help determine the solution. Maybe it will be OSoft’s, maybe it will be interoperable systems from different companies–oh, the possibliities go on and on.

But as an end user, based on what I know so far, OSoft’s approach seems rather attractive. It isn’t machine oriented and also would allow full interactivity, according to what the company says–this is something for the appropriate people, including you, to vet. I’d like to see this happen by the rules of a neutral body such as OASIS. If anyone has a better solution, let that one prevail over OSoft’s. I just hope that there’ll be a better balance between the needs of consumers and the self-perceived needs of the content providers, who are really hurting themselves when they insist on Draconian measures–especially since it’s increasingly easy to scan paper books.

But back to the issue of the standards body. That’s no small factor, IDPF just isn’t to be trusted to be Standards Central, not when people from ETI chair both the container and format groups. This in itself shows the lack of technical talent available to the IDPF. OpenReader favors a more open, more inclusive approach, encompassing more people from outside the e-book-related companies; and to avoid accusations of favoritism, we would prefer that OpenReader founder Jon Noring not run the standards effort. My own preference would be someone from outside the industry, such as Allen Renear, who earlier presided over the once-productive IDPF/OeBPS efforts before business people let the standards group fade away. Standards efforts at the IDPF were revived only when OpenReader started up.

Thanks,
David

Integration with the Mobipocket store online is seamless. The only question I have is, Will this harm independent booksellers? Also, TeleBlog readers already know how I feel about people getting locked into proprietary formats. Oh, to see the Pepper in action with the forthcoming dotReader!

Last I heard (here), OSoft had its own proprietary DRM to lock up books in dotReader format when publishers demanded it. Won’t this put purchasers in exactly the same position they would be in if they bought the book in Mobipocket’s proprietary format, except that now they’d have books in dotReader’s proprietary format? What’s going to change? Are publishers going to forego DRM protection for their books?

Too bad about this eBabel complication. With e-book standards and more openness in software, you might well be moving more Peppers. More competiton in e-book software would be good for consumers. Only one company makes software that can read DRMed Mobipocket, however, and that’s, yes, Mobipocket, Jeff B’s baby. Without a proprietary format involved and with DRM issues addressed by standards-setters, Pepper might not have to wait as long for a final version of the reader.

You suggest here that some kind of common DRM scheme is going to be established by some kind of standards body. Can you say more about those efforts?

Everyone: Sean not only works for Pepper but also is the author of the Pepper Hacks blog. I hope that at some point he’ll have more time to update his useful blog. Great way to encourage developers to write for the machine!

David