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.
As regards DRM which becomes obsolete rendering the purchased work useless, the British Library are already having considerable problems with this, and have submitted evidence about it to the investigation the UK Government are currently undertaking into DRM.
Link:
http://news.zdnet.co.uk/business/legal/0,39020651,39250168,00.htm
“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.”
It seems to me that the user already had a reason to defeat or remove the DRM software: it restricts usage of the CD. I would see the above sentence as more accurate if the phrase were something like “giving the user further reason.”
Steve R., you wrote, “I advocate the they avoid the PC altogether and simply sell their own proprietary disks and hardware that do NOT use a PC.”.
This is what Sony/Philips have done with SACD. There’s a Red Book layer (on hybrid discs) that you can rip to your heart’s content. And then there’s the high-resolution layer that dedicated players can decode. They will not license the high-resolution audio for PC reading or playback.
JEF,
The reason we don’t say more about the economics is simply that we face a strict page limit (we’re already slightly over the limit and so will have to cut) and we’re writing for an audience of non-economists. We can’t simply toss out a term like “third degree price discrimination” (or even “price discrimination”) but would have to explain at length what the term means, which we simply don’t have space for. So we have to settle for concise but vague generalities about monetizing uses.
Michael S.,
Thanks for your comment.
What we were trying to say — but in retrospect didn’t say clearly enough in the draft we posted — is consistent with what you’re saying. Lennon’s catalog is still selling, and new discs are being pressed from his masters. A Lennon disc pressed in 2006 would have 2006 CD DRM software on it, and most of the revenue opportunites for that particular copy of the disc would have been extracted by 2009. If somebody buys a Lennon disc in 2008, it will presumably have been pressed in 2008 and therefore its DRM software would time out in 2011.
We’ll revise the wording in the next version to make this point clearer.
Spelling error in this sentence: “The archive file consists of several blocks of gzip-compressed data, each storing a seperate file and preceded with a short header.” Seperate should be separate.
I should also say that I enjoy your blog and find it extremely informative–the above is only in the interests of having your paper be the best it can be.
From the labels’ point of view, CDs with limited lifespans would be the best thing to come down the pike since CDs themselves. They could offer replacement copies (with updated or extended DRM) to any users who complained, and laugh all the way to the bank at the decimation of the resale and lending markets. Writable CDs are reportedly turning out to be rather more fragile than people had anticipated, so it should be easy enough to introduce similar instability in the stamped ones (in conjunction with time-sensitive DRM).
dr2chae you are quite correct that a vinyl record can easily be digitized. The point that I am attempting to make is that I do not want DRM vendors making modifications to my computer system to “protect” their so-called intellectual property. If the DRM vendor is concerned, then they should develop their own line of product, such as the ipod. To use your vinyl record analogy, I would say that the maker of the vinyl record could warp the record in such a manner that it would only play correctly on their turntable. Just don’t modify my turntable, because the “law of unintended consequences” may result in my turntable no longer working correctly for playing standard vinyl records. Of course, all these DRM schemes are subject to failure in the end because they must produce something that we can hear/see – the analog hole – at which point we can digitally capture the information stream.
“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.”
I think this passage is too strong. I would expect that CDs older than three years (or even ten years) frequently make non-negligible amounts of money for their owners. For example, John Lennon’s back catalogue is apparently making $20m or so per year http://www.forbes.com/2003/10/27/cx_dd_1027matchup.html. (Quick Google search.) iTunes sales data (or analogues) would presumably be useful, though I don’t know where you can get this–long tail enthusiasts will probably know more.
Steve R’s proposal in summary if the vendor wants DRM then I advocate the they avoid the PC altogether and simply sell their own proprietary disks and hardware that do NOT use a PC. won’t help at all. Vinyl recordings are as PC-unfriendly as anyone could want, but with modest additional hardware, I have been able to rip my old vinyl into digital form. Once digitized, the music is on the PC, and just as shareable as any other digitized music.
The only use of restrictive DRM I would expect to really gain market acceptance is for “content rental” services where the DRM is required to ensure that content expires in timely fashion. I would tend to think that the most effective means of administering such services would be for the service provider to supply a device that plugs into the computer and includes a custom decoder and digital-to-analog convertor (the device could include a pass-through feature for other audio and/or make itself usable as a ‘general-purpose sound card’).
Such an approach could provide better security for the producer of the DRM content than software-only means, while simultaneously avoiding the need for ‘intrusive’ software on the PC. The vendor of such a device could freely publish all of the protocols necessary to communicate with it allowing its use in open-source contexts; the device itself could contain a secure clock to allow accurate content expiration without requiring live network connections.
The published protocols, of course, would not instruct people how the data for the device was encrypted (at least not in sufficient detail for them to decrypt it). But if a Linux application fed the license and data files supplied by the music vendor into the device, the device would play them; if it needed more info from the vendor (e.g. an indication that the subscription was renewed) it could supply the Linux application with the information it needed to send to the vendor.
BTW, this would have also been a logical approach for implementing HD-DVD, though it’s too late now: rather than requiring a high-powered PC to read the video, decrypt it, uncompress it, and reencrypt it prior to sending it to the monitor, it would have made more sense for the PC to just instruct the monitor that a certain compressed and encrypted data stream should appear at a certain part of the screen. Open-source drivers would then pose no problem, because the PC would never have any access whatsoever to non-encrypted content.
Additionally you note “The software could lock itself down if the vendor’s Internet site is shut down, for example if the vendor goes bankrupt.â€
Indeed, this is the classic problem with centralized DRM schemes. The advantage is that it is easier to strengthen security and still have flexibile permissions. The biggest disadvantage (ignoring the lesser problems of privacy invasion and shifting terms) is that once the central system is no longer around – the media is worthless. Just think how happy all those DIVX customers were when they found that a “life-time” subscription meant for the lifetime of DIVX!
In terms of DRM software being loaded onto computers by CD, I need to resuscitate my rant of 1/26/2006 in the CD DRM: Attack on Disc Recognition post. In summary if the vendor wants DRM then I advocate the they avoid the PC altogether and simply sell their own proprietary disks and hardware that do NOT use a PC.
In terms of the current post, I really see this as TWO issues. One is the datafile and the other is the DRM software. If one uses a standard audio file then the CD should still be compatible 20 years from now, which is the reason for my rant above. The second issue is placing DRM software on the CD. As you point out, software is prone to obsolesce and requires updates. Another reason not to treat the datafile and DRM software as one issue.
Additionally you note “The software could lock itself down if the vendor’s Internet site is shut down, for example if the vendor goes bankrupt.” This theme I believe if virtually unrecognized by the public as a threat and deserves greater emphasis. We always here how the vendor has a right to be paid for his product, but what of the customers investment in that product????? For example, Enron screwed many of its employees out of their retirement savings through a bad business model.
In summary, this section needs a preamble to discuss that CDs that soley contain a datafile are not at issue. What is at issue are CDs that contain both data and software that are designed to work together to “protect” the vendors product, to restrict the ability of the user to do what he or she may want to do with that product, and to provide the vendor with a certain degree of real-time control over a remote computer.
Each one of these excerpts has been simply amazing. Well forumlated, objective, and technical enough to breath some fresh air into the subject. At the risk of being slightly tangential to the subject written about in this excerpt, I hope a section symilar to the following will make it into the final draft:
It seems to me that the usefulness of custom players which CD DRM systems must employ without the cooperation of other program developers (apple itunes, MS media player) is inherently limited. The very reason why digital music is convenient is that it can be stored in a small place (hard drive) and accessed from a single application. I suspect most users who don’t know that they are actually installing an additional program end up never using the program because the benefits of playing that music via thier computer is outweighed by the hassle of having to open and use a different program than they are used to (which manages the rest of thier music).
The best result the record companies can hope for is that the music is not played as often and the consumer is annoyed at the manufacturer for not allowing them to use thier chosen music management software. At worst, poorly written DRM software causes problems with thier system and the user’s hatred of the manufacturer increases, leading to decreased revenue streams.
As you have previously stated, the goal of such CD DRM systems cannot be to block internet sharing of music, but must be to block casual copying. Record companies should realize the intellectual cost of such a decision, since it will always cheapen the value of the product in the consumer’s eye.
I fear that all this is leading to record companies developing thier own DRM standard for downloadable music and then eventually ceasing CD manufacturing. Not only would that force the consumer to use the record companies’ software, but it would prohibit the consumer from being able to purchase full CD quality 16 bit/44.1 kHz music.
What about passive updates? Any sort of request to update, forced or optional, would alert the user to the DRM’s presence. Most people didn’t even know these programs existed until the security investigations on XCP.
A lot of programs update themselves on their own, we just don’t realize it. Antivirus products, windows, and MS Office all do most their work in the background, but they still ask you when you want to install. Normally I would assume it’s not an issue, since what kind of program can install itself with almost no sign of activity whatsoever.
Except that a few days ago GoogleTalk updated it. It didn’t ask, and I wouldn’t have known if it wasn’t for firewall software that needed to give it permission to access the internet. This doesn’t bother me, since I put GoogleTalk there and I want it to update.
But what’s to stop a DRM software from doing the exact same thing, assuming that most users don’t run firewall software?
And the customers who simply wish to play a CD on their PC get 4th degree burned… 🙂
You should look into the value of DRM from the perspective of an economist. DRM segments the market into two groups: Customers who only need to play CD’s on traditional players and customers who need to rip the audio to a digital player. Once the market is segmented, the label can engage in third degree price discrimination.
I think it would be useful if you explored this in greater depth instead of simply saying that DRM allows the label to monetize new uses of the music.
s/verions/versions/
Again, you have not examined “Bill’s Incredibly Stupid CD Protection”, even though it will steal your television and paint obsenities on your front door.