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. 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