The following is an expansion upon the notes I took during the talk given by Martin Gorner, the President & CEO of Mobipocket.

Mobi Desktop 6.2 can import EPUB, and will auto-convert an EPUB file to Mobi format so you can read it. He demonstrated this during the presentation.

The next version of Mobi Creator and Mobigen will also support EPUB creation.

By the end of the year, Mobipocket will release updated readers for the various platforms, as well as release a new reader for the Apple iPhone.

Mr. Gorner also said that sales of Mobipocket format e-books have doubled since last year, while giving a breakdown of users by device. I wasn't quite fast enough to get all the data, but I can tell you it's 43 percent Windows Mobile, 23 percent Palm, 6% proprietary (iRex iLiad, Pepper-Pad, etc). The number of Palm users is shrinking, both as a percentage and as an absolute number.

---

When Gorner demoed EPUB support, I was under the impression that Mobi Desktop can read EPUB natively. Well, I just tested it, and my copy of 6.2 converted the EPUB file to Mobi before opening it. Either way, it's a nice step forward!

as well as giving a breakdown of users by device.

I'm curious how they know this. Do they count by downloads? What about devices where the reader is pre-installed like CyBook/iLiad?

BOb

I would guess that Mobipocket can tell what type of device you have based on the PID.

Since you have to provide a PID to download a book, and the book must be encoded by Mobipocket's DRM servers with that PID, Mobipocket at some point will know about each PID.

I would guess that Mobipocket can tell what type of device you have based on the PID.

So are you suggesting that the Mobipocket software is reporting back to the mother ship. You don't actually have to use the Mobipocket software on your PC, right?

Or, are you suggesting that all Mobipocket stores are reporting PID's registered with them back to Mobipocket?

BOb

I would guess that Mobipocket can tell what type of device you have based on the PID.

Since you have to provide a PID to download a book, and the book must be encoded by Mobipocket's DRM servers with that PID, Mobipocket at some point will know about each PID.


The PID is generated from the device's system ID/serial number.

Derek

So are you suggesting that the Mobipocket software is reporting back to the mother ship. You don't actually have to use the Mobipocket software on your PC, right?

Or, are you suggesting that all Mobipocket stores are reporting PID's registered with them back to Mobipocket?

BOb
When you purchase a Mobipocket format eBook, the site you purchase it from has to talk to the DRM server in order to insert the PID(s) you've told the site you want to use. So in effect you are sending your purchase info back to Mobipocket.

Well, since I have my Cybook AND my Treo registered, that must confuse the servers. :)

Overall, I prefer eReader on the Treo anyway.

When you purchase a Mobipocket format eBook, the site you purchase it from has to talk to the DRM server in order to insert the PID(s) you've told the site you want to use. So in effect you are sending your purchase info back to Mobipocket.

Ah, I didn't know the encoding was such a secret that it wasn't provided to Mobi stores as an SDK. Well then, that makes sense that they could get the info from the PIDs.

BOb

Ah, I didn't know the encoding was such a secret that it wasn't provided to Mobi stores as an SDK. Well then, that makes sense that they could get the info from the PIDs.

BOb

Well... It's a "secret" and NOT a "secret". If you look around for the python scripts that detail how to get a Mobipocket PID from a Kindle, that will tell you how a PID is developed.

And the python scripts which decrypt the Mobi DRM will show you how the Pukall cipher (PC1) works. Given those tools, there's no reason to not incorporate Secure Mobipocket support into FBReader.

Derek

And the python scripts which decrypt the Mobi DRM will show you how the Pukall cipher (PC1) works. Given those tools, there's no reason to not incorporate Secure Mobipocket support into FBReader.


hmm.. if that's the case, I wonder why they haven't added it.

BTW: Do you get the same PID on the same device all the time?

So it uses the PC1 cipher with the PID as the key?

BOb

Well... It's a "secret" and NOT a "secret". If you look around for the python scripts that detail how to get a Mobipocket PID from a Kindle, that will tell you how a PID is developed.

And the python scripts which decrypt the Mobi DRM will show you how the Pukall cipher (PC1) works. Given those tools, there's no reason to not incorporate Secure Mobipocket support into FBReader.

Derek

Except a legal one.

Dale

hmm.. if that's the case, I wonder why they haven't added it.

BTW: Do you get the same PID on the same device all the time?

So it uses the PC1 cipher with the PID as the key?

BOb

Yes, the PID is fixed on a given device/machine. And if you buy a new computer and install Mobireader, you'll get a *brand new* PID and all your old books won't open until you register that PID and re-download them. (Note I did NOT say you have to re-purchase them.)

And, yes, the PC1 cipher will, with the PID as the key, decypher them.

Derek

Except a legal one.

Dale

Well, *IF* the "decryption" were performed "on-the-fly" on an internal-to-FBReader file and that file weren't saved to disc - in other words, this decryption took place every single time one chose to read the ebook - I can't really see how it would violate the law. The PID would be "unique" to the user's device. The ebook would have been legally purchased. FBReader would not create a permanent "decrypted" version. Sorry, but nowhere does it say one *MUST* use Mobipocket Reader to read the Secure Mobipocket ebooks. And in point of fact, the iLiad version was created - then got approval from Mobipocket.

Now if Mobipocket wants to get all "legal" over a program designed to permanently remove the DRM so the legally-purchased ebook can be shared amongst people, I'm down on Mobipocket's side. But to be aghast at another application allowing reading - by the person who purchased the Mobi ebook - while not crushing the developers who did so for the iLiad, nope, I don't buy the argument.

Derek

And, yes, the PC1 cipher will, with the PID as the key, decypher them.


I'm curious how it does this with multiple PIDs. Most asymetric ciphers use a key to convert plain text to cipher text. I'm not sure how this would work with 3 keys. Unless the whole file isn't encrypted and there is just some header. Hmmm...

BOb

Mobi Desktop 6.2 can import EPUB, and will auto convert an epub file to Mobi format so you can read it. I tried one of Adobe's sample ebooks (http://www.adobe.com/products/digitaleditions/library/), Alice's Adventures in Wonderland. It displays well in Adobe Digital Editions, including the text wrapping around images. FBReader displays it ok too, but without CSS support it does not wrap the text or style the chapter heading. In MobiPocket Reader, a MOBI version was produced but without any images and with character encoding errors.

MobiPocket Reader did better on Red Alert, another Adobe sample ebook. However, Digital Editions and MobiPocket Reader display the chapter title in different colors.

Both MobiPocket Reader and FBReader fail to produce a TOC from the toc.ncx file for both ebooks. When I tried mobigen (rather than MobiPocket Reader) the console messages indicate that the toc.ncx file is read, but no TOC was produced.

MobiPocket Reader failed to convert the only epub example I have with SVG graphics, but it is seriously non-conforming and so this might not have been due to the SVG content.

I'm curious how it does this with multiple PIDs. Most asymetric ciphers use a key to convert plain text to cipher text. I'm not sure how this would work with 3 keys. Unless the whole file isn't encrypted and there is just some header. Hmmm...

BOb


You know... *I'm* not sure myself. I mean, I've got four PIDS registered with Mobipocket and Fictionwise and when I buy a Secure Mobipocket ebook and download it, I don't have to download one for each of my devices - one download does it all.

Derek

You know... *I'm* not sure myself. I mean, I've got four PIDS registered with Mobipocket and Fictionwise and when I buy a Secure Mobipocket ebook and download it, I don't have to download one for each of my devices - one download does it all.

Derek

I wonder if the file is a compressed package with one copy of the document for each PID. Is the document smaller when you have 1 PID registered with the store as opposed to 4?

BOb

I wonder if the file is a compressed package with one copy of the document for each PID. Is the document smaller when you have 1 PID registered with the store as opposed to 4?

BOb


I haven't tested it. Nor am I willing to go through the hassle of deleting PIDs from the registered PID lists to find out. I've had hassles changing/adding them before. Sorry.

Derek

Wallcraft, did you downloaded this (http://adedemo.com/Title-XHTML.asp?InventoryID={861EF1FE-266A-4C9D-A6BB-6B63D3E1F420})one? If that's the one you had, did you notice the restrictions on it? The conversion could have failed because of the DRM put on the file by Adobe.

XHTML Rights:
Copying not allowed
Printing not allowed
Lending not allowed
Reading aloud not allowed

P.S. Try one from Feedbooks instead. I'll try some also.

If that's the one you had, did you notice the restrictions on it? That is the one, but I never got to the full web page on the ebook. It does not have DRM, and I don't see these restrictions in the actual .epub. The .opf file says: <dc:rights>Public Domain</dc:rights> What it does have is an embedded font, which might be part of the problem.

I have tried EPUBs from feedbooks, and they work except that the .ncx file is again ignored. There is a TOC, but it comes from the guide section of the .opf file rather than the .ncx file.

That is the one, but I never got to the full web page on the ebook. It does not have DRM, and I don't see these restrictions in the actual .epub. The .opf file says: What it does have is an embedded font, which might be part of the problem.

I have tried EPUBs from feedbooks, and they work except that the .ncx file is again ignored. There is a TOC, but it comes from the guide section of the .opf file rather than the .ncx file.

If there is no DRM, then the conversion should have worked. I tried a couple from Feedbooks, and you're right. It leaves much to be desired.

There is a vast amount of data in the epub file. The conversion should be just as good as a conversion from an exploded MSLIT.

I haven't tested it. Nor am I willing to go through the hassle of deleting PIDs from the registered PID lists to find out. I've had hassles changing/adding them before. Sorry.


No big deal. Just my geek/programmer curiosity.

BOb

I wonder if the file is a compressed package with one copy of the document for each PID. Is the document smaller when you have 1 PID registered with the store as opposed to 4?

BOb

No, it isn't. I've just re-downloaded my (extremely large) Chambers Dictionary having added the PID of my new Gen3. The file is the same size.

No, it isn't. I've just re-downloaded my (extremely large) Chambers Dictionary having added the PID of my new Gen3. The file is the same size.

Thanks for the info. The plot thickens.

BOb

Thanks for the info. The plot thickens.

Not necessarily. One way to achieve this would be a two-step process where you encrypt each book with a key unique to that book, then encrypt the key needed to decrypt the book with the PID. If the mobipocket format has a fixed place to store the decryption key four times for each of the four PIDs allowed, the size doesn't need to change.

If you assume a 2048 bit key for encrypting/decrypting the book, then storing four encrypted versions of that key takes 1 kB, which isn't that much.

I don't know if this is what happens, but IIRC, this is how gnupg works if you encrypt an email for multiple recipients (except that gnupg doesn't have a fixed number of "slots", so each additional recipient you encrypt the message for enlarges the whole thing by a couple hundred bytes).

I have tried EPUBs from feedbooks, and they work except that the .ncx file is again ignored. There is a TOC, but it comes from the guide section of the .opf file rather than the .ncx file.

Which will generate a very ugly TOC then since we follow the advice from Adobe's best practice guide and divide our books into multiple-flows.

I guess that currently, they generate the TOC this way, because that's how OEBPS1.0 worked with an OPF and they didn't changed anything compared to their normal Mobipocket generation.

Not necessarily. One way to achieve this would be a two-step process where you encrypt each book with a key unique to that book, then encrypt the key needed to decrypt the book with the PID. If the mobipocket format has a fixed place to store the decryption key four times for each of the four PIDs allowed, the size doesn't need to change.

If you assume a 2048 bit key for encrypting/decrypting the book, then storing four encrypted versions of that key takes 1 kB, which isn't that much.

I don't know if this is what happens, but IIRC, this is how gnupg works if you encrypt an email for multiple recipients (except that gnupg doesn't have a fixed number of "slots", so each additional recipient you encrypt the message for enlarges the whole thing by a couple hundred bytes).

There's a 16-byte primary key (the same across all Secure Mobipocket ebooks) and a 10-byte PID key. That gives 128 bits in the hidden key and 80 bits in the PID key. I suppose you should study how the various decryption python scripts handle it all.

Derek

Reading aloud not allowed


*is amused* How would they enforce that one. :chinscratch:

*is amused* How would they enforce that one. :chinscratch:

The Windows version of Microsoft Reader has a "reading aloud" feature (which actually works pretty well). It's disabled for books with DRM.

Oh, I didn't know that. But still, you have to admit it sounds awfully funny to not allow something to be read aloud. :p

Even if the program won't read it aloud, nothing is stopping the person who bought it from doing so. I fail to see how disabling that protects much of anything.

Oh, I didn't know that. But still, you have to admit it sounds awfully funny to not allow something to be read aloud. :p

Even if the program won't read it aloud, nothing is stopping the person who bought it from doing so. I fail to see how disabling that protects much of anything.

this is a side effect of what they don't allow, not the main intent. The read aloud software has to have access to the data. Providing this permission also allows a DRM hole which is what they are really trying to block.

Dale

...But still, you have to admit it sounds awfully funny to not allow something to be read aloud. :p

Even if the program won't read it aloud, nothing is stopping the person who bought it from doing so. I fail to see how disabling that protects much of anything.

The main thing it really protects from is allowing the blind to use the almost always cheaper ebook version (instead, forcing them to purchase the overpriced audiobook, instead). That may not be the "reason", but it is the effect.

One positive side effect is that it prevents parents from giving the kids the book and leaving them to have it read to them by the computer, forcing the parent to read to the child themselves (although, face it, for that type of parent it just means they leave the kid in front of the tv instead).

The read aloud function is also helpful to those who have poor reading skills or who are learning a new language (although the pronunciation can be off a bit for this use).

Back to the main thrust of this thread. I opened the free ebook "Three shadows" with Mobipocket Reader on my PC. It is an unDRMed graphic epub novel. I then exported it to my Cybook Gen3 (one of the readers registered with the desktop Mobipocket Reader) and it works fine on the Cybook.:thumbsup:

In the USA, if you purchase an eBook where the DRM for it stops the read aloud feature you are legally allowed to break the DRM so read aloud works.

So MS Reader files are legal to have the DRM removed.

In the USA, if you purchase an eBook where the DRM for it stops the read aloud feature you are legally allowed to break the DRM so read aloud works.

So MS Reader files are legal to have the DRM removed.

If you have a real need for the feature. It cannot be used as an excuse.

Dale

In the USA, if you purchase an eBook where the DRM for it stops the read aloud feature you are legally allowed to break the DRM so read aloud works. The actual current, November 2006, exception to the DMCA is (from Wikipedia (http://en.wikipedia.org/wiki/DMCA#Anti-circumvention_exemptions)):

Literary works distributed in ebook format when all existing ebook editions of the work (including digital text editions made available by authorized entities) contain access controls that prevent the enabling either of the book’s read-aloud function or of screen readers that render the text into a specialized format. (Revised from a similar exemption approved in 2003.)

The problem is that some other ebook version might allow reading aloud, and sometimes "authorized entities" have unlocked versions that are available to those with disabilities.

However, this does narrow the number of cases where someone could be sued for format shifting a DRM-ridden ebook for their own personal use.

The actual current, November 2006, exception to the DMCA ...:

"...contain access controls that prevent the enabling ... of screen readers that render the text into a specialized format."

so, anyone who needs a larger font on a non-backlit screen due to their eyes, would be allowed to break the DRM and transfer it to the Kindle (just as others break DRM to be able to listen)? Right?

If someone besides Koland suggested this, I missed it... but it seems to provide an easy way to convert any ePub files to your Kindle. That's always cool!

so, anyone who needs a larger font on a non-backlit screen due to their eyes, would be allowed to break the DRM and transfer it to the Kindle (just as others break DRM to be able to listen)? Right? It is my understanding that the exception is available to everyone, but its purpose is to allow access to those with disabilities.

I am not aware of anyone being sued in the US for breaking the DRM of an ebook they bought for the sole purpose of format shifting for personal use (which is an established "fair use" in the US, except for the DMCA's prohibition of DRM circumvention). This exception is very close, in practice, to saying that this is legal (given that all DRMed ebooks contain these access controls), but it obviously does not say this explicitly.

But it is still (apparently) illegal to publish DRM breaking SW as I understand it.:blink:

so, anyone who needs a larger font on a non-backlit screen due to their eyes, would be allowed to break the DRM and transfer it to the Kindle (just as others break DRM to be able to listen)? Right?
You would have to purchase it in a format that allows reading aloud. So you'd have to get it in MS Reader format and then yes, feel free to format shift.

PDF has also the option to read aloud.

Out of curiosity, has anyone ever heard anything more about the thing mentioned at the start of this thread—Gorner's remarks that Mobipocket would release an iPhone client "by the end of the year"?

It's starting to get pretty close to the end of the year, and not a peep has come out of Mobipocket about such a thing.

It's three months away still :).

I've just written an article about the mysterious absence of a Mobipocket reader for the iPhone, Mac, or Linux:

http://www.teleread.org/blog/2008/12/02/missing-iphone-mobipocket/

Enjoy.

Maybe I should have started a new thread for this as I'm not sure anyone's reading this one anymore.

But I heard from a highly-placed source (who spoke to me on condition of anonymity). This source claimed to know with certainty that Mobipocket had its reader for the iPhone ready to go in August, but that Amazon forced them not to release it.

http://www.teleread.org/blog/2008/12/04/is-amazon-sitting-on-the-mobipocket-iphone-client-after-all/

Isn't that interesting?