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.)
