November 24, 2024

Taming EULAs

Most software programs, and some websites, are subject to End User License Agreements (EULAs). EULAs are long and detailed and apparently written by lawyer-bots. Almost everybody agrees to them without even reading them. A EULA is a contract, but it’s not the result of a negotiation between the vendor and the user. The vendor writes the EULA, and the user can take it or leave it. Most users just accept EULAs without thinking.

This has led to any number of problems. For example, some EULAs give the software vendors permission to install spyware – and most users never realize they have granted that permission.

Why don’t users pay more attention to EULAs? Rational ignorance is one possibility – it may be that the cost of accepting a bad EULA every now and then is lower than the cost of actually reading EULAs and making careful decisions. If so, then a rational cost-minimizing user won’t read EULAs.

And there are a few oddballs who read EULAs. When these people find a particularly egregious provision, they spread the word. Occasionally the press will report on an extreme EULA. So rationally ignorant consumers get a little information about popular EULAs, and there is some pressure on vendors to keep their EULAs reasonable.

In domains where rational ignorance is common, tools often spring up to help people make decisions that are more rational and less ignorant. If it’s not worth your time to research your senator’s voting record, you can look at how he is rated by the Environmental Defense Fund or the NRA, or you can see who has endorsed him for reelection. None of these sources captures the nuances of an individual voting record. But if you’re not going to spend the time to examine that record, these crude tools can be valuable.

When it comes to EULAs, we don’t have these tools. So let’s create them. Let me suggest two useful tools.

The first tool is a service, provided via a website, that rates EULAs in the same way that political advocacy groups rate legislators. I’m not talking about a detailed explanation – which rationally ignorant users wouldn’t bother to read – but a simple one-dimensional rating, such as a grade on an A-to-F scale. Products whose EULAs get good scores might be allowed to display a trademarked “Our EULA got an A-” logo.

Naturally, reducing a complex EULA to a single rating is an oversimplification. But that’s exactly the point. Rationally ignorant users demand simplification, and if they don’t get it they’ll decide based on no information at all. The site could offer more details for users who want them. But let’s face it: most users don’t.

The second tool is a standardized template for writing EULAs, akin to the structure of Creative Commons licenses. You’d have some core EULA language, along with a set of modules that could be added at the vendor’s discretion. Standardized EULAs can be displayed concisely to the user, by listing the modules that are included. They could be expressed easily in machine-readable form, so various automated tools could be created.

The main benefit of standardization is that users could re-use what they had learned about past licenses, so that the cost of learning about a license could be amortized over more decisions. Standardization would also seem to benefit those companies who have more likable EULAs, since it would help users notice the substantive differences between the EULAs they see.

Will either of these things happen? I don’t know. But I would like to see somebody try them.

The Broadcast Flag, and Threat Model Confusion

The FCC has mandated “broadcast flag” technology, which will limit technical options for the designers of digital TV tuners and related products. This is intended to reduce online redistribution of digital TV content, but it is likely to have little or no actual effect on the availability of infringing content on the Net.

The FCC is committing the classic mistake of not having a clear threat model. As I explained in more detail in a previous post, a “threat model” is a clearly defined explanation of what a security system is trying to prevent, and of the capabilities and motives of the people who are trying to defeat it. For a system like the broadcast flag, there are two threat models to choose from. Either you are trying to keep the average consumer from giving content to his friends and neighbors (the “casual copying” threat model), or you are trying to keep the content off of Internet distributions systems like KaZaa (the “Napsterization” threat model). You choose a threat model, and then you design a technology that prevents the threat you have chosen.

If you choose the casual copying model, your DRM technology needs to be strong enough to resist attack by average consumers only; but your technology will not address the Napsterization threat. If you choose the Napsterization threat model, then you have to be able to stop every would-be infringer from ripping the content, because if even one person manages to rip the content and upload it onto the Net, the content becomes available to everybody who wants it.

The FCC seems to be trying to have it both ways. They have mandated technologies that are only strong enough to prevent casual copying by typical consumers. But at the same time, they somehow expect those technologies to prevent Napsterization. This incoherence is evident throughout the FCC’s broadcast flag order. At several points the two incompatible threat models appear in the same paragraph; here is an example:

19. We recognize the concerns of commenters regarding potential vulnerabilities in a flag-based protection system. We are equally mindful of the fact that it is difficult if not impossible to construct a content protection scheme that is impervious to attack or circumvention. We believe, however, that the benefits achieved by creation of a flag-based system – creating a “speed bump” mechanism to prevent indiscriminate redistribution of broadcast content and ensure the continued availability of high value content to broadcast outlets – outweighs the potential vulnerabilities cited by commenters….

(emphasis added) The error here should be clear – a “speed bump” cannot prevent “indiscriminate redistribution”.

(I’ll have more to say about the broadcast flag in subsequent posts.)

Election Day

It’s Election Day, and residents here in Mercer County may have cast our last votes on the big old battleship-gray lever voting machines. Next election, we’re supposed to be using a new all-electronic system, without any of the necessary safeguards such as a voter-verifiable paper trail or public inspection of software code.

Broadcast Flag Confusion

In today’s New York Times, Stephen Labaton reports on the continuing controversy over the FCC’s impending Broadcast Flag rules. In the midst of a back-and-forth about the rules, Labaton writes this:

An F.C.C. official said, for instance, that the broadcast flag could contain software code that was recognized by computer routers in a way that the program would self-destruct after passing through three routers while being e-mailed by a user.

Somebody is really confused here about how the Internet works. Maybe it’s the reporter, or maybe it’s the FCC source, or maybe (God forbid) both.

If this statement bears any connection to reality, it’s cause for serious worry. I can’t think of any way of translating the statement into a technically coherent form that doesn’t involve the FCC redesigning the basic workings of the Internet.

UPDATE (8:55 PM): Seth Schoen has solved the mystery; see his comment. The mystery sentence looks like a very confused attempt to explain the fact that DTCP-over-IP sets the Time-To-Live field on its IP packets equal to three.

Swarthmore Bans Indirect Links

Ernest Miller reports that Swarthmore now is yanking the Net connections of students who linking to a page that links to a page containing the infamous Diebold memos.

So Swarthmore students can’t make a two-hop link to the memos (i.e., a link to a link to the memos). Can they make a three-hop link, say by linking to Ernest Miller’s report? Can they make a four-hop link, say by linking to the page you are reading right now? Can they make a five-hop link, say by linking to my personal home page? Maybe some enterprising Swarthmore student will do an experiment to find out.

UPDATE (1:40 PM, Oct. 27): James Grimmelmann at LawMeme says that Diebold’s own home page contains a five-hop link.