publisher colophon

7
iTunes Hacks: Hacking as a Tactic in the Digital Rights Movement

A history of iTunes, the iTunes Music Store (iTMS), and the DRM system that once operated on music sold through Apple illustrates the development of hacks to iTunes and its access- and copy-protection measures. With this history, we can see a progression of technological resistance that began with DeCSS and AEPBR (consumer products that became politicized) and continued with hacks for iTunes (which were designed with both a political and technologically functional purpose).

The iTMS and the iTunes Client

On April 28, 2003, with much fanfare and publicity, Apple introduced iTunes 4.0 and quickly became the darling of the nascent digital media distribution business. The success of iTunes and the iTMS helped redefine how digital music, movies, and books would increasingly be distributed. The iTMS helped propel Apple’s portable digital music device, the iPod, into the consumer consciousness—so much so that it currently dominates the personal digital music device market. iTunes 4.0 was designed to integrate with the iTMS and give the user access to catalogs for purchasing downloadable music.1 However, despite the overall positive reception of the iTMS service, some users of the iTunes software opposed some of the technologically imposed conditions of the iTunes EULA and, more specifically, the terms of service agreement (TOSA) for iTMS.

The development of multiple technologies bent on undermining the iTunes EULA followed. Many of these technologies were designed with the explicit purpose of giving common users what designers felt were fair-use rights. These iTunes hacks are a marked departure from technologies such as the AEBPR and DeCSS in that whereas the latter technologies were designed with consumer needs in mind and with the still ambiguous understanding of the DMCA, iTunes hacks were designed in a way that was explicitly political: the designers created the hacks both to subvert copyright law and to provide functionality.

The iTunes EULA and Its Technological Enforcement

The iTunes EULA came to the consumer in the form of what has now come to be known as a “click-through agreement.” At the time of installation, the user is shown a body of text in the software’s installation window; she is asked to read it, and if she agrees with its terms, she is asked to click a button on the computer screen that will bring her to the next window, which will then complete the installation process. If the user declines to accept the conditions of the agreement, the program closes and is not installed on the computer. Because the iTunes software is capable of accessing the iTMS, the iTunes EULA makes some explicit demands about how the software ought to be used. The EULA states: “This software may be used to reproduce materials. It is licensed to you only for reproduction of non-copyrighted materials, materials in which you own the copyright, or materials you are authorized or legally permitted to reproduce. This software may also be used for remote access to music files for listening between computers. Remote access of copyrighted music is only provided for lawful personal use or as otherwise legally permitted” (2005).2

Having installed the iTunes software, a user can then access, via a link within iTunes, the iTMS, at which time the user is presented with another document, the iTMS TOSA. The user is once again asked to “click through” if she agrees to its conditions. The salient points of the TOSA include the following stipulations: “You shall be authorized to use the Products only for personal, noncommercial use. You shall be authorized to use the Products on five Apple-authorized devices at any time. You shall be entitled to export, burn or copy products solely for personal, noncommercial use. You shall be authorized to burn a playlist up to seven times” (2005).

Although not explicitly stated in the TOSA, there are two additional limitations on the use of songs bought on the iTMS that are of relevance. First, songs bought on the iTMS can be played only on the iTunes music player. Second, because the songs are encrypted with Apple’s DRM system, they cannot be sampled, edited, or used in other creative fashions.

At the time of the iTunes 4.0 release in 2003, users criticized these limitations and the terms of the iTunes EULA as overly restrictive, unrealistic, and in violation of what they perceived as a fair-use right. The click-through TOSA with the iTMS stipulated that only three computers could be authorized to have copies of songs bought on the iTMS.3

Enforcing the EULA: FairPlay

Apple ensured that the terms of the iTunes EULA and the iTMS TOSA were adhered to by incorporating a method of technological enforcement. The iTunes software tracked the number of authorized copies of a song by collecting system-specific information about the computers in which iTunes songs were purchased and keeping that information stored in the iTMS servers. iTunes also encrypted the authorization code for the purchasing computer on the song itself. When a user tried to access an iTMS song on an unauthorized computer, the software asked the user if she wished to authorize the computer. The iTunes software would then connect to the iTMS servers to check for authorization. If the computer exceeded the number of authorized computers, iTunes would not play the song. In contrast, if the computer was cleared for authorization, the song was encrypted with the new computer’s information, and a copy of that information was updated on the iTMS server (see figure 7.1).

Figure 7.1

Figure 7.1

How Apple checks song authorization.

The iTunes software would also keep track of the number of times a song was burned on a playlist to a CD. Because the encryption of the songs downloaded from iTunes was proprietary, the iTMS song would not play on any other software. It is interesting to note, however, that iTunes made no limitation on the number of copies and did not affect the playability of songs not bought on the iTMS. The system of checking the number and authenticity of the iTMS songs was part of Apple’s DRM system, FairPlay.

Early Circumventions: Dissention among the Faithful

The success iTunes enjoyed early on was a result of iTunes 4.0’s connection with the iTMS and a series of new features introduced with that iteration of the Apple music client. Aside from having access to the catalogs of the iTMS, iTunes 4.0 introduced the file-streaming feature Rendezvous, which allowed one user in a household to stream content to any other Macintosh on the home network. Content could be accessed via the streaming feature so long as the user provided the iTMS user name and the password used to buy the song on the iTMS (Borland 2003a; P. Cohen 2003). For example, if a Mac in one part of the house had music on the hard drive, and a user wanted to listen to it on a Mac in another part of the house, the Rendezvous feature would stream the music between the two machines. However, the music was not “downloaded”; it was simply streamed between machines, much like a Webcast via Internet radio.4 It was this simple streaming feature that users first appropriated for purposes other than what Apple had intended.

About two weeks after the release of iTunes 4.0, users figured out that they could open their home networks to users on the Internet. Various Web-based groups soon started providing search services and applications that allowed iTunes users who provided their ISP address to share their music libraries with other iTunes users via Rendezvous, thereby essentially turning iTunes into an “on-demand” Webcast application. These services and applications included: (1) a music-sharing database that held the ISP addresses of users willing to stream their music libraries via the Internet (Heidi 2003); (2) ServerStore, a downloadable database and application that listed ISP addresses of users sharing music and gave the user the option of publishing her own address (Borland 2003b; “iTunes 4 Tip” 2003); and (3) iTunesTracker, an application that would allow the user to connect to a central server and browse other users’ shared libraries, thus functioning in the same fashion as the early Napster, but having only streaming capabilities (Borland 2003b; “iTunes Tracker” 2003b).5

It had taken Apple considerable work to negotiate licensing of music catalogs from record labels, and the linchpin of the agreement was the assurance by Apple that it could preserve the access rights delineated by copyright owners. Webcast licensing is required by law, even for amateur Webcasters, and capturing the music stream as a download was in 2003 and continues to be a possible means of creating copies of content. The new uses that iTMS customers were exploring thus violated the promise that Apple had made to music companies. The EULA and the TOSA in effect delineated how music companies wanted their music distributed and used. The key here is that those guidelines were not congruent with what users had come to expect in music they perceived as “bought.” The EULA and the TOSA essentially rented the music to consumers, a point that did not come clearly through in the extensive language of those documents. The prospect of Apple’s running afoul of the delicate agreement it had with record labels suddenly became palpable, and Apple moved quickly to address the appropriation of Rendezvous. Unfortunately for Apple, hacks that turned iTunes into a file-sharing program, a type of program that goes beyond mere streaming, had been developed even before the release of iTunes 4.0.

First among these hacks was iCommune, designed by software developer James Speth months prior to the release of iTunes 4.0. iCommune was designed to allow users on a network to stream and/or download music to other Macs on the same network, unlike the Rendezvous hack, which only streamed the content. iCommune integrated with iTunes as a plug-in and used some of iTunes’ proprietary source code. As a result, Speth could not distribute the code widely without legal ramifications. But on April 14, 2003, just two weeks before the release of iTunes 4.0, Speth released his project as an open source on SourceForge.org, having reworked it to contain none of Apple’s proprietary code. With iTunes 4.0’s release in mind, Speth noted in an interview with the online press that his next step would be to integrate iCommune with the Rendezvous feature. Such a feature, in conjunction with the various ISP address databases available at the time, would have turned iTunes into a peer-to-peer file-distribution application, where users could find each other over the Internet and share content with one another (Fried 2003b). The iCommune site stated: “iCommune is a standalone open source application for Mac OS X that extends Apple’s iTunes to share your music over a network. You can share the music in your iTunes library and access other iCommune music collections. iCommune music collections appear as playlists in your iTunes window. You can browse through them, and choose to stream or download the music they contain” (Speth 2005).

Versions of this software are currently still available from SourceForge .org, the open-source clearinghouse site, and its authors claim compatibility with iTunes 3.0 or higher (Borland 2003b; Speth 2005).

Speth, however, was not the only hacker who wanted to expand the Rendezvous feature. A series of other programs quickly followed the launch of iTunes 4.0. On May 11, David White released iLeech; on May 12 Gus Holcomb released iSlurp; and on May 17 Tobias Lernvall released iTunesDL (Heidi 2003; Holcomb 2003; “iTunesDL” 2003a; White 2003). All were applications that would allow a user to exploit the Rendezvous architecture to download music from other users.

Within two weeks of iTunes 4.0’s release, there were at least eight services and applications that exploited the Rendezvous feature and expanded it beyond what had been intended by Apple developers.6 Later applications allowed users with Mac or Linux machines to stream music from one to the other. Hacks that would allow this type of interoperability between operating systems included TunesBrowser and AppleRecords, released by David Hammerton in March 2004 and Chris Davies in May 2004, respectively (they were released nearly a year after the release of iTunes 4.0).

In 2003, however, Apple had to respond quickly to the growing possibility that iTunes would be appropriated for file sharing. Within a month of releasing iTunes 4.0, it released iTunes 4.01, plugging the hole that allowed users to stream and download music over the Internet (Fried 2003a). iCommune then responded to the iTunes 4.01 update with iCommune401(ok) which reestablished Netwide streaming in iTunes. Other less technical users did not develop hacks but instead devised “work-arounds” to iTunes 4.01’s limited-sharing features. One user suggested simply having a dual installation of the iTunes software:7 when a user wanted Internet streaming, she simply had to run iTunes 4.0 instead of 4.01 (Khaney 2003).

Even though some of these early hacks and work-arounds to the iTunes software allowed copying and streaming, the iTunes 4.0 DRM system remained secure. In its press release at the time of the iTunes 4.01 upgrade on May 27, 2003, Apple noted:

The new iTunes 4.01 update limits Rendezvous music sharing to work only between computers on a local network (its intended use) and disables music sharing over the Internet. The iTunes . . . Music Store has been very successful to date, and the mechanisms we put in place to secure that music against theft are working well. . . . Music purchased from the iTunes Music Store can only be played on up to three authorized Macintosh computers, and there has been no breach of this security. (quoted in Fried 2003a)

Circumventing the iTunes DRM system would take another six months, and it would signal an escalation of the nascent war between Apple and some of its users. The iTMS and iTunes expanded to the Windows operating system, and so did the hacks that sought to circumvent limits on use. It is worth noting that Rendezvous remains part of the iTunes software today and seamlessly integrates a user’s music library into the available playlists on other computers running iTunes with the users’ home network. Therefore, downloading is still quite possible within these networks, although broadcasting to the Internet is not. The iTunes sharing option remains a concern for content owners because larger networks in universities make this type of sharing easy. With the release of iTunes for Windows, these concerns became more acute.

iTunes for Windows and QTFairUse: The First Volley

On October 16, 2003, Apple released iTunes for Windows, bringing the PC market within reach of its rapidly growing digital music distribution business. Less than two weeks later, on October 26, twenty-year-old college student Bill Zeller released MyTunes. MyTunes did for the Windows version of iTunes what iSlurp, iLeech, and iCommune did for the Mac version. Working within the limitations of the new version of Rendezvous, Zeller’s software made it possible to download music within the same network and save that captured stream in the popular mp3 music format.

In spite of this circumvention, the DRM system on iTunes songs bought via the iTMS remained intact on Windows machines, and MyTunes could only generate mp3s for unprotected content, such as songs ripped from commercially available music CDs (Borland 2003c; Dalrymple 2003; Menta 2003). In an interview with the online press, Zeller acknowledged the potential legal tangle that such software could create:

I would like to think they would go after those infringing copyrights and not those abiding by them. . . . However, although MyTunes can be used for legal ends, I understand how they (Apple and/or the RIAA) might have a problem with the software. I would like to think the responsibility to act in accordance with the law is on the user. Authors of software should not have to baby-sit the user in order to insure legal compliance. (quoted in Dalrymple 2003)8

Within a matter of months, Zeller’s program had been downloaded more than thirty thousand times from the popular download site Download.com. Zeller himself reported that it had been downloaded one million times from other sites “mirroring” the program. However, by March 2004, MyTunes had vanished from the Internet due to a hardware failure on Zeller’s computer. The failure erased all the source code and prevented further critical updates to the software to counter Apple’s newer versions of iTunes that blocked the functionality of MyTunes (Borland 2004b; Menta 2003). On the Mac, GetTunes, developed by programmer Gregor Triplehorn as an open-source project, was released in May 2004 (Triplehorn 2004a, 2004b). It was billed as “[a] Mac version of MyTunes, a small application that allows users to download music from local Rendezvous-shared music libraries (instead of streaming the songs)” (Triplehorn 2004a).

Five months after MyTunes vanished from the Internet, David Blackman, a Stanford University programmer, released OurTunes, a variant of MyTunes for Windows with the same functionality.9 The OurTunes project, hosted on SourceForge.net, is as of this writing still available for both the Mac and the Windows versions of iTunes. Like MyTunes, OurTunes made it possible to download songs from other members on a local area network sharing songs.

The hacks that plagued Apple iTunes for Mac and Windows shortly after the introduction of the iTMS did two things: it opened up the streaming feature, Rendezvous, to computers outside home networks; and it added a downloading feature to iTunes. These hacks engendered a sort of “code war” between Apple and hackers, with new versions of iTunes being released to counter hacks and new hacks being produced in response. Yet no breach of the Apple DRM system was made in the battle until hacker Jon Johansen did so on November 17, 2003, just a month after the release of iTunes for Windows.

Jon Johansen was not new to controversies surrounding access-control and copy-control technologies. In 1999, working with the hacker group MoRe, he had released DeCSS, a tool that incorporated the decryption algorithm for movies on DVDs, making it possible to play them in players not authorized by the MPAA and the DVD CCA.10 On November 17, 2003, Johansen released the program QuickTime for Windows AAC Memory Dumper, or QTFairUse, as it came to be known. QTFairUse exploited a weakness in the algorithm for encrypting protected Advanced Audio Coding (AAC, a type of high-quality audio file) files bought via the iTMS. Songs bought from the iTMS have the “.mp4” file extension. Mp4 files are files that have been compressed using the AAC algorithm, have the MPEG Layer 4 audio encoding, and are protected by the iTMS DRM system FairPlay. It is possible to have AAC compressed files that are not protected by the iTMS DRM system but that are still encoded using the MPEG Layer 4 encoding, in which case these files would show up as ma4 files when viewed, for example, in the Windows file explorer. QTFairUse captures the protected AAC (mp4) file after it is decrypted but before it is processed to be played as audio, and it “dumps” a raw data file on the hard drive of the computer playing the song. That raw data file is not protected by Apple’s DRM system because it was derived from the AAC file after it had been decrypted (figure 7.2).

Figure 7.2

Figure 7.2

Algorithm for the operation of QTFairUse.

Shortly after the release of QTFairUse, Mac hobbyists on the Net had extensive discussions on the method by which QTFairUse achieved its ends. It is worthwhile to note that capturing encrypted audio has been an ongoing practice carried out before the advent of QTFairUse. The easiest way to capture the encrypted audio was well known among users of the iTunes software and was suggested by a contributor to MacRumor forums. The method requires simply burning a CD of the iTunes-protected media and then ripping (copying) it back onto the hard drive in mp3 format (or whatever other format the user desires so long as the format conversion software is available). Another method to capture the encrypted audio file was to download any number of audio-capture programs that would record the music as it was played by the sound card. Both of these methods unfortunately resulted in a loss of quality because they involved multiple conversions of the digital media format, from protected AAC (iTunes), to Audio Interchange File Format (AIFF) to unprotected AAC or mp3 in the case of copying to CD and back. In the case of capturing the data as the sound card plays it, the digital media file is converted from protected digital format to unprotected analog and then to unprotected digital. As figure 7.2 illustrates, the benefit of QTFairUse was that it captured the AAC data after they had been decrypted by iTunes but before they were processed to be played on the iTunes player. The quality of the sound from these captured data was therefore as good as that of the encrypted file (Chaosmint 2003; Geekpatrol 2003; “QTFairUse?” 2003).

Using QTFairUse was not without its complications; at the time of its release, many of the more popular music-player applications (Windows Media Player and Winamp, for example) did not support the AAC format. Furthermore, the raw AAC format was unreadable in the fashion “dumped” by QTFairUse and needed to be encoded with MPEG Layer 4 encoding, which would then generate an ma4 file. For all practical purposes, it appeared that QTFairUse users were stuck with a decrypted file that no player could play. Some users were able to generate the proper formatting and encode the raw AAC data into a readable m4a format, yet for most users QTFairUse remained technically complex. These users simply chose to use other methods of relieving their songs of Apple’s DRM system.

Despite the fact that only a minority of computer users were skilled enough to decrypt and encode the raw AAC data, the importance of QTFairUse cannot be denied. It was the first program to render protected iTunes files into an unprotected format and, as such, was a crucial “proof of concept” that the iTunes DRM system, FairPlay, could be circumvented while maintaining the sound quality of the music.

All these machinations on the part of users as well as the development of QTFairUse required that the song be played by iTunes. Many of the users commenting on message boards and technology forums expressed the desire to want to play legally bought songs on devices other than iTunes and to want to play them in more than the three computers that the iTunes DRM system initially authorized. Whether those devices were Linux machines or other media players, many users felt that restricting the playability of legally bought music to one piece of software or to some limited number of personal devices was not what they bargained for when they bought a song from iTunes. One user quoted in the online press noted:

Applied to a physical media . . . the idea of the DRM is this: You can play the CD on three designated CD players that support the DRM. . . . [I]t will play ONLY on xyz brand cd player and only three of those that you pick. Yes, you have to stick to that brand of cd player (the iTunes player, the supported OS of iTunes, no unix support in sight) and too bad if you have a fourth one in the bedroom. It’s not gonna play in your second car’s player either. Nor in the kitchen. Nor on your neighbor’s player. Nor can you trade it on the used market when you’re tired of listening to it. (Orlowski 2003, emphasis in original)

This user’s statement is exemplary of the various frustrations that some consumers faced. It also illustrates the blurred boundaries between what users recognize as fair use and what the law delineates as a legal use of media. It illustrates the difficulties in implementing the “access right”11 in digital intellectual-property distribution, and it goes to the heart of the digital copyright debate by pointing to the deviation between what some users see as a normal and legitimate practice and the practices that the law deems acceptable. The reason why users chose to use QTFairUse and other circumvention technology was that it allowed them interoperability and expanded their rights of access.

The VideoLan Client and drms.c: Escalation, Part 1

In January 2004, Johansen and fellow developer Sam Hocevar struck again: they reverse engineered the FairPlay DRM system for Windows. Their hack was modestly titled “drms.c” and was made available as iTunes playback support in the unofficial development library of the open-source media player VideoLan Client (VLC).12 The software had two important uses: first, it allowed users to play iTMS songs on a player other than iTunes; and second, it allowed users to play songs bought from the iTMS on any number of machines, regardless of what the iTMS TOSA said. Thus, after just eight months of operation, FairPlay encryption was obsolete for those in the technological know.

On March 2, the VLC team released VLC version 0.7.1, which integrated Johansen and Hocevar’s work into the project’s official release. As reported by Andrew Orlowski for The Register, Johansen deduced that the key for encrypted songs was “derived from four factors: the serial number of the ‘C’ drive on the host computer [the computer containing the iTMS song], the host system BIOS,13 the CPU [central processing unit] name for the host computer and its Windows Product ID” (2004). A user who wanted to play a FairPlay-protected song on an unauthorized machine first had to play it using VLC on a machine that was authorized. After the song was played, VLC would write the song key to a file on the hard drive (see figure 7.3). The user could subsequently listen to the song on unauthorized machines running VLC by simply copying the song and the key to the new machine (figure 7.4).14 The technologically enforced limit on the number of computers that could play the song was thus defeated.

Figure 7.3

Figure 7.3

How drms.c plays and produces a song key.

Figure 7.4

Figure 7.4

How drms.c incorporates into VLC functionality, allowing multiple machines to play a song.

Importantly, drms.c remained tied to the VLC, and songs had to be played by VLC before keys could be generated. However, just a few weeks after drms.c’s release, another programmer uncoupled it from the VLC and thus expanded the cross-platform playability of songs bought on the iTMS.

PlayFair: Escalation, Part 2

PlayFair (not to be confused with FairPlay, the DRM for iTunes), developed by an anonymous programmer as an open-source project and released April 6, 2004, used Johansen and Hocevar’s reverse engineering work but was a stand-alone application, as opposed to being incorporated into VLC. According to the developer, the application functioned on most UNIX-type systems (presumably Linux), Mac, and Windows systems. PlayFair was initially a command-line interface application for both Mac OS X and Window machines (see figure 7.5). Later iterations of PlayFair included a graphical user interface (GUI) for the Mac OS X and Windows (Hymn Project 2004b).

Figure 7.5

Figure 7.5

Early interface for the PlayFair program.

Importantly, PlayFair not only decoupled song playback from the VCL but also produced an unprotected, playable AAC output file of equal quality to the protected AAC file.15 PlayFair improved on Johansen and Hocevar’s VLC hack because it allowed a user to play a decrypted song on any number of machines without having to copy the song keys along with the song (figure 7.6).

Figure 7.6

Figure 7.6

PlayFair produces unprotected songs and allows them to be played on any computer with any player.

The FairPlay system on the Mac OS X was not as easily defeated, but PlayFair did give Mac users some options. At that time, users who wanted to strip the DRM system from songs on a Mac needed to have an iPod mounted on the Mac with all the songs they wanted to decrypt stored on the iPod from an authorized computer. Because the iPod needed the song keys to play the stored music, iTunes loaded those keys onto a hidden folder on the iPod known as the “key store.” PlayFair searched the iPod connected to the Mac, accessed the “key store” folder, and used those keys in conjunction with Johansen and Hocevar’s software to strip the songs on the Mac (figure 7.7).

Figure 7.7

Figure 7.7

PlayFair uses iPod to generate song keys for Mac users.

The GUI made conversion of a protected song somewhat easier than for the early Windows DOS interface. A user could simply drag and drop the protected song into the PlayFair interface, and the program would generate a new file that was free of the DRM system (figure 7.8) (Hymn Project 2004b).16 The user, after having generated the unprotected AAC file encoded in MPEG Layer 4, could then play it on players that supported the format. Windows users, although not having access to an early GUI, had the advantage of not needing to plug in an iPod.

Figure 7.8

Figure 7.8

PlayFair GUI after its name had changed to “Hymn.” Image taken from http://www.hymn-project.org.

During the two years following the release of iTunes 4.0, the process of stripping songs of their iTunes DRM system became increasingly simple. For example, at the time of the QTFairUse release, users were having some difficulty playing the raw AAC file. By the time PlayFair was released, the media players Winamp, Free App a Day (FAAD), and VLC were capable of easily playing these songs. Thus, it was finally possible to convert a protected AAC file to an easily playable unprotected AAC file, doing away with the potential loss in quality due to conversions between file formats. It took Apple less than forty-eight hours to take legal action against PlayFair.

A Software Bloom: Code War Momentum

PlayFair was released on the open-source Web site SourceForge.org on April 6, 2004. On April 8, Robin Miller, the copyright agent for SourceForge.net, received a cease-and-desist email and fax from David Hayes, a lawyer with the San Francisco firm Fenwic and West, the firm representing Apple Corporation. In that letter, Mr. Hayes, citing the DMCA’s anticircumvention provisions, demanded that the SourceForge.org site take down the PlayFair project from its servers and cease distributing the PlayFair client. On April 9, SourceForge.org pulled the project from its servers. Not to be outdone, the developer of PlayFair then reposted the project on Sarovar.org, an open-source development site similar to SourceForge located in India. By April 15, however, the Sarovar.org administrators had also received a cease-and-desist letter from Apple through its legal representation in India. In that letter, Apple noted that Sarovar was in violation of India’s Information Technology Act of 2000 and Copyright Act of 1957. In response to this letter, Sarovar withdrew the PlayFair project from its servers (Sarovar 2004).

PlayFair spawned a long passionate discussion among iTunes loyalists and PlayFair supporters. The commentary is illuminating and addresses the frustrations users felt with the iTunes DRM system. It also illustrates that by no means are users monolithic in their feelings toward DRM. Some users felt that the FairPlay DRM system was as good a deal as could be had in the digital environment. Yet others felt that they were entitled to more. Two opposing views indicate the conflicts:

I have the answer to all your problems: Stop purchasing music with DRM! You knew, before you purchased anything from the iTMS, that you would not be able to convert it to another format; you would only be allowed to play it on three computers at a time, plus iPods; and that you would not be allowed to remove the copy protection from the files you purchase. Quit whining about “legitimate” uses when you agreed to give up those options when you purchased from the iTMS. You agreed to a contract and are attempting to, or already have, violated that contract. That is illegitimate. (aogail 2004, emphasis in original)

Moron . . . calling me a thief. . . . I wanted to make a music video in mpg format out of an itunes file and some anime. I was unable to because of “fairplay.” Not so fair eh? Your shortsightedness is amusing, and you make it seem as if there is parity between intellectual and actual property. (“Re: Overseas” 2004)

These comments give us extraordinary insights into the complexities of the issues surrounding digital copyright at the level of users. The second user’s understanding (or lack thereof) of fair use, “aogail’s” understanding (or lack thereof) of market power in contract, and the power of technological resistance to make a reality out of a belief play themselves out in this exchange. Imagine what it would mean to understand fair use in this way without PlayFair. PlayFair makes the expanded conception of fair use real. The software expands the alternative conception through its distribution on the Internet by gaining users and by creating, through practice, a new fair use, regardless of the law. As I noted in the introduction to this book, the realization of a world where user conceptions are made reality is a central distinguishing factor of digital rights activism. PlayFair is an example of this factor. It is the ideal made real.

These computer programs are not trivial, and lest we doubt the undertones of civil disobedience in these technological practices, some users surely recognize them:

People can argue ethics all they want. But the simple fact is that the music industry should make the experience the best they can for their legitimate customers, of which I am one. I have had numerous problems trying to play my songs on different computers I’m using. I’m a technically savvy guy, and I know all I need to do is contact tech support. But you know what? Just because I own four computers, I don’t feel like asking permission each time I want to play a song that I paid them for. Face it: DRM sucks. I don’t want to steal. DRM still sucks. So I’ll be using PlayFair to unlock my legally purchased songs, and then I’ll enjoy them however I want. Yeah, it’s illegal. But it’s “right” in my book, and I’m not ashamed to flaunt [sic] these crappy laws. (Localman 2004)

In spite of Apple’s persistence, PlayFair was back online by May 10, 2004, registered to an Indian citizen and hosted on Hymn-project.org with legal support from the Free Software Foundation India. According to its developer, the software was downloaded three hundred thousand times as of May 14, 2004. It also had acquired a new name, “Hymn,” an acronym for “Hear Your Music Anywhere” (Hymn Project 2004e).

DeDRMS

On April 25, at the same time that PlayFair was confronting its problems with Apple, Jon Johansen released DeDRMS, an application quite similar to PlayFair. The DeDRMS utility worked on Windows machines in conjunction with VLC by using the song keys generated by drms.c to create new copies of a song without any DRM protection. Recall that VLC could only generate keys for protected songs that needed to be copied if a user wanted to move music to more than the three authorized computers. With DeDRMS, the user could use VLC to get the song keys from the computer system; DeDRMS would convert the songs into unprotected AAC files. The difference between drms.c and DeDRMS was that the latter generated unencrypted files that would not need copies of song keys to be played on other computers.

Because songs purchased on iTunes have included in their code information about the user who bought the songs, both Johansen and the PlayFair/Hymn developer (from this point, I refer to PlayFair as Hymn) designed their applications to incorporate a technological system of self-policing into the software. If a user chose to decrypt his or her iTunes songs and then share them on peer-to-peer networks, for example, the songs would be traceable back to the person who originally bought the song. Johansen makes his intent clear in the “readme” document that comes with the DeDRMS source code. He writes: “DeDRMS requires that you already have the user key file(s) for your files. The user key file(s) can be generated by playing your files with the VideoLAN Client. . . . DeDRMS does not remove the UserID, name and email address. The purpose of DeDRMS is to enable Fair Use, not facilitate copyright infringement” (Johansen 2004).

The Hymn developer also makes his17 intentions clear in the “frequently asked questions” (FAQ) section of the Hymn user manual:

Q: Why are you trying to promote music “piracy”? Shouldn’t musicians make money, too?

A: First of all, I buy all of my music. In fact, most of the music I buy these days comes from the iTunes Music Store. However, I want to be able to play the music I buy wherever I want to play it without quality loss, since I PAID FOR that quality. I want musicians to make money. I want Apple to make money. I don’t condone sharing music through P2P [peer-to-peer] networks with the masses, though I believe making a mix CD or playlist for a friend is okay. I also think the RIAA are a bunch of crooks, but that’s another story.

Secondly, hymn leaves the apple ID embedded in the output file, so anyone who shares the decoded files on P2P networks is bound to be prosecuted under copyright law. (Hymn Project 2004c, emphasis in original)

Once again these comments bear out some underlying themes in the copyright debate. They illustrate practices that are at odds with the law and the norms of technology and media use that conflict with fair use as it is legally defined. The spirit of this debate is encapsulated in the user’s statement quoted previously: “Yeah, it’s illegal. But it’s ‘right’ in my book” (Localman 2004). Importantly, such comments also add a layer of complexity to any understanding of how hackers who facilitate a user-centered interpretation of fair use see that doctrine. For them, licensing that precludes users from having reasonable access to their cultural goods is limiting, but they themselves also define some limits. The digital rights movement’s interpretation of access and use rights does not advocate a free-for-all, and the more moderate activists and leaders would like to see a compromise.

FairKeys

One of the ways Apple ensured that a user could play a song on only three authorized computers was to keep a copy of the song keys on its servers. The song keys were system specific, so if songs were installed on a computer that was not authorized (and so no song keys were found locally), the iTunes software would pull the keys from the iTMS server and attempt to open the songs with the keys. If the system information (as described in the section on drms.c) on the keys did not match the computer on which the songs are stored, iTunes would ask if the user wished to authorize the computer to play the songs. This question assumed the user had not yet authorized the three computers stipulated by the EULA. If the user had already authorized three computers, however, iTunes would not play the songs. Under normal circumstances, a user with three authorized computers who acquired a fourth computer that he or she wanted to play music on would be required to deauthorize one of the three originally authorized computers. iTunes would then communicate the deauthorization to the iTMS server, which would then update the server keys, noting that only two computers were authorized and that the user could now authorize a third computer.

Following upon the release of DeDRMS, Johansen released FairKeys, an application that would retrieve a user’s song keys from the Apple iTMS servers. With this new tool, a user could access the Apple servers using her log-in information. The Apple server, believing that the user was accessing the songs with iTunes, would send the song keys to FairKeys. As explained earlier, iTunes would not have played the songs because the keys would note that three computers were already authorized. DeDRMS, however, could use those keys to strip the DRM from the protected song (see figure 7.9). The FairKeys/DeDRMS combination made it unnecessary to use VLC (something already done by Hymn) or to have the song keys on the system attempting to strip the DRM; those keys were now accessible via FairKeys’ access to the iTMS servers.

Figure 7.9

Figure 7.9

How FairKeys and DeDRMS produce unprotected songs.

FairKeys used the user’s log-in information to get song keys from the iTMS, so the self-policing aspect of the software was preserved because, in theory, only a person who legally bought the songs would have the log-in information matching the copies of the songs in question.

iOpener and JHymn

The Hymn Project developer quickly noted FairKeys on the Hymn Project Web site. With this added feature, Mac users using Hymn did not need to have an iPod mounted on their desktops to be able to strip the DRM from songs bought on the iTMS.18 Furthermore, from May 2004 until early 2005 the Hymn Project expanded, making it increasingly easy to strip DRM from iTunes songs. In August 2004, a Hymn Project community member released iOpener for Windows, a variant of Hymn, which ran on Microsoft’s “.net” framework. iOpener monitored the iTunes music library on the installed computer and would convert DRM-protected iTunes files into unprotected AAC files, allowing for almost seamless integration (Hymn Project 2004d). On the iOpener FAQ, the developer stated:

iOpener is an application that will find all of the “protected” AAC files in your iTunes library (the ones you purchased online) and remove the DRM (encryption) from them “in place,” allowing you to enjoy the music you’ve purchased on any device anywhere that supports the standard AAC format. This means that you will notice no change whatsoever in iTunes except that the “type” of the track will change from “Protected AAC audio file” to “AAC audio file.” Additionally, iOpener can run in the background (in your task tray, actually) and auto-decrypt any “protected” AAC files as they are added to your iTunes library. (Hymn Project 2004d)

Regarding the legal implications of this software, the developer noted that iOpener is

an insurance policy, primarily. In a capitalist economy like the one Apple (and you and I) operate in, it’s not unlikely that Apple, Inc. will be bought/sold/merged/dissolved sometime between now and the day I’m pushing up daisies. I like the convenience of being able to purchase music online, but don’t like the idea of sitting in the retirement home with a hard drive full of music from my younger days that I can’t “authorize” because CocaNikeEnron, Inc. decided to shut down its “Apple division” to boost this quarter’s figures. . . . Don’t share music or other files on P2P [peer-to-peer] networks or elsewhere online unless you wrote/created them. It’s unethical. . . . Making mix tapes for your friends (i.e. people whose faces or at least real names you know) is cool. Anonymously sharing your entire collection with the world is not. That being said, iOpener preserves all metadata . . . in the track. This includes your Apple ID and email address. Share if you want, but caveat emptor. (Hymn Project 2004d)

Also during this time, a Hymn community member who went by the online name “FutureProof” developed JHymn, another variant of Hymn but written in Java. This variant, originally written for the Mac, grew into the most user-friendly iTunes DRM system–stripping technology since the iTunes battle in the copyright code war began. JHymn had the ability to easily find protected files and convert them into unprotected AAC files. It gave the user the option of converting those AAC files to mp3 files “on the fly,” and it would strip the identifying information from the generated files.

Apple responded to all these hacks by updating iTunes with features that would undermine circumvention measures. For example, iTunes 4.6 included a function that would search out unprotected AAC songs bought on the iTMS (with the identifying metadata still attached) and refuse to play them, going as far as deleting copies of these songs found on users’ iPods (FutureProof 2004).

According to the developer’s comments on the JHymn Web site, the user data on the unprotected songs was a “dead giveaway that those files once lived a life as DRM-protected files” (FutureProof 2004). Faced with the difficulty of having unprotected AAC files remain unplayable to the iTunes software (although they can be played by other applications, such as Winamp), the developer included a “scrubbing” option in subsequent versions of JHymn. The developers noted his discomfort in including the option to turn off the self-policing feature that had been a part of all the variants originating from PlayFair. He noted,

For various philosophical and quasi-legal reasons, JHymn, right “out of the box” so to speak, does not strip your Apple ID or the copyright information contained within the files from which DRM is removed. . . . We know after what happened when iTunes 4.6 came out that such vulnerabilities can, and probably will, be exploited. . . . You have to make the decision yourself, as the user of JHymn, to remove either or both of these items by going into JHymn’s Preference settings. (FutureProof 2004)

At play in this cautionary statement were the developer’s commitment to what he believed to be fair use, his understanding of his liability should he have stripped the user information as a default, and his desire to continue to provide a tool that would effectively free iTunes songs from DRM.

It would be naive to think that the technological self-policing in some of these applications was conceived solely out of concern for preventing illegal music sharing on peer-to-peer networks. It is quite probable that self-policing features were included to diminish the appearance that such technologies were being developed with the explicit purpose of facilitating copyright infringement by allowing once-protected songs to be sharable. Regardless, the self-policing features had an expressive function beyond that of their operative function. Technological self-policing features state, “Although we believe in expanded fair use, we do not condone rampant copying.” Self-policing drew technologically defined boundaries around an ideology of fair use. It was, in a sense, a compromise on the part of the developers of these technologies. It expressed recognition of the damage that the technology might do to copyright owners and attempted to address it. Apple was unfortunately unwilling to entertain this discussion because it did not own the copyrights to the songs the owners sell.

Although statements about the recommended use of these features were articulated to limit the distributor’s liability, I do not believe that the self-policing features were present entirely for this reason. The very design and distribution of these programs was in violation of the various anticircumvention provision of DMCA section 1201. Therefore, the developers of these technologies were already in violation of the law by the very fact that they made and shared these programs.19 Statements that attempt to mitigate the impact of these technologies for copyright were issued after the fact, and it would be folly for a developer to rely on a judge or jury to take them as genuine. As such, statements about intended use must have some value other than buffering liability—that value being an honest expression of a belief both in copyright and in its limitations.

Conclusion

All told, between April 2003 and the summer of 2005, iTunes faced twenty-four services and technologies designed with the explicit purpose of circumventing the restrictions on copying and accessing songs bought on the iTMS (table 7.1).

Table 7.1

List of iTunes Hacks from March 2003 to Summer 2005


iTunes Hacks

Release Dates

iCommune (for Mac)

March 2003

ServerStore

April 30, 2003

iSlurp

May 12, 2003

iLeech

March 2003

iTunesDL

May 17, 2003

iTunesTracker

June 2003

MyTunes (for Windows)

October 26, 2003

QTFairUse

November 17, 2003

drms.c

January 5, 2004

VLC 0.7.1 Functionality

March 2, 2004

PlayFair (for Windows and Mac)

April 6, 2004

Hymn

April 25, 2004

AppleRecords

May 19, 2004

JHymn

Summer 2004

DeDRMS

April 25, 2004

FairKeys

July 7, 2004

iOpener

August 22, 2004

FairTunes (for Mac)

April 25, 2004

OurTunes

August 9, 2004

GetTunes (Mac version of MyTunes)

Summer 2004

SharpMusique

March 31, 2005

PyMusique

March 18, 2005

JusteTune

April 15, 2005

Musik

Summer 2005


Some of these technologies were designed with interoperability in mind (the ability to play songs on more than just iTunes); many were open-source projects. The most successful were designed with the explicit political purpose of giving users of iTunes what designers felt were fair-use rights. Hymn stands out among these. The developer had very explicit viewpoints on the matter of Hymn’s being a political technology that allowed users their rights:

The purpose of the Hymn Project is to allow you to exercise your fair-use rights under copyright law. The various software provided on this web site allows you to free your iTunes Music Store purchases (protected AAC/.m4p) from their DRM restrictions with no loss of sound quality. These songs can then be played outside of the iTunes environment, even on operating systems not supported by iTunes and on hardware not supported by Apple. . . . “The primary objective of copyright is not to reward the labor of authors, but [t]o promote the Progress of Science and useful Arts.” “To this end, copyright assures authors the right to their original expression, but encourages others to build freely upon the ideas and information conveyed by a work. This result is neither unfair nor unfortunate. It is the means by which copyright advances the progress of science and art.”—US Supreme Court Justice Sandra Day O’Connor. Despite what Justice O’Connor of the United States Supreme Court has said, DRM exists. The purpose of DRM is to bypass traditional copyright law. The result of DRM combined with laws that outlaw circumvention of DRM (such as the DMCA) is that there is no longer clear protection for fair use in some countries. (Hymn Project 2004a)

Also of note is the fact that these circumvention technologies became increasingly easier to use. The evolution in usability from the initial command-line interface to drag-and-drop functionality contributed to wide adoption of these technologies (see figure 7.10).

Figure 7.10

Figure 7.10

Drag-and-drop function of Jon Johansen’s JusteTune iTunes hack.

These iTunes DRM-circumvention technologies distinguish themselves from the AEBPR and DeCSS in that they were explicitly designed to challenge technological enforcement that designers felt embodied the DMCA’s overly broad limitations. Unlike the latter two technologies, iTunes hacks did not gain a political meaning based on struggles in court but were instead born with that meaning; their adoption, although convenient for many, was a matter of politics for others (especially the designers).

Apple eventually abandoned the DRM system for music sold on the iTMS, but the way technologies like them and the hacks to them were understood by corporations and the movement reflect an important cultural framing of technology as part of the ongoing debate over user rights. Technology itself is both a boon and a hindrance to participation, and both sides of the debate claim technology for their own purposes.

On the side of those companies selling digital music (such as Apple), digital technologies were presented as untethering the user from the confines of old media and allowing him or her to roam creatively through music collections. For example, the now famous ad campaigns for iPods showing silhouetted figures dancing ecstatically intimated a liberated user, faceless so that he or she could be any of us, but joyous, unattached to any physical world save the iPod colored in its signature white. This image, coupled with Apple’s early ad campaign with the tagline “It’s your music . . . rip, mix, burn,” sent a clear message: digital music and digital technology would free you to consume music in a personal way.

The politics of these technologies, then, are related not only to legal debates (the legal politics of copyright), but also to the cultural politics of music consumption, cultural appropriation, and ownership. The ad campaign added a certain type of rhetoric about digital technologies; it presented an argument for freedom. Of course, the great irony was that this freedom was not exactly what users encountered. The Apple DRM system tied users to iPods, the iTMS, and iTunes. Far from liberating a user from old media and technologies, they tied them to new ones.

It is not surprising that the digital rights movement itself generated its own rhetorical moves—through, for example, naming one of the hacks to the iTunes DRM system “PlayFair.” These semantic hacks were and continue to be important to the movement. They give cultural meaning to politics that reside deeply in the workings of technological systems. Because they do so, users can connect to a particular technological system not only functionally but also meaningfully. This practice common to highly politicized digital technologies can be seen in, for example, studies of user attitudes toward adoption of open-source software (such as the Mozilla Firefox browser): although users adopt the technology for functional purposes, they also do so because of its meaningful politics.

The irony represented by Apple’s “rip, mix, burn” mantra and its implementation of DRM ultimately suggests that corporations selling digital music often find themselves in a middle ground between copyright owners’ desire to strictly control consumption and users’ strong participatory impetus. On which side companies such as Apple fall is a matter of convenience. Apple supported DRM because it needed to appease copyright owners, but it jettisoned DRM when the system became intractable, its competition started offering DRM-free music (services such as Amazon .com never used DRM), and users rejected DRM.

Chapter 8 further discusses the implications of the role of technology as a means of making a political statement and as a means of affecting change with both its functional aspects and its meaning. Hackers such as FutureProof and Johansen were not the only ones producing such explicitly political technological resistance. Other technologies were also produced, targeting both the iTunes DRM system and digital copyright in general. These technologies were developed as an explicit tactic employed by active individuals and movement organizations.

Additional Information

ISBN
9780262305334
Related ISBN
9780262017954
MARC Record
OCLC
1053419019
Launched on MUSE
2018-09-19
Language
English
Open Access
Yes
Back To Top

This website uses cookies to ensure you get the best experience on our website. Without cookies your experience may not be seamless.