Post by dkennedy on Feb 25, 2005 7:39:43 GMT -5
The Clicker: Demystifying the HD Broadcast Flag
Posted Feb 17, 2005, 2:44 PM ET by Peter Rojas
Each week Stephen Speicher contributes The Clicker, a weekly column on television. Last week he discussed why there are so many d**n standards for HDTV, this week he pokes a stick at the Broadcast Flag:
As we approach the July 1, 2005 deadline of “Broadcast Flag,” I am beginning to hear more and more chants of “Michael Powell is the Devil.”
While I can neither confirm nor deny FCC-Chairman Powell’s status as Lucifer, Satan’s doppelganger, or even a man who likes to wear little red horns, I can say that the FCC’s decision to mandate the Broadcast Flag has somewhat unfairly become the lightning-rod for all matters regarding content protection. I can also say that it gets “credit” for a lot more than it should.
Now, if, on the other hand, your hatred of Powell stems from his treatment of Nipple-gate and its effect on the 2005 Super Bowl half-time show (which had, let’s face it, the excitement of an evening of Scrabble with Bea Arthur), I can hardly blame you. Feel free to chant away.
So what exactly is the Broadcast Flag?
In November of 2003, bowing to pressure from the MPAA and hoping to speed the nation’s transition to digital television, the FCC approved a system (the Broadcast Flag) designed to curb Internet distribution of digitally-broadcasted TV shows. The FCC’s rationale, as twisted as it may be, was that content owners would be more likely to put “the good stuff” on the air if they didn’t fear that perfect digital copies of their content would be spread over the Internet. In turn, consumers would rush to the stores and buy digital televisions. Hey, like I said: “twisted.”
The Broadcast Flag is a system? Yes, the Broadcast Flag is best viewed as two different pieces. First, as a technical piece it’s a tiny bit of data (the flag) that is inserted into a station’s digital stream. This flag lets digital receivers know the protection level of the content. The flag itself is rather benign. It’s a little like the sign in the candy story that says “No Sampling.” It’s just there. It’s not encrypting the data. It’s not stopping existing receivers from receiving the data, and much like a kid who’s too young to read will walk into the candy store and ignore the sign, so too will today’s receivers ignore the flag.
The more controversial aspect of the Broadcast Flag is the set of regulations revolving around how future receivers will treat the content. Beginning July 1st all new devices will be required to protect marked content with an “authorized technology.” The purpose of these authorized technologies is to limit one’s ability to distribute the content via the Internet or other mass methods while simultaneously allowing the consumer unfettered access to his or her content.
In theory that sounds just hunky-dory, but, as you know, the devil is in the details. As most detractors of the Broadcast Flag will tell you, what starts as a way to prevent mass-distribution often leads to situations where consumers are prevented from viewing their recorded content.
Let’s look at an example:
Let’s assume that we are using 5C’s EPN as our authorized technology. EPN (encryption plus non-assertion) allows users to make as many copies of their content as they would like. You can copy any 5C EPN content from one 5C-compatible device to another. You can even make copies of copies (and copies of copies of copies, etc.). 5C relies on the fact that its handshake (a method of determining if both devices are 5C-compliant) must take place locally. Unlimited local copies and no mass-distribution is exactly what they were hoping for.
So far this sounds great. The problem is that once you place your data within the 5C framework you can never get it out. From then on you are limited to 5C-compliant devices. That new video-enabled cell phone might not be a 5C-compliant device. It might use a different method to protect that data. This method might also be acceptable. However, much like the different audio-protection schemas out there (AAC, WMA, etc), transferring from one camp to another is often a process fraught with frustration and futility.
This will be the case with all methods of distribution protection. Unfortunately, it’s nearly impossible to protect content without limiting it. Therein lies the crux of the problem and the meat behind most people’s complaints.
At this point you might be thinking “So, he’s locked up our data and foisted unnecessary copy-protections upon us. Why, again, isn’t he the devil?” Hmmm. At this point in the column I’m starting to wonder the same thing.
The answer is that many people have come to use the term Broadcast Flag as a generic term. It’s important to remember that the July 1 deadline only really deals with over-the-air digital television. Below are some common questions:
Q: I have a PVR from my cable company. Does the broadcast flag mean that I can’t time shift my content?
A: No, the only purpose of the Broadcast Flag is to limit mass-distribution of content. Unlike other types of conditional-access systems there is no provision to limit how the content is used. For instance, there is nothing in the broadcast flag that limits copying locally. Likewise there is nothing that expires content making it unwatchable after a set time.
Q: Recently HBO began encrypting its shows and now Microsoft’s Media Center Edition (MCE) won’t let me copy them with impunity. Surely, I can blame the Broadcast Flag for this, right?
A: Again, no. First, you’re referring to the recent inclusion of CGMS-A. As the A indicates this is an analog technology. While CGMS-A has similar concepts (e.g. terms like copy-never), it isn’t the same thing. The Broadcast Flag in question is a) purely for digital content and b) only intended to regulate content that’s sent OTA (or retransmitted versions of that signal).
Q: Is it true that the Broadcast Flag is the reason that neither TiVo nor MCE work with high-definition cable?
A: Once again, no. Both TiVo and MCE have only tackled OTA HDTV because, unlike a standard TiVo which encodes the analog signal, an analog HDTV signal is way too big to encode at a cost-effective price. The recent roll-out of Digital Cable Ready (DCR) support by the cable companies should mean an acceptable path for stand-alone HD TiVos.
Those are just a few of the questions that unfairly get tied to the Broadcast Flag.
For feedback or column suggestions email theclicker@theevilempire.com. Until next week – save my seat!
Posted Feb 17, 2005, 2:44 PM ET by Peter Rojas
Each week Stephen Speicher contributes The Clicker, a weekly column on television. Last week he discussed why there are so many d**n standards for HDTV, this week he pokes a stick at the Broadcast Flag:
As we approach the July 1, 2005 deadline of “Broadcast Flag,” I am beginning to hear more and more chants of “Michael Powell is the Devil.”
While I can neither confirm nor deny FCC-Chairman Powell’s status as Lucifer, Satan’s doppelganger, or even a man who likes to wear little red horns, I can say that the FCC’s decision to mandate the Broadcast Flag has somewhat unfairly become the lightning-rod for all matters regarding content protection. I can also say that it gets “credit” for a lot more than it should.
Now, if, on the other hand, your hatred of Powell stems from his treatment of Nipple-gate and its effect on the 2005 Super Bowl half-time show (which had, let’s face it, the excitement of an evening of Scrabble with Bea Arthur), I can hardly blame you. Feel free to chant away.
So what exactly is the Broadcast Flag?
In November of 2003, bowing to pressure from the MPAA and hoping to speed the nation’s transition to digital television, the FCC approved a system (the Broadcast Flag) designed to curb Internet distribution of digitally-broadcasted TV shows. The FCC’s rationale, as twisted as it may be, was that content owners would be more likely to put “the good stuff” on the air if they didn’t fear that perfect digital copies of their content would be spread over the Internet. In turn, consumers would rush to the stores and buy digital televisions. Hey, like I said: “twisted.”
The Broadcast Flag is a system? Yes, the Broadcast Flag is best viewed as two different pieces. First, as a technical piece it’s a tiny bit of data (the flag) that is inserted into a station’s digital stream. This flag lets digital receivers know the protection level of the content. The flag itself is rather benign. It’s a little like the sign in the candy story that says “No Sampling.” It’s just there. It’s not encrypting the data. It’s not stopping existing receivers from receiving the data, and much like a kid who’s too young to read will walk into the candy store and ignore the sign, so too will today’s receivers ignore the flag.
The more controversial aspect of the Broadcast Flag is the set of regulations revolving around how future receivers will treat the content. Beginning July 1st all new devices will be required to protect marked content with an “authorized technology.” The purpose of these authorized technologies is to limit one’s ability to distribute the content via the Internet or other mass methods while simultaneously allowing the consumer unfettered access to his or her content.
In theory that sounds just hunky-dory, but, as you know, the devil is in the details. As most detractors of the Broadcast Flag will tell you, what starts as a way to prevent mass-distribution often leads to situations where consumers are prevented from viewing their recorded content.
Let’s look at an example:
Let’s assume that we are using 5C’s EPN as our authorized technology. EPN (encryption plus non-assertion) allows users to make as many copies of their content as they would like. You can copy any 5C EPN content from one 5C-compatible device to another. You can even make copies of copies (and copies of copies of copies, etc.). 5C relies on the fact that its handshake (a method of determining if both devices are 5C-compliant) must take place locally. Unlimited local copies and no mass-distribution is exactly what they were hoping for.
So far this sounds great. The problem is that once you place your data within the 5C framework you can never get it out. From then on you are limited to 5C-compliant devices. That new video-enabled cell phone might not be a 5C-compliant device. It might use a different method to protect that data. This method might also be acceptable. However, much like the different audio-protection schemas out there (AAC, WMA, etc), transferring from one camp to another is often a process fraught with frustration and futility.
This will be the case with all methods of distribution protection. Unfortunately, it’s nearly impossible to protect content without limiting it. Therein lies the crux of the problem and the meat behind most people’s complaints.
At this point you might be thinking “So, he’s locked up our data and foisted unnecessary copy-protections upon us. Why, again, isn’t he the devil?” Hmmm. At this point in the column I’m starting to wonder the same thing.
The answer is that many people have come to use the term Broadcast Flag as a generic term. It’s important to remember that the July 1 deadline only really deals with over-the-air digital television. Below are some common questions:
Q: I have a PVR from my cable company. Does the broadcast flag mean that I can’t time shift my content?
A: No, the only purpose of the Broadcast Flag is to limit mass-distribution of content. Unlike other types of conditional-access systems there is no provision to limit how the content is used. For instance, there is nothing in the broadcast flag that limits copying locally. Likewise there is nothing that expires content making it unwatchable after a set time.
Q: Recently HBO began encrypting its shows and now Microsoft’s Media Center Edition (MCE) won’t let me copy them with impunity. Surely, I can blame the Broadcast Flag for this, right?
A: Again, no. First, you’re referring to the recent inclusion of CGMS-A. As the A indicates this is an analog technology. While CGMS-A has similar concepts (e.g. terms like copy-never), it isn’t the same thing. The Broadcast Flag in question is a) purely for digital content and b) only intended to regulate content that’s sent OTA (or retransmitted versions of that signal).
Q: Is it true that the Broadcast Flag is the reason that neither TiVo nor MCE work with high-definition cable?
A: Once again, no. Both TiVo and MCE have only tackled OTA HDTV because, unlike a standard TiVo which encodes the analog signal, an analog HDTV signal is way too big to encode at a cost-effective price. The recent roll-out of Digital Cable Ready (DCR) support by the cable companies should mean an acceptable path for stand-alone HD TiVos.
Those are just a few of the questions that unfairly get tied to the Broadcast Flag.
For feedback or column suggestions email theclicker@theevilempire.com. Until next week – save my seat!