June 24, 2017

Archives for October 2006

YouTube and Copyright

YouTube has been much in the news lately. Around the time it was bought by Google for $1.65 billion, YouTube signed copyright licensing deals with CBS television and two record companies (UMG and Sony BMG). Meanwhile, its smaller rivals Bolt and Grouper were sued by the record industry for infringement.

The copyright deals are interesting. The first question to ask is whether YouTube needed the deals legally – whether it was breaking the law before. There’s no doubt that some of the videos that users upload to YouTube include infringing video and audio content. You might think this makes YouTube an infringer. But the law exempts service providers from liability for material stored on a server at users’ request, as long as certain conditions are met, including a requirement that the service provider take down material promptly on being notified that specific content appears to be infringing. (See section 512(c) of the DMCA.) Whether a site like YouTube qualifies for this exemption will be one of the main issues in the lawsuits against Bolt and Grouper.

It’s easy to see why CBS and the record companies want a deal with YouTube – they get money and greater control over where their content shows up on YouTube. Reading between the lines in the articles, it looks like YouTube will give them fairly direct means of taking down videos that they think infringe their copyrights.

Why would YouTube make a deal? Perhaps they’re worried about the possibility of lawsuits. YouTube hasn’t been sued yet, but the Bolt and Grouper cases might create precedents that put YouTube in jeopardy. YouTube might prefer to make deals now rather than take that risk.

But even if it faces no legal risk, YouTube might want to make these deals anyway. If users feel safer in posting CBS, UMG and Sony BMG content on the site, they’ll post more of that content, and they’ll face fewer frustrating takedowns. The deals might give YouTube users more confidence in using the site, which can only help YouTube.

Finally, we can’t ignore the influence of politics. In recent years, entertainment companies have run to Congress whenever they thought a new product led to more infringement. Congress has typically responded by pressuring the product’s maker to cut licensing deals with the entertainment companies. YouTube is getting in front of this process by making deals now. Again, whether YouTube is actually breaking the law makes little difference, because the dynamic of entertainment company complaints followed by threats to regulate relies not on existing laws but on threats to create new, more restrictive law.

Whether YouTube qualifies for the legal exemption is an interesting question for lawyers to debate. But in today’s copyright policy environment, whether a company is breaking the law is only one piece of the equation.

iPods Shipped with Worm Infection

Apple revealed yesterday that some new iPods – about 1% of the new iPod Videos shipped in the last month or so – were infected with a computer worm that will spread to Windows PCs, according to Brian Krebs at the Washington Post. Apparently a PC used to test the iPods got infected, and the worm spread to the iPods that were connected to that PC for testing.

As far as the worm is concerned, the iPod is just another storage device, like a thumb drive. The worm spreads by jumping from an infected PC to any removable storage device inserted into the PC, and then using the Windows autorun mechanism to jump from the storage device into any PC the storage device is inserted into.

Apple tried to spread the blame: “As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it.” The jab at Windows probably refers to the autorun feature, which MacOS lacks, and which is indeed a security risk. (I hear that autorun will be disabled by default in Windows Vista.) Apple also says that the infected machine belonged to a contractor, not to Apple itself. If I were a customer, I would blame Apple – it’s their job to ship a product that won’t hurt me.

As Brian Krebs reminds us, this is at least the third case of portable music players shipping with malware. Last year Creative shipped a few thousand infected players, and McDonalds Japan recently gave away spyware-infected players.

In all of these cases, the music players were not themselves infected – they didn’t run any malware but only acted as passive carriers. It didn’t matter that the music players are really little computers, because the worm treated them like dumb memory devices. But someday we’ll see a scary virus or worm that actively infects both computers and music players, jumping from one to the other and doing damage on both. Once autorun goes away, this will be the natural approach to writing player-borne malware.

In principle, any device that has updatable software might be subject to malware infections. That includes music players, voting machines, printers, and many other devices. As more devices get “smart”, we’ll see malware popping up in more and more places.

ThreeBallot and Tampering

Let’s continue our discussion (1; 2) of Rivest’s ThreeBallot voting system. I’ve criticized ThreeBallot’s apparent inability to handle write-in votes. More detailed critiques have come from Charlie Strauss (1; 2) and Andrew Appel. Their analysis (especially Charlie’s) is too extensive to repeat here, so I’ll focus on just one of Charlie’s ideas.

Recall that ThreeBallot requires each voter to mark three ballots. Each candidate must be marked on at least one ballot (call this the mandatory mark); and the voter can vote for a candidate by marking that candidate on a second ballot. I call these rules (each candidate gets either one or two marks, and at most one candidate per race gets two marks) the Constraints. Because of the Constraints, we can recover the number of votes cast for a candidate by taking the total number of marks made for that candidate, and subtracting off the number of mandatory marks (which equals the number of voters).

ThreeBallot uses optical scan technology: the voter marks paper ballots that can be read by a machine. A voter’s three ballots are initially attached together. After filling out the ballots, the voter runs them through a checker machine that verifies the Constraints. If the ballots meet the Constraints, the checker puts a red stripe onto the ballots to denote that they have been checked, separates the three ballots, and gives the voter a copy of one ballot (the voter chooses which) to take home. The voter then deposits the three red-striped ballots into a ballot box, where they will eventually be counted by a tabulator machine.

Charlie Strauss points out there is a window of vulnerability from the time the ballots are checked until they’re put in the ballot box. During this time, the voter might add marks for his desired candidate, or erase marks for undesired candidates, or just put one of the ballots in his pocket and leave. These tactics are tantamount to stuffing the ballot box.

This kind of problem, where a system checks whether some condition is true, and then later relies on that assumption still being true even though things may have changed in the meantime, is a common cause of security problems. Security folks, with our usual tin ear for terminology, call these “time of check to time of use” or TOCTTOU bugs. (Some people even try to pronounce the acronym.) Here, the problem is the (unwarranted) assumption that if the Constraints hold when the ballots are put into the checker, they will still hold when the ballots are later tabulated.

One way to address this problem is to arrange for the same machine that checks the ballots to also tabulate them, so there is no window of vulnerability. But ThreeBallot’s security depends on the checker being dumb and stateless, so that it can’t remember the ballot-sets of individual voters. The tabulator is more complicated and remembers things, but it only sees the ballots after they are separated and mixed together with other voters’ ballots. Rivest makes clear that the checker and the tabulator must be separate mechanisms.

We might try to fix the problem by having the checker spit out the checked ballots into a sealed, glass-sided chute with a ballot box at the bottom, so the voter never gets to touch the ballots after they are checked. This might seem to eliminate the window of vulnerability.

But there’s still a problem, because the ballots are scanned by two separate scanner devices, one in the checker and one in the tabulator. Inevitably the two scanners will be calibrated differently, so there are some borderline cases that look like a mark to one scanner but not to the other. This means that ballot-triples that meet the Constraints according to one scanner won’t necessarily meet them according to the other scanner. A clever voter can exploit these differences, regardless of which scanner is more permissive, to inflate the influence of his ballots. He can make his mandatory marks for disfavored candidates faint, so that the checker just barely detects them, in the hope that the tabulator will miss them. And he can add a third mark for his favored candidate, just barely too faint for the checker to see, in the hope that the tabulator will count it. If either of these hopes is fulfilled, the final vote count will be wrong.

This is just a small sample of Charlie Strauss’s critique of ThreeBallot. If you want to read more, check out Charlie’s reports (1; 2), or Andrew Appel’s.