December 15, 2024

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

Comments

  1. The FCC – Stupid or Dissimulators?

    Prof. Ed Felten makes a good point on Freedom to Tinker about the FCC’s justifications for the Broadcast Flag – they are incoherent (The Broadcast Flag, and Threat Model Confusion). The justifications for the broadcast flag and the effect of…

  2. Beth – There have been a number of articles in the press the past few years about Sony’s difficulties straddling the worlds of entertainment content and technological hardware. As far as the BF, the main question is how bad this will be for the hardware guys?

    The pro BF people were waving around a quote claiming that with all the other stuff going on in HDTV, doing the BF would not add much expense. So there may not be much opposition from Sony’s techno side. In that case I’d think the content guys would win and Sony would come down pro BF.

    The main question would be, is there anything Sony really wants to do but they can’t do it because of the BF? And even if the answer is yes, the BF kind of levels the playing field from Sony’s perspective. That is, Sony is already going to be slow to get into piracy promoting technologies compared to a pure hardware company, because of its internal split personality. So if the BF slows everyone down in this area, that actually works to Sony’s benefit as its competitors will have less of an advantage over it.

  3. There is some dispute about whether the FCC had the authority to issue the broadcast flag rule. The FCC’s broadcast flag order argues that it does have such authority. There may well be a legal challenge to the order, based on this authority issue.

    I don’t have the background to judge who is right.

  4. Assuming the broadcast flag order eliminates Fair Use considerations, Public Domain recognition, and consumer choice, in favor of moving all technology toa pre-market approval process controlled by the Entertainment Industry, I find this order to be in complete conflict with the charter of the FCC. Why is it permitted to be discussed, let alone issued? Who are these officials accountable to?

  5. Hi there,
    My name is Beth and I am grad student doing a research presentation on the Braodcast Flag issue from the perspective of SONY. I am having a hard time figuring out where SONY should come out on the Broadcast Flag issue. I know the ruling came out on Tuesday but I have to argue it as though it is still pending. So what do you guys think? Due to the fact that they are a manufacturer who now must deal with new technical constraints, are they opposed or as they are also a content source in need of protection should I argue in favor?
    I can do what I want regardless of what Sony actually did in the real world.
    I am sure you all have better things to do than this, but any comments would be great!
    -Beth

  6. Hi there,
    My name is Beth and I am grad student doing a research presentation on the Braodcast Flag issue from the perspective of SONY. I am having a hard time figuring out where SONY should come out on the Broadcast Flag issue. I know the ruling came out on Tuesday but I have to argue it as though it is still pending. So what do you guys think? Due to the fact that they are a manufacturer who now must deal with new technical constraints, are they opposed or as they are also a content source in need of protection should I argue in favor?
    I can do what I want regardless of what Sony actually did in the real world.
    I am sure you all have better things to do than this, but any comments would be great!
    -Beth

  7. Ed,

    Which threat model were the security folks thinking about when they decided to pre-print at random a large “*S*” on airplane boarding passes to alert security to conduct more thorough searches?

    Recently, I missed a flight solely when selected for search by this method.

    Since any organized terrorist would have the time AFTER the pass was printed and BEFORE he or she entered security, I have to think that this method would only help prevent a casual terrorist from boarding the plane.

    I think that you’re threat model is a construct the department of homeland security would be smart to consider.

    – Mike

  8. [from NPRM] The CSS content protection system serves as an adequate speed bump for most consumers

    I think Macrovision on the outputs of DVD players is the effective speed bump here. It has caused consumer grief because VCRs wouldn’t work as RF modulators for TVs lacking baseband video inputs, but it has prevented casual copying to VHS tape.

    The other speed bump is region coding which prevents some amount of grey market DVD importing.

    Neither of these measures strictly required encryption of the digitized video. Keeping manufacturers from making players that ignore region coding or disable Macrovision was mostly a matter of licensing backed up by trade secret law, though in the US, the DMCA does add another strike against non-licensed (by the DVD-CCA) players.

    There’s nothing casual at this point about copying a DVD over the internet or to a DVD-R due to the need to recompress in MPEG-4 for the former and the need to recompress in lower quality MPEG-2 for the latter as DVD-9 recorders are not generally available (must squeeze 9GB to 4.7GB).

  9. Paul,

    It’s from the FCC’s press release:

    http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-240759A1.pdf

  10. I was hoping to see a comment on this quote:

    ‘The broadcast flag protects consumers’ use and enjoyment of broadcast video programming. The flag does not restrict copying in any way.'”

    but I’m not sure where it came from, beyond this article:

    http://yro.slashdot.org/article.pl?sid=03/11/05/0113226&mode=thread&tid=103&tid=126&tid=129&tid=188&tid=99

  11. peterverstappen says
  12. Mark Gritter says

    I’m particularly amused by this paragraph:

    20 …The DVD example is instructive in this regard. Although the CSS copy protection system for DVDs has been hacked and circumvention software is available on the Internet, DVDs remain a viable distribution platform for content owners. The CSS content protection system serves as an adequate speed bump for most consumers, allowing the continued flow of content to the DVD platform. We believe the same rationale applies here.

    Yet, file-sharing networks have plenty of DVD rips available (mainly reencoded). I don’t think there is any evidence that CSS has actually prevented any distribution of copyright materials— are non-encrypted DVDs more prevalent than encrypted ones? But somehow it is hailed as a success. Is this just because content producers have not abandoned DVDs? There is no evidence that the FCC has looked at examples where copy protection has has the opposite effect and killed the medium…

  13. he “threat model” issue just came up in the comments of my blog post Broadcast Flag – desecration, as I’ve argued the controllers are not being stupid.

    Written out bluntly, the strategy seems to be that size and bandwidth constraints keep down the “global” threat, while the speedbump addresses the “local” threat.

    The idea is, if you stop almost everbody with a video card from being a potential source for their campus LAN, the difficulty of downloading material over much slower external links means there won’t be many copies in circulation.

    Again, this might ultimately be wrong, but it’s at least arguable.