Late last month, Windows expert Mark Russinovich revealed Sony installing a rootkit to hide its “XCP” DRM (digital rights management) software as installed on users’ PCs. The DRM software isn’t something a typical user would want; the “rights” it manages are Sony’s rights, i.e. by preventing users from making copies of Sony music, and this protection for Sony comes at the cost of 1%-2% of CPU time (whether or not users are playing a Sony CD). Notably, Sony didn’t disclose its practices in its installer or even in its license agreement. At least as bad, Sony initially provided no uninstall for the rootkit, and when Sony added an uninstaller, the process was needlessly complicated, prone to crashing, and a security risk. See timeline & index, parts 1 and 2.
Having bungled this situation, Sony has recalled affected CDs and announced an exchange program to swap customers’ affected CDs for XCP-free replacements. For savvy consumers who have followed this story, the exchange looks straightforward. But what about ordinary users, who don’t read the technology press and aren’t likely to learn their rights?
As it turns out, there’s a clear solution: A self-updating messaging system already built into Sony’s XCP player. Every time a user plays a XCP-affected CD, the XCP player checks in with Sony’s server. As Russinovich explained, usually Sony’s server sends back a null response. But with small adjustments on Sony’s end — just changing the output of a single script on a Sony web server — the XCP player can automatically inform users of the software improperly installed on their hard drives, and of their resulting rights and choices.
Sony’s Messaging System; A Demonstration Message
The Sony messaging system works as follows: Whenever a user plays an affected XCP CD, and whenever a user browses within certain sections of the player, the player sends a message to Sony’s connected.sonymusic.com server. A typical outbound message is shown below. A “uId” parameter (yellow) marks the CD being played and the specific section of the player in use.
GET /toc/Connect?type=redirect&uId=1171 HTTP/1.1
Accept: application/*, audio/*, image/*, message/*, model/*, multipart/*, text/*, video/*
User Agent: SecureNet Xtra
Host: connected.sonymusic.com
Connection: Keep Alive
Cache Control: no cache
Sony’s web server typically replies with a reference to a “nobanner.xml” file (green).
HTTP/1.1 302 Moved Temporarily
Set Cookie: ARPT=JKXVXZS64.14.39.161CKMJU; path=/
Date: Sat, 12 Nov 2005 18:36:49 GMT
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.14 OpenSSL/0.9.7d
Location: http://www.sonymusic.com/access/banners/nobanner.xml
Keep Alive: timeout=10
Connection: Keep Alive
Transfer Encoding: chunked
Content Type: text/plain
<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor=”#FFFFFF”>
<p>This document you requested has moved temporarily.</p>
<p>It’s now at <a href=”http://www.sonymusic.com/access/banners/nobanner.xml“>http://www.sonymusic.com/access/banners/nobanner.xml</a>.</p>
</body></html>
In place of this “nobanner” response, what if Sony’s connected server instead replied by sending a reference to a XML file that included relevant, timely disclosures? Using the HOSTS file on a test PC, I caused my test PC to think the connected.sonymusic.com server was at an IP address I controlled (rather than on a real Sony server). I then wrote a replacement /toc/Connect?… script that sent back a reference to an XML file I wrote, rather than the ordinary reference to Sony’s nobanner.xml file. Finally, I posted an XML banner configuration file. Notice my inclusion of a banner image (blue) and a hyperlink (red).
<?xml version=”1.0″ encoding=”UTF-8″ ?>
<rotatingbanner>
<banner src=”http://www.benedelman.org/sony/image1.jpg” href=”http://cp.sonybmg.com/xcp/” time=”4000″ />
</rotatingbanner>
In my test environment, Sony’s XCP player automatically retrieved my XML file, then retrieved the banner and showed it within the large banner box at the bottom of the player. Clicking the banner opened a browser window to the URL specified in the HREF parameter.
A notification banner shown in my Sony XCP Player, demonstrating the feasibility of using the banner system to notify users of the software installed on their computers.
For a very few artists, Sony already uses the notification system to provide updates to the XCP player’s information screens. Fortunately, the banner system explicitly anticipates placing multiple pieces of information in a single banner space. Notice the “rotatingbanner” and “time” constructs in the XML banner file above. If the <banner> tag is repeated, the XCP player automatically rotates between the specified images.
Sony’s recall of affected CDs is a sensible start in undoing the harm and ill will XCP has caused. But for the recall to make a meaningful difference — in actually helping ordinary users, not just in improving Sony’s PR standing — Sony needs to spread the word widely.
Unlike Amazon (which already emailed users who bought an affected CD), Sony does not know the names or addresses of affected customers. But Sony’s existing banner messaging system gives Sony an easy, cost-effective way to reach them. Sony should implement the method described above. Via these banners, Sony can assure that as many affected consumers as possible have timely, authoritative information about what has been done to their computers and about how Sony offers to make them whole.
What I propose is not an auto-updater as that term is generally used. A “real” auto-updater downloads and installs executable program code onto a user’s computer. In contrast, my demonstration downloads only data — a single XML configuration file and a single graphic image. The difference has substantial implications for computer security and user control: Downloading and running executable code risks a substantial intrusion onto users’ PCs, for lack of any technology-enforced limit to what the auto-updater can do. In contrast, merely updating graphics entails no clear harms to computer security or reliability.
Sony’s initial inclusion of self-updating message screens entails clear privacy consequences — transmissions to Sony servers that report users’ IP addresses, playing habits, and CDs on hand. But these transmissions occur whether Sony sends a null “nobanner” answer or sends a useful banner with information users urgently need. Under the circumstances, Sony might as well put the notification system to use.
Sony Takes My Suggestion (This section added on December 17, 2005.)
Sony has accepted my suggestion of using XCP’s existing banner system to notify users about the XCP software. Today, upon inserting an affected Sony XCP CD, I received the banner shown below. Clicking the banner led me to http://cp.sonybmg.com/worldwide and onwards to instructions to update XCP (including removing the XCP rootkit) or to remove XCP altogether.
An actual banner shown in my Sony XCP Player on December 17, 2005.