“Roadcast Flag” Is MPAA's Latest Attack on Linux
The Digital Millennium Copyright Act (DMCA) gave copyright holders powerful new rights to control implementations of proprietary protocols and media formats. Yet, it took a hands-off position toward non-proprietary formats. You still are free under the DMCA to implement a system based on open standards with the features of your choice.
But now, even this “no mandate” rule is under attack from proposals to regulate the use of open standards. The best-known is the Consumer Broadband and Digital Television Promotion Act (CBDTPA), introduced by Sen. Ernest Hollings. CBDTPA goes beyond the DMCA and requires that any “digital media device” must include “standard security technologies”.
The CBDTPA has been criticized from many directions. But entertainment industries have effectively split it into a series of more palatable pieces. The Motion Picture Association of America (MPAA) has spent the past year pursuing three new regulatory measures:
A “broadcast flag” mandate for all devices that can receive digital television broadcasts.
An “analog hole” watermark-detection mandate for “all devices that perform analog-to-digital conversions”.
An unspecified technology mandate for peer-to-peer file-sharing software.
None of these measures, individually, is as drastic as the CBDTPA. Mandates can be imposed gradually; technology industries may not launch an all-out campaign against any particular measure. Tech vendors may be divided and choose not to oppose measures that don't affect them directly.
MPAA's lobbying for a “broadcast flag” mandate is already underway. This proposal is specific to US terrestrial digital television broadcasts. But it's the first part of a larger regulatory agenda that needs to be stopped now—movie studios should have less, not more, control over our technology.
Current-generation US television broadcasts use the 50-year-old analog NTSC transmission standard. In 1996, the US adopted a plan to replace NTSC gradually with a next-generation digital standard, ATSC, capable of carrying high-definition TV pictures. This transition was meant to finish around 2006 with the complete discontinuation of analog TV broadcast. Meanwhile, stations are broadcasting both analog and digital TV signals (using additional channels lent to them by the government). ATSC-capable home theater equipment and PC adapters are now available. The transition is underway.
ATSC is an open standard, and terrestrial broadcasts using it are always unencrypted. Therefore, the DMCA does not restrict the kinds of features that can be included in an ATSC receiver. Hollywood studios have begun to complain that this means ATSC broadcasts are too insecure for transmission of Hollywood movies—if anybody can build a receiver, the movies could be used in ways the studios might wish to prevent.
The studios have argued that the “insecurity” of ATSC receivers is deterring them from licensing their movies for ATSC broadcast. They regularly license their movies for unencrypted NTSC broadcast, but the superior quality of ATSC purportedly makes it a more attractive target for copyright infringement. Instead of encrypting the broadcasts, however, the studios have proposed new legal restrictions that limit how a TV signal can be used on receiving devices. According to the studios' proposal, the TV receiver, whether hardware or software, would have to be “compliant” and “robust” against modification by an end user.
Instead of encryption, the proposed measure is merely a label or header akin to an e-mail header defined to signal “technological control of consumer redistribution”. Such a measure is no more effective than an “X-No-Forward:” e-mail header, but a law or regulation could deem it illegal to fail to honor such a header.
This regulation leads us away from a world where people are free to implement open standards as they choose. ATSC has been such a standard, but the benefits of its openness, including support by free software, could be lost.
“Compliance” requirements limit permissible outputs to a short list of restricted formats, implementations of which are subject, in turn, to DMCA restrictions. Open standards need not apply. This creates a tremendous incentive for consumer electronics manufacturers to implement proprietary technologies. Open interfaces, which one studio representative referred to as “legacy interfaces” because they lack copy controls, would suffer a substantial competitive disadvantage.
“Robustness” requirements prevent programmers from developing free drivers for ATSC, such as the free drivers already being developed for ATSC tuner cards. They also would ban free software implementations of ATSC, such as FSF's GNU Radio Project, which interprets radio signals in software. If software can be modified by an end user, it can't be trusted to control how users use it—the same argument the MPAA uses against the development of free DVD players. The broadcast flag rules could result in a ban on certain kinds of free software specifically because that software can be modified by end users.
The Federal Communications Commission (FCC) is now considering whether to mandate that TV-receiving equipment comply with these rules.
EFF is fighting this proposal and recently filed comments with the FCC against it. We attended all the meetings of the Broadcast Protection Discussion Group where the proposal was developed. With our “Consensus At Lawyerpoint” web site, we've tried to fill the information vacuum surrounding the broadcast flag issue. (Reporters were barred from meetings, which had a $100-per-meeting admission fee.)
Seth David Schoen created the position of EFF staff technologist, helping other technologists understand the civil liberties implications of their work, EFF staff better understand the underlying technology related to EFF's legal work, and the public understands what the technology products they use really do.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- Purism Librem 13 Review
- diff -u: What's New in Kernel Development