Here's part of the actual order. On April 26, Judge Charles Eick of the U.S. District Court, Central District of California, gave SonicBLUE 60 days to:
(1) take the steps necessary to use their broadband connections with ReplayTV 4000 customers to gather all available information about how users of the ReplayTV employ the devices, including all available information about what works are copied, stored, viewed with commercials omitted, or distributed to third parties with the ReplayTV 4000, when each of those events took place, and the like; (2) implement Defendants' offer to collect available data from a second source -- the MyReplayTV.com web site -- about how users of the ReplayTV employ the devices, but for all time periods for which that data can be collected, rather than just for a short period; (3) provide the foregoing data to Plaintiffs in a readily-understandable electronic format and provide any technical assistance that may be necessary for Plaintiffs to review the data; (4) provide Plaintiffs with all documents about Defendants' consideration of what data to gather or not to gather about their customers' uses of the ReplayTV 4000; and (5) provide Plaintiffs with any other documents (such as emails or logs) reflecting what works have been copied with the ReplayTV 4000 and how those works have been stored, viewed, or distributed.
Now who gets all of this data? The plaintiffs in the case against SonicBLUE (the makers of the ReplayTV 4000). Roughly, Time Warner, HBO, Warner Brothers, TBS, New Line Cinema, Castle Rock Entertainment, WB TV, MGM Studios, Orion Pictures, 20th Century Fox, Universal City Studios, Fox Broadcasting, Paramount Pictures, Disney, NBC, Showtime, United Paramount Network, ABC, Viacom, CBS, Columbia Pictures, Columbia TV, and Tristar. The plaintiffs are also ordered to pay 3/4 of the cost of gathering the data.
Come on. Our courts have no business ordering a company to spy on its own customers just because big media wants to put the company out of business. We at the Privacy Foundation saw a lot of consumer outrage after we released our report about TiVo's privacy disclosure and practices. TiVo did a pretty good job of responding to the situation; they spent a lot of time with the press, and they wrote a white paper explaining what had happened. (We still have some gripes about their system, but that's another story.) The point is that companies are very sensitive about tweaking their customers' privacy, because they know customers don't have much patience for it. So when the court orders a company to spy on their customers, it's basically a punitive act. The customers will revolt and get mad at everyone. I'm no lawyer, but I'm pretty sure the discovery of evidence phase of a lawsuit isn't supposed to be punitive.
In this case it's worse than just a privacy squabble. Either the court doesn't understand or the court doesn't believe ReplayTV's repeated explanation that they simply don't have the information demanded by this order. See, in April 2001 some months after our TiVo report came out, I showed a ReplayTV exec my traces that proved that their current model also collected some type of viewing information. This scared them, and in May 2001 - before the ReplayTV 4000 existed - they disabled the collection function, since they had never used the data for anything. This is what they told me, and this is what they've sworn to the court in testimony.
Now the ReplayTV 4000 is a different product than the one I investigated, and ReplayTV has said that they never reenabled the old tracking code, nor did they update it to make it monitor the newer features - like automatically skipping commercials and sending recordings to other ReplayTV 4000 units. But that's precisely the type of data that the plaintiffs are demanding to see in this case!
So what we have is a court ordering SonicBLUE to prepare a new software release that implements new spying features, and then ordering them to force it upon all of their customers, out of fairness to Big Media in their case against them. Considering that SonicBLUE has probably updated their customers' software only a few times ever, this is like ordering Microsoft to create, distribute, and maintain a new version of Outlook that checks to see if any of its users are sending MP3s as attachments!
I guess this is a sneak preview of the type of consumer broadband "protection" we can look forward to in the very near future.
What happens next: SonicBLUE is planning to file papers with the overseeing judge in U.S. District court objecting to this order. If that doesn't go their way, then I guess they'll be working on a new software release.
As I understand it, the clients will send their IDs to bnetd, but bnetd has no way to verify whether they are valid or not. So what if bnetd were to just forward each client ID to battle.net and await validation before letting that client join the bnetd network? You'd be stuck with an initial roundtrip to battle.net for each client, but afterwards the play could proceed independently.
Even if this is not technically possible right now, battle.net has an obligation to consider supporting low-impact measures like this that preserve their rights without trampling on other noninfringing uses. The courts are there to decide disputes when the parties can't agree, but this dispute seems pretty easy to deal with.
So, it's an unwelcome development, but if the bnetd developers decide to spend some time now trying to work with battle.net to find a technical fix, it's time well spent. In particular, the courts are not going to be sympathetic to battle.net if a straightforward solution were proposed but then ignored by battle.net.
Re:Comments from a Bugnosis author
on
Web Bug Detector
·
· Score: 1
I agree with most of what you said, but I'm skeptical about the 95% thing, particularly with NATs and proxies and whatnot fooling around with IP addresses. And you can't really count timestamps for much unless the clocks are synchronized. It's much more reliable with cookie sync.
I still say that the Web bug is there for info transfer only. It certainly isn't there for visual purposes, so what other explanation is there? When I was going off about cookie sync I was talking about the capability of the channel, not Slashdot/OSDN's practices in particular, and I didn't intend to imply that the very broad term "info transfer" is a synonym for the very specific term "cookie sync". In the case of Slashdot/OSDN I would guess the bug is an aggregate hit counter of some type. To me, that's a type of info transfer, not image display, and I agree they indeed could achieve the same with out-of-band log swapping.
David
Re:Comments from a Bugnosis author
on
Web Bug Detector
·
· Score: 1
That's not Web bugs leaking the information to a third party, that's the main site deliberately giving that information to a third party. I may have concerns about the main site doing that, but Web bugs don't add anything to that concern IMHO seeing as the conduit exists without Web bugs.
I have to disagree. There is a very important difference between the info transfer with a Web bug (or equivalent) and just sending around log files behind the scenes. Our FAQ covers this.
In the scenario I described, OSDN ends up with both cookies. This allows OSDN to synchronize with Slashdot, allowing both sites to realize they're discussing the same user, no matter when the sites originally assigned the cookies, and without planning to synchronize in advance. If on the other hand Slashdot just sends a log file to OSDN, then the synchronization is much harder to achieve, and in practice, would probably not even be attempted.
Basically, it's the same old third-party cookie synchronization threat. Now, cookie sync can be done with banner ads or other 3rd-party content and is not uniquely associated with Web bugs. But when you encounter a Web bug, it is absolutely clear that (1) it's there for the info transfer alone and (2) it's trying to slip under the radar. That makes it a pretty interesting device, from a policy point of view.
By adding a Web bug to HTML email, you can track the progress of your emails, and under further assumptions, you can even intercept comments added by people who forwarded your email: see our email wiretapping report, originally described by Carl Voth. A yet-to-be-distributed version of Bugnosis examines Outlook and Outlook Express emails for Web bugs too.
Re:Comments from a Bugnosis author
on
Web Bug Detector
·
· Score: 1
Here's what I meant by my claim.
When the browser fetches the Slashdot page, it sends the Slashdot cookie if any. Slashdot can then encode that cookie into the name of the Web bug image, so when the browser fetches the image from OSDN, it effectively tells OSDN the user's Slashdot cookie. No JavaScript required.
I'm not saying that Slashdot and OSDN are actually doing this -- just that the info conduit allows it.
David
Comments from a Bugnosis author
on
Web Bug Detector
·
· Score: 5
Yep, we consider the OSDN image to be a Web bug, because it acts as a surreptitious information conduit between slashdot.org, the reader's computer, and osdn.com. Information sent through this path picks up both slashdot and OSDN cookies, so it bypasses the "same domain" rule preventing one domain from manipulating cookies set at another. Of course there's no way for Bugnosis to understand the business relationship and contracts that may restrict the use of the conduit (P3P will help with this). What's absolutely clear is that a facility designed for displaying images is being run in reverse to transmit information without the user's permission or knowledge.
Many people have been asking (cursing, etc.:) for Mozilla, Mac, Opera etc. support. I think it would be great to investigate, and I have a student trying to learn something about Mozilla now. We just don't have the expertise yet. I'd be very interested in hearing from potential contributors. Heck, just a plugin or diff that shows how we can tap into browsing events and access the DOM in Mozilla could make it possible for us to proceed. Frankly, IE support was pretty easy because of all the books and sample code out there. Besides, we had just finished a long-winded report on IE browser extensions & their privacy practices when we started this project, which made Bugnosis pretty easy to envision.
We decided not to make Bugnosis a Web bug blocker, just a good analysis and exposition tool. See, the problem with many "privacy enhancing technologies" is that they put the burden on users to protect themselves. I firmly believe that being concerned about privacy shouldn't mean that you have to make it a huge personal priority, say, by committing time to downloading, maintaining, and upgrading yet another piece of software. Privacy should just be built in. Bugnosis shows how the current infrastructure is being used, and so contributes to the debate on what reasonable standards should be. In the privacy arms race, I'd much rather be a reporter in the trenches than an arms manufacturer -- even defensive arms.
Any CS students interested in working with us? We'll be setting up at Boston University in the fall.
You observed that your competitor forgot to put brakes on the car that your would-be client bought from them. They are both in danger. Send a letter to both and move on.
This is not a sales opportunity -- you have a professional obligation to warn of catastrophe when you see it coming so clearly. You can stress your super brakes in your next bid if you want...
Cutting and pasting from an HTML email, at least within Outlook Express 5, preserves embedded JavaScript that appears within the area selected to cut. So the suggestion might not work.
Slashdot Mirror
By the way, I put up the relevant court document PDFs on my Web page (where I also managed to capitalize SONICblue correctly): http://www.cs.bu.edu/~dm/pubs/replaytv.html
Here's part of the actual order. On April 26, Judge Charles Eick of the U.S. District Court, Central District of California, gave SonicBLUE 60 days to:
(1) take the steps necessary to use their broadband connections with ReplayTV 4000 customers to gather all available information about how users of the ReplayTV employ the devices, including all available information about what works are copied, stored, viewed with commercials omitted, or distributed to third parties with the ReplayTV 4000, when each of those events took place, and the like;
(2) implement Defendants' offer to collect available data from a second source -- the MyReplayTV.com web site -- about how users of the ReplayTV employ the devices, but for all time periods for which that data can be collected, rather than just for a short period;
(3) provide the foregoing data to Plaintiffs in a readily-understandable electronic format and provide any technical assistance that may be necessary for Plaintiffs to review the data;
(4) provide Plaintiffs with all documents about Defendants' consideration of what data to gather or not to gather about their customers' uses of the ReplayTV 4000; and
(5) provide Plaintiffs with any other documents (such as emails or logs) reflecting what works have been copied with the ReplayTV 4000 and how those works have been stored, viewed, or distributed.
Now who gets all of this data? The plaintiffs in the case against SonicBLUE (the makers of the ReplayTV 4000). Roughly, Time Warner, HBO, Warner Brothers, TBS, New Line Cinema, Castle Rock Entertainment, WB TV, MGM Studios, Orion Pictures, 20th Century Fox, Universal City Studios, Fox Broadcasting, Paramount Pictures, Disney, NBC, Showtime, United Paramount Network, ABC, Viacom, CBS, Columbia Pictures, Columbia TV, and Tristar. The plaintiffs are also ordered to pay 3/4 of the cost of gathering the data.
Come on. Our courts have no business ordering a company to spy on its own customers just because big media wants to put the company out of business. We at the Privacy Foundation saw a lot of consumer outrage after we released our report about TiVo's privacy disclosure and practices. TiVo did a pretty good job of responding to the situation; they spent a lot of time with the press, and they wrote a white paper explaining what had happened. (We still have some gripes about their system, but that's another story.) The point is that companies are very sensitive about tweaking their customers' privacy, because they know customers don't have much patience for it. So when the court orders a company to spy on their customers, it's basically a punitive act. The customers will revolt and get mad at everyone. I'm no lawyer, but I'm pretty sure the discovery of evidence phase of a lawsuit isn't supposed to be punitive.
In this case it's worse than just a privacy squabble. Either the court doesn't understand or the court doesn't believe ReplayTV's repeated explanation that they simply don't have the information demanded by this order. See, in April 2001 some months after our TiVo report came out, I showed a ReplayTV exec my traces that proved that their current model also collected some type of viewing information. This scared them, and in May 2001 - before the ReplayTV 4000 existed - they disabled the collection function, since they had never used the data for anything. This is what they told me, and this is what they've sworn to the court in testimony.
Now the ReplayTV 4000 is a different product than the one I investigated, and ReplayTV has said that they never reenabled the old tracking code, nor did they update it to make it monitor the newer features - like automatically skipping commercials and sending recordings to other ReplayTV 4000 units. But that's precisely the type of data that the plaintiffs are demanding to see in this case!
So what we have is a court ordering SonicBLUE to prepare a new software release that implements new spying features, and then ordering them to force it upon all of their customers, out of fairness to Big Media in their case against them. Considering that SonicBLUE has probably updated their customers' software only a few times ever, this is like ordering Microsoft to create, distribute, and maintain a new version of Outlook that checks to see if any of its users are sending MP3s as attachments!
I guess this is a sneak preview of the type of consumer broadband "protection" we can look forward to in the very near future.
What happens next: SonicBLUE is planning to file papers with the overseeing judge in U.S. District court objecting to this order. If that doesn't go their way, then I guess they'll be working on a new software release.
David Martin
http://www.cs.bu.edu/~dm
As I understand it, the clients will send their IDs to bnetd, but bnetd has no way to verify whether they are valid or not. So what if bnetd were to just forward each client ID to battle.net and await validation before letting that client join the bnetd network? You'd be stuck with an initial roundtrip to battle.net for each client, but afterwards the play could proceed independently.
Even if this is not technically possible right now, battle.net has an obligation to consider supporting low-impact measures like this that preserve their rights without trampling on other noninfringing uses. The courts are there to decide disputes when the parties can't agree, but this dispute seems pretty easy to deal with.
So, it's an unwelcome development, but if the bnetd developers decide to spend some time now trying to work with battle.net to find a technical fix, it's time well spent. In particular, the courts are not going to be sympathetic to battle.net if a straightforward solution were proposed but then ignored by battle.net.
I still say that the Web bug is there for info transfer only. It certainly isn't there for visual purposes, so what other explanation is there? When I was going off about cookie sync I was talking about the capability of the channel, not Slashdot/OSDN's practices in particular, and I didn't intend to imply that the very broad term "info transfer" is a synonym for the very specific term "cookie sync". In the case of Slashdot/OSDN I would guess the bug is an aggregate hit counter of some type. To me, that's a type of info transfer, not image display, and I agree they indeed could achieve the same with out-of-band log swapping.
David
I have to disagree. There is a very important difference between the info transfer with a Web bug (or equivalent) and just sending around log files behind the scenes. Our FAQ covers this.
In the scenario I described, OSDN ends up with both cookies. This allows OSDN to synchronize with Slashdot, allowing both sites to realize they're discussing the same user, no matter when the sites originally assigned the cookies, and without planning to synchronize in advance. If on the other hand Slashdot just sends a log file to OSDN, then the synchronization is much harder to achieve, and in practice, would probably not even be attempted.
Basically, it's the same old third-party cookie synchronization threat. Now, cookie sync can be done with banner ads or other 3rd-party content and is not uniquely associated with Web bugs. But when you encounter a Web bug, it is absolutely clear that (1) it's there for the info transfer alone and (2) it's trying to slip under the radar. That makes it a pretty interesting device, from a policy point of view.
By adding a Web bug to HTML email, you can track the progress of your emails, and under further assumptions, you can even intercept comments added by people who forwarded your email: see our email wiretapping report, originally described by Carl Voth. A yet-to-be-distributed version of Bugnosis examines Outlook and Outlook Express emails for Web bugs too.
When the browser fetches the Slashdot page, it sends the Slashdot cookie if any. Slashdot can then encode that cookie into the name of the Web bug image, so when the browser fetches the image from OSDN, it effectively tells OSDN the user's Slashdot cookie. No JavaScript required.
I'm not saying that Slashdot and OSDN are actually doing this -- just that the info conduit allows it.
David
Many people have been asking (cursing, etc. :) for Mozilla, Mac, Opera etc. support. I think it would be great to investigate, and I have a student trying to learn something about Mozilla now. We just don't have the expertise yet. I'd be very interested in hearing from potential contributors. Heck, just a plugin or diff that shows how we can tap into browsing events and access the DOM in Mozilla could make it possible for us to proceed. Frankly, IE support was pretty easy because of all the books and sample code out there. Besides, we had just finished a long-winded report on IE browser extensions & their privacy practices when we started this project, which made Bugnosis pretty easy to envision.
We decided not to make Bugnosis a Web bug blocker, just a good analysis and exposition tool. See, the problem with many "privacy enhancing technologies" is that they put the burden on users to protect themselves. I firmly believe that being concerned about privacy shouldn't mean that you have to make it a huge personal priority, say, by committing time to downloading, maintaining, and upgrading yet another piece of software. Privacy should just be built in. Bugnosis shows how the current infrastructure is being used, and so contributes to the debate on what reasonable standards should be. In the privacy arms race, I'd much rather be a reporter in the trenches than an arms manufacturer -- even defensive arms.
Any CS students interested in working with us? We'll be setting up at Boston University in the fall.
David
You observed that your competitor forgot to put brakes on the car that your would-be client bought from them. They are both in danger. Send a letter to both and move on.
This is not a sales opportunity -- you have a professional obligation to warn of catastrophe when you see it coming so clearly. You can stress your super brakes in your next bid if you want...
David Martin, University of Denver