If Camden, New Jersey, becomes the first American community to lower its medical costs, it will have a murder to thank. At nine-fifty on a February night in 2001, a twenty-two-year-old black man was shot while driving his Ford Taurus station wagon through a neighborhood on the edge of the Rutgers University campus. The victim lay motionless in the street beside the open door on the driver’s side, as if the car had ejected him. A neighborhood couple, a physical therapist and a volunteer firefighter, approached to see if they could help, but police waved them back.

Legendary film director Francis Ford Coppola talks about how he self-finances all his films, why the artist must never lie, and how true collaboration is like great sex.

Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here next week. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper. Today's section will be (in the final paper) the last part of the technical core of the paper. Readers of the final paper will have seen the rest of our technical analysis by this point. Blog readers haven't seen it all yet – stay tuned. Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready. Compatibility and Software Updates Compared to other media on which software is distributed, compact discs have a very long life. Many compact discs will still be inserted into computers and other players twenty years or more after they are first bought. If a particular version of (say) active protection software is burned onto a new CD, that software version may well try to install and run itself decades after it was first developed. The same is not true of conventional software, even when it ships on a CD-ROM. Very few if any of today's Windows XP CDs will be inserted into computers in 2026; but CDs containing today's CD DRM software will be. Accordingly, CD DRM software faces a much more serious issue of compatibility with future systems. The future compatibility problem has two distinct aspects: safety, or how to avoid incompatibilities that cause crashes or malfunction of other software, and efficacy, or how to ensure that the desired anti-copying features remain effective. Protecting Safety by Deactivating Old Software Safety is the easier attribute to protect, and in most respects the more important. One way to protect safety is to design the DRM software so that it is likely to be inert and harmless on future systems. Both XCP and MediaMax do this by relying on the Windows Autorun feature, which is unlikely to be supported in future Windows versions for security reasons. If, say, the upcoming Windows Vista does not support Autorun (or supports it but disables it by default), then XCP and MediaMax will have no effect on Vista systems. Perhaps the use of Autorun by XCP and MediaMax was a deliberate design decision to ensure safety; but we suspect that it was a side-effect of a design choice that was expedient for other reasons. Another way to protect safety is to build a sunset date into the software, and to program the software to be as inert as possible once the sunset date is reached. Building in a sunset after (say) three years would protect against many safety problems; and it would have little effect on the record label's business model, as we would expect nearly all revenue from monetizing new uses of the music to have been extracted within the first three years after the disc is pressed. If a customer is ever going to pay for iPod downloading, she is likely to do so within the first three years after the CD is pressed. Updating the Software Like any software vendor, a DRM vendor can issue new verions of its products. A new version can be shipped on newly pressed CDs, but existing CDs cannot be modified retroactively. Instead, the vendor can offer updates, which can be delivered either by download or on new CDs. Downloads can occur immediately, but only on machines that are connected to the Internet. CD delivery can potentially reach more machines, but is slower and less certain. Either mode of distribution can be used straightforwardly if the user wants to cooperate. Users will generally cooperate with updates that only provide safety on new systems, or that otherwise increase the software's value to the user. But updates that merely retain the efficacy of the software's usage restriction mechanisms will not be welcomed by users. Users have many ways to block the downloading or installation of updates. They can write-protect the software's code, so that it cannot be updated. They can configure the system to block network connections to the vendor's servers. They can use standard security tools, such as personal firewalls, to stop the downloads. System security tools are often well suited for such a task, being programmed to block unwanted network connections, downloads, and code installation. If a current security tool does not block updates of CD DRM software, the tool vendor has an incentive to make future versions do so. A DRM vendor who wants to offer efficacy-related updates, recognizing that users will not want those updates, has two options. The vendor can offer updates and hope that many users will not bother to block them. From the record label's standpoint, prolonging the system's efficacy for some users is better than nothing. Alternatively, the vendor can try to force users to accept updates. Forcing Updates If a user can block updates of the DRM software on his machine, the vendor's best strategy for forcing an update is somehow to convince the user that the update is in his best interest. This can be done by making a non-updated system painful to use. If we rule out dangerous and almost certainly illegal approaches such as logic bombs that destroy a noncompliant user's files or hold his computer hostage, the vendor's best option is to make the DRM software block all access to protected CDs until the user updates the software. The software might check periodically with some server on the Internet, which would produce some kind of cryptographic assertion saying which versions are allowed to continue operating without an update, as of some date time. If the software on the user's system noticed that no recent certificate existed that allowed its own version to keep operating, it would go into a locked down mode that blocked all access to protected discs but allowed software updates. The user would then have to update to a new version in order to get access to his protected CDs. This approach could force updates on some users and thereby prolong the efficacy of the DRM for those users. However, it also has several drawbacks. If the computer is not connected to the Internet, the software will eventually lock down the user's music because it cannot see any certificates that allow it to continue. (The software could continue working if it can't see the Internet, but that would allow users to block updates indefinitely by configuring their systems to stop the DRM software from making network connections.) A bug in the software could cause it to lock itself down irreversibly, perhaps by accident. The software could lock itself down if the vendor's Internet site is shut down, for example if the vendor goes bankrupt. Locking down the music, or forcing a restrictive software update, can also be counterproductive, by giving the user a reason to defeat or remove the DRM software. (Users could also defeat the timeout mechanism by misleading the DRM software about the date and time, but we expect that most users with the inclination to do that would choose instead to remove the DRM software altogether.) The software is more likely to remain on the user's system if it does not behave annoyingly. Automatic update can reduce the DRM system's efficacy if it just drives users to remove the DRM software. From the user's standpoint, every software update is a security risk, because it might carry hostile or buggy code. Given the difficulties associated with forced updates, and the user backlash it likely would have triggered, we are not surprised that neither XCP nor MediaMax chose to use forced updates.