Designing a More User-Friendly DRM

onethumb writes: "As one of the core engineers on MightyWords' (now-defunct) DRM for digital documents, I was impressed by Dmitry Skylarov's great analysis of our work the other day. Planet eBook is now running my reply as their feature article explaining our design goals and decisions for our decidedly user-friendly DRM solution."

Comments

Operating Systems That Are DYING!

[Anonymous Coward]

The following operating systems are DYING:

• FACT: AIX is dying.
• FACT: AtheOS is dying.
• FACT: BeOS is dying.
• FACT: BSD is dying.
• FACT: BSD-OS is dying.
• FACT: ChorusOS is dying.
• FACT: Darwin is dying.
• FACT: eCos is dying.
• FACT: FreeBSD is dying.
• FACT: GNU Hurd is dying.
• FACT: HP-UX is dying.
• FACT: HP 3000 is dying.
• FACT: IBM OS/2 is dying.
• FACT: Inferno is dying.
• FACT: INTEGRITY is dying.
• FACT: IRIX is dying.
• FACT: Linux is dying.
• FACT: LynxOS is dying.
• FACT: Mac OS X is dying.
• FACT: Mach is dying.
• FACT: Microkernel is dying.
• FACT: MINIX is dying.
• FACT: MkLinux is dying.
• FACT: Mobius is dying.
• FACT: MS-DOS is dying.
• FACT: NachOS is dying.
• FACT: Nemesis is dying.
• FACT: NetBSD is dying.
• FACT: NeXT is dying.
• FACT: Open Source is dying.
• FACT: OpenBSD is dying.
• FACT: OpenVMS is dying.
• FACT: OS-400 is dying.
• FACT: PalmOS is dying.
• FACT: PIOS is dying.
• FACT: Plan 9 is dying.
• FACT: PowerMAX is dying.
• FACT: pSOS is dying.
• FACT: QNX is dying.
• FACT: Roadrunner is dying.
• FACT: RTEMS is dying.
• FACT: SCO UNIX is dying.
• FACT: Solaris is dying.
• FACT: Tru64 is dying.
• FACT: TUNES is dying.
• FACT: Unix is dying.
• FACT: UnixWare is dying.
• FACT: Visopsys is dying.
• FACT: VSTa is dying.
• FACT: VxWorks is dying.
• FACT: Windows 2000 is dying.
• FACT: Windows 3.11 is dying.
• FACT: Windows 95 is dying.
• FACT: Windows 98 is dying.
• FACT: Windows CE is dying.
• FACT: Windows ME is dying.
• FACT: Windows NT is dying.
• FACT: Windows XP is dying.
• FACT: Xinu is dying.
• FACT: z-OS Unix is dying.

Connectivity allows applications to transparently communicate with other programs or processes, regardless of their location. The key element of connectivity is the network operating system (NOS). NOS provides services such as routing, distribution, messaging, file and print, and network management services. NOS rely on communication protocols to provide specific services. The protocols are divided into three groups: media, transport and client-server protocols. Media protocols determine the type of physical connections used on a network (some examples of media protocols are Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), coaxial and twisted-pair). A transport protocol provides the mechanism to move packets of data from client to server (some examples of transport protocols are Novell's IPX/SPX, Apple's AppleTalk, Transmission Control Protocol/ Internet Protocol (TCP/IP), Open Systems Interconnection (OSI) and Government Open Systems Interconnection Profile(GOSIP)). Once the physical connection has been established and transport protocols chosen, a client-server protocol is required before the user can access the network services. A client-server protocol dictates the manner in which clients request information and services from a server and also how the server replies to that request (some examples of client- server protocols are NetBIOS, RPC, Advanced Program-to-Program Communication (APPC), Named Pipes, Sockets, Transport Level Interface (TLI) and Sequenced Packet Exchange (SPX)).

FACT: These operating systems are DEAD!

In Case It Gets Slashdotted (karma whore alert)

[Jucius Maximus]

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

MS Patent Question

[Alien54]

Just how extensive is the MS patent of the DRM OS?

Is this one of those things that many years after the fact, when they get around to marketing their own product, they turn around, and tell everyone else that they are in violation of the MS Patents, and either cease and desist, or give up the family jewels?

Do we face a situation where people are doing all of Microsoft's work for them? Why should we bother?

Talk about stifling innovation!