EFF
reports more action
on the Broadcast Flag front. The
broadcast flag, if you don't
know, is control information attached to audio or video that tells
compliant devices whether it can save, copy, etc. Such devices
will of course be forbidden from exporting protected content
in non-protected form or sending it to non-compliant devices.
So, for instance, your HDTV tuner wouldn't be able to send
decoded copies of broadcast-flagged data to a general purpose
computer for processing. Think of it as a roach motel for data.
It's obvious why the broadcasters want this: they want to extract
monopoly rents by selling off each individual use of their content
rather than giving people the kind of blanket capability that they
have now. Consider a TV show that you've taped off the air:
you can make as many copies as you want, send them to your
friend, whatever. The networks would clearly prefer to charge
you for each viewing and definitely don't want you making long-term
copies and giving them to friends.
Ignore for the moment the question of whether this sort of price
discrimination is a valuable thing. Ask instead why this means
you need the broadcast flag.
There are two big problems with the broadcast flag as specified:
First, it's not very secure. Consider the security properties of the broadcast flag system.
It creates a closed environment of machines all of which
supposedly enforce correct security policies. As long as
none of the machines are compromised, then this all works
fine. But consider what happens if a single machine--or more
likely class of machines--is compromised. Anyone who owns one
of those machines can export any content he receives in
plaintext form. Allan Schiffman used to call this type of
system a "distributed single point of failure" (he was talking
about thinnet).
Of course, you don't need to have a compromised device in order
to bring about this scenario: it's fairly easy to build an
HDTV-capable device that doesn't respect the broadcast flag.
Indeed, that's the situation with the HDTV-tuners you buy
today. So, if pirates (for instance) want to record HDTV
signals off the airwaves and then burn them to DVD, they
won't have any problem doing it. The only people who are
going to be seriously inconvenienced here are consumers.
This brings us to the second big problem: the broadcast
flag is horribly inconvenient for consumers. This inconvenience
comes in three flavors. The first is intentional: all sorts of
things you'd want to do with the content--and that you can
currently do--such as time-shifting, space-shifting, etc.
will be prohibited by the broadcast flag. That's the point,
after all. The second two inconveniences are collateral
damage. It gets much harder to write generic content (image/audio/video)
processing applications because they need to keep the content
from being exported. This brings us into the whole
Trusted Computing
mess.
Finally, because the content is actually being transmitted
in the clear, in order for the system to work it needs to be illegal
to make non-broadcast-flag decoders. This is essentially fatal to
software-defined radio type systems unless they themselves run on trusted computers,
which means that you won't be able to make SDRs that run on Open
Source operating systems. This doesn't sound like a big deal right
not, but it precludes a lot of really cool applications of SDR
that are likely to be around the corner as processors get faster.
Consider the following alternative design:
- The networks broadcast their traffic in encrypted form
along with signed access control restrictions.
- The encryption keys are restricted to devices which
obey the access control restrictions on content.
- Compliant devices never export plaintext but rather
re- export ciphertext to any device. They can
also re-encrypt to other compliant devices, for instance
if they transform the data before export.
From the perspective of both security and convenience, this design
dominates the broadcast flag. It's more secure because a generic
RF-receiver can't receive the content. You actually need the
keying material. This means you need to compromise a legitimate
unit, which puts at least a modest barrier in the way of
piracy. I don't want to overstate the case here: this kind
of technology is used for pay satellite television and it
gets broken pretty regularly, but the networks have
managed to impose pretty substantial costs on the pirates
and do a pretty good job of protecting their revenue stream.
A cryptography-based design is superior from a convenience
perspective as well, since it means that there's no need
to impose legal restrictions on receiving technology. The networks
can simply impose restrictions on receivers that can decode
their signals--just like the situation with DVDs. Now, it's
certainly true that this may end up with everyone having
a "secure content"-enabled unit, but maybe not. And in any
case it wouldn't get in the way of people developing new, cool
applications on spectrum not dominated by the radio and TV networks.
And of course it's possible--though not guaranteed--that there would
be enough content broadcast without restrictions that you could
make a good business selling products that just didn't play secure
content.
It's obvious why the networks don't want to go this route, of course.
It's
a pain in the ass to manage this kind of cryptographic infrastructure
and it's certainly much easier to just have the FCC impose the costs
on consumers. However, seeing as the entire purpose of this
scheme is increased revenue extraction, it's hard to see why
consumers should be legally required to bear the costs when a workable alternative
exists.