Slashdot Mirror

Let's try this instead:

wget http://www.planetebook.com/ebooks/1984.pdf

or 2 page layout:

wget http://www.planetebook.com/ebooks/1984-2.pdf

wget http://www.msxnet.org/orwell/print/animal_farm.pdf

I have mod points. Happily sacificed. Now on the count of three - everybody wget 'em ;)

"License to read" == bullshit.

Let's try this instead:

wget http://www.planetebook.com/ebooks/1984.pdf

or 2 page layout:

wget http://www.planetebook.com/ebooks/1984-2.pdf

wget http://www.msxnet.org/orwell/print/animal_farm.pdf

I have mod points. Happily sacificed. Now on the count of three - everybody wget 'em ;)

"License to read" == bullshit.

Instead coming to get me, wget http://www.planetebook.com/1984.asp and http://www.asiaing.com/animal-farm-by-george-orwell.html I'm no legal expert (I gave up on trying to understand the law), but these novels are impiratable since their copyright has expired (well, I think they have anyway). Even if they weren't if Amazon and publishers will do things like this, then they deserve all the piracy they wget! --- Mod this one up, rather than either of my two comments.

(the first link is meant to be http://www.planetebook.com/1984.asp)

To see a bigger image of this thing, click this here.

From the Sklyarov artical

There were several pages about each title available -- Summary, Free PDF Preview, Table of Contents, and a script generated Author Info -- and all pages. For example, the sample link here (now dead) would display a page with Free PDF Preview of the "Making Sense of the C++ Pointer" book.

http://www.mightywords.com/browse/ details_bc05.jsp?sku=MWBCBZ&private Label=false&display=preview

From the Free PDF Preview page there was a link to a PDF file with a preview exists:

http://download-prod.mightywords.com/ MW/BC/MakingSenseoftheCP_ MWBCBZ_p.pdf.

After you paid for the title, you would get the following link to download full version of the eMatter:

http://download-prod.mightywords.com/ MW/BC/MakingSenseoftheCP_ MWBCBZ_e.pdf

The download links for preview and full version differed only by the last character before the extension -- 'p' for preview and 'e' for complete eMatter. So, an unauthorized user could download the full versions of any eMatter.

Man, you guys were MORONS!

Anyone with a hex editor and a working knowlage of javascript could have downloaded and hax0red your books for free. They wouldn't even need a p2p program, or a complex tool like DeCSS!

Designing More User-friendly DRM
MightyWords Ex-R&D Manager Don MacAskill talks about the Security Design Behind eMatter

By Don MacAskill
March 7, 2002

I really enjoyed your technical analysis of MightyWords' eMatter security . As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. I was turned on to the article by Brian Scardina, another core engineer on the project, who also agrees with the analysis.

I should note that exposing the eMatter downloads to anyone and everyone was by design: customers were encouraged to email their purchased eMatter documents to friends. Sharing was a core business concept that we tried to foster.

A little background about our decisions and why we made them

As the article mentions, we made a tough decision: lower security in exchange for a better user experience. From the outset, we had a clear set of goals:

1. A user only has to unlock it once. If possible, pre-unlock it for them during the purchase process.
2. Cross-platform (Windows, Mac, and any flavor of Unix we could)
3. Useable across all devices a user possessed - desktops, laptops, and, we hoped, eventually handhelds, no extra purchase required for each device.
4. No additional downloads (plugins, etc)
5. Acrobat 3.01 with JavaScript (not the then-new 5.0 or the myriad of confusing 4.0x releases) as the lowest required version, with at least the ability to inform Acrobat 3.0 users without JavaScript that they needed to upgrade.
6. Users were not only able to print, but were encouraged to do so.
7. No unique/difficult-to-remember IDs that could get lost and prevent a document from opening. Username & password is something everyone understands and remembers.

The end decision, as the article pointed out, was to use Acrobat's built-in JavaScript & Forms capability. It allowed us to answer all of the above goals in a way which allowed everyone, whether technically savvy or not, to easily use the eMatter they had purchased.

A quick answer to the three security points oulined in the article:

* As noted, trying to hide the JavaScript became pointless when Acrobat 5.0 came out. We built and shipped this incarnation of eMatter as Acrobat 5 was in final beta.
* We didn't want to require Acrobat 5 (or even 4, for that matter) to support digital signatures. Harnessing the huge installed base of Acrobat 3.01+ was a key business decision.
* Obfuscating the JavaScript code was on the tasklist for future revisions, but again, our core focus was on usability, rather than security. Security precautions were a secondary concern.

Designing the system

An analogy we used often during development was that of car door locks. A determined thief would be able to get into any car door through numerous means. All car door locks really do is prevent your average everyday person from violating your car's security and stealing your sunglasses. But it doesn't get in the way of your use of the car.

Most DRM implementations these days are so heavy-handed with their security precautions, they prevent even honest users from enjoying their purchases. And the determined, experienced, and techincal people will always be able to break a given DRM if the incentive is there. Most DRMs provide loads of incentive to break them: you can't use them on two or more devices you own, you can't print your purchases, etc.

Maybe if more companies were willing to acknowledge the obvious and just work on car door-type locks, digital distribution of content would really catch on.

Don MacAskill
Ex-R&D Manager,
MightyWords Inc.

More Info

* Sklyarov Examines Security Behind MightyWords eMatter, Planet eBook, February 19, 2002
* onethumb.com

Designing More User-friendly DRM
MightyWords Ex-R&D Manager Don MacAskill talks about the Security Design Behind eMatter

By Don MacAskill
March 7, 2002

I really enjoyed your technical analysis of MightyWords' eMatter security . As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. I was turned on to the article by Brian Scardina, another core engineer on the project, who also agrees with the analysis.

I should note that exposing the eMatter downloads to anyone and everyone was by design: customers were encouraged to email their purchased eMatter documents to friends. Sharing was a core business concept that we tried to foster.

A little background about our decisions and why we made them

As the article mentions, we made a tough decision: lower security in exchange for a better user experience. From the outset, we had a clear set of goals:

1. A user only has to unlock it once. If possible, pre-unlock it for them during the purchase process.
2. Cross-platform (Windows, Mac, and any flavor of Unix we could)
3. Useable across all devices a user possessed - desktops, laptops, and, we hoped, eventually handhelds, no extra purchase required for each device.
4. No additional downloads (plugins, etc)
5. Acrobat 3.01 with JavaScript (not the then-new 5.0 or the myriad of confusing 4.0x releases) as the lowest required version, with at least the ability to inform Acrobat 3.0 users without JavaScript that they needed to upgrade.
6. Users were not only able to print, but were encouraged to do so.
7. No unique/difficult-to-remember IDs that could get lost and prevent a document from opening. Username & password is something everyone understands and remembers.

The end decision, as the article pointed out, was to use Acrobat's built-in JavaScript & Forms capability. It allowed us to answer all of the above goals in a way which allowed everyone, whether technically savvy or not, to easily use the eMatter they had purchased.

A quick answer to the three security points oulined in the article:

* As noted, trying to hide the JavaScript became pointless when Acrobat 5.0 came out. We built and shipped this incarnation of eMatter as Acrobat 5 was in final beta.
* We didn't want to require Acrobat 5 (or even 4, for that matter) to support digital signatures. Harnessing the huge installed base of Acrobat 3.01+ was a key business decision.
* Obfuscating the JavaScript code was on the tasklist for future revisions, but again, our core focus was on usability, rather than security. Security precautions were a secondary concern.

Designing the system

An analogy we used often during development was that of car door locks. A determined thief would be able to get into any car door through numerous means. All car door locks really do is prevent your average everyday person from violating your car's security and stealing your sunglasses. But it doesn't get in the way of your use of the car.

Most DRM implementations these days are so heavy-handed with their security precautions, they prevent even honest users from enjoying their purchases. And the determined, experienced, and techincal people will always be able to break a given DRM if the incentive is there. Most DRMs provide loads of incentive to break them: you can't use them on two or more devices you own, you can't print your purchases, etc.

Maybe if more companies were willing to acknowledge the obvious and just work on car door-type locks, digital distribution of content would really catch on.

Don MacAskill
Ex-R&D Manager,
MightyWords Inc.

More Info

* Sklyarov Examines Security Behind MightyWords eMatter, Planet eBook, February 19, 2002
* onethumb.com

Designing More User-friendly DRM
MightyWords Ex-R&D Manager Don MacAskill talks about the Security Design Behind eMatter

By Don MacAskill
March 7, 2002

I really enjoyed your technical analysis of MightyWords' eMatter security . As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. As one of the core engineers of the concept and implementation, I thought it was absolutely accurate and correct. I was turned on to the article by Brian Scardina, another core engineer on the project, who also agrees with the analysis.

I should note that exposing the eMatter downloads to anyone and everyone was by design: customers were encouraged to email their purchased eMatter documents to friends. Sharing was a core business concept that we tried to foster.

A little background about our decisions and why we made them

As the article mentions, we made a tough decision: lower security in exchange for a better user experience. From the outset, we had a clear set of goals:

1. A user only has to unlock it once. If possible, pre-unlock it for them during the purchase process.
2. Cross-platform (Windows, Mac, and any flavor of Unix we could)
3. Useable across all devices a user possessed - desktops, laptops, and, we hoped, eventually handhelds, no extra purchase required for each device.
4. No additional downloads (plugins, etc)
5. Acrobat 3.01 with JavaScript (not the then-new 5.0 or the myriad of confusing 4.0x releases) as the lowest required version, with at least the ability to inform Acrobat 3.0 users without JavaScript that they needed to upgrade.
6. Users were not only able to print, but were encouraged to do so.
7. No unique/difficult-to-remember IDs that could get lost and prevent a document from opening. Username & password is something everyone understands and remembers.

The end decision, as the article pointed out, was to use Acrobat's built-in JavaScript & Forms capability. It allowed us to answer all of the above goals in a way which allowed everyone, whether technically savvy or not, to easily use the eMatter they had purchased.

A quick answer to the three security points oulined in the article:

* As noted, trying to hide the JavaScript became pointless when Acrobat 5.0 came out. We built and shipped this incarnation of eMatter as Acrobat 5 was in final beta.
* We didn't want to require Acrobat 5 (or even 4, for that matter) to support digital signatures. Harnessing the huge installed base of Acrobat 3.01+ was a key business decision.
* Obfuscating the JavaScript code was on the tasklist for future revisions, but again, our core focus was on usability, rather than security. Security precautions were a secondary concern.

Designing the system

An analogy we used often during development was that of car door locks. A determined thief would be able to get into any car door through numerous means. All car door locks really do is prevent your average everyday person from violating your car's security and stealing your sunglasses. But it doesn't get in the way of your use of the car.

Most DRM implementations these days are so heavy-handed with their security precautions, they prevent even honest users from enjoying their purchases. And the determined, experienced, and techincal people will always be able to break a given DRM if the incentive is there. Most DRMs provide loads of incentive to break them: you can't use them on two or more devices you own, you can't print your purchases, etc.

Maybe if more companies were willing to acknowledge the obvious and just work on car door-type locks, digital distribution of content would really catch on.

Don MacAskill
Ex-R&D Manager,
MightyWords Inc.

More Info

* Sklyarov Examines Security Behind MightyWords eMatter, Planet eBook, February 19, 2002
* onethumb.com

This would be nice if the e-version was sold at about half the price of a hard-copy book and you could have one printed up for half the price of a book in the book store. Or just have the option to buy the book with the e-version included. Having *just* an e-version sold would be fine, I think, if you were able to get it printed up with the books-on-demand stuff. Getting it done at Kinkos is okay... but this could be a lot more practical. You know, just some way that I can have either one or both without having to pay twice what it would cost for the regular old book.

just a couple of ideas...

In response to the jurisdiction issue:

I realize I may very be using a prejudiced source in citing the FBI's affidavit filed in court, but here goes.

The affidavit states that AEBPR license keys were sold through Register Now!, and American ecommerce provider, to American buyers, in American currency. Would this not constitute US jurisdiction? Sure, the transactions between Register Now! and US buyers would make those parties liable, but would the transactions between RN and ElComSoft make them culpable within US Jurisdiction?

Secondly, isn't the fact Skylarov is expressly identified as the coyright holder sufficient to warrant his arrest?

According to the affidavit, the splash screen of the program identifies him as the rights holder. I've since been corrected by unconfirmed reports that his name only appears on the 1.0 version, and only then jointly with ElComSoft.

Even so - isn't that enough?

Understand, I'm not saying the DMCA isn't a bogus law that needs to go, just trying to clarify some technical points of the case.

While promoting freedom of speech is nice, it irks me that the poster child for American free speech is just another company trying to make money. If AEBPR were Open Source, then there's something I could REALLY get behind.

I agree with Dmitry Sklyarov's friend and take issue with the use of the word "cracker" to apply to him.

Dmitry is not a hacker/cracker but an exceptional security expert