A few years ago, I lived in Cambridge, Massachusetts. With my trusty Hauppauge WinTV-PVR-150 I enjoyed the ability to watch and record Comcast TV on my desktop computer — and even to occasionally edit and re-upload it to YouTube along with fair use critical commentary. When I moved across the river to Boston, Comcast required me to pay for a set-top box that would tune channels on my television. However, when I plugged my PVR-150 into the cable connection, it got almost no channels at all. As it turns out, the Comcast system in Boston had been migrated to use mostly digital signals, but my tuner card worked only with analog cable signals. Fair enough, I thought, I’ll buy a digital cable tuner. As it turned out, that wouldn’t help much. The cable companies had implemented encryption to fight “service theft” of most channels that subscribers had not paid for. As a result, I lost the ability to view channels I had paid for on a device of my choosing.
The FCC saw this problem on the horizon all the way back in 1996, when it included requirements for compatibility of consumer-provided “navigation devices” in the 1996 Telecommunications Act. The FCC ultimately settled on a solution called CableCard, which specified a universal standard for a small device that would perform the decryption and tuning functions of a full set-top-box, but in a form factor that could be inserted into third-party “host” devices. The problems with CableCard have been many-fold. To begin with, the long process of implementation (both technically and politically) failed to facilitate a competitive market for devices that are a viable alternative to set-top-boxes provided by the cable companies. Second, the functionality of CableCard was outdated almost as soon as it was designed. For instance, it did not anticipate two-way interactive services, program guides, or video-on-demand. Third, the standard mandated particular hardware, which contributed to the implementation delays and difficulties. Finally, and perhaps most problematic for the standard, all devices that wish to be CableCard “host” devices must first pass certification by the cableco-surrogate organization CableLabs. This means that cable companies still hold de facto control over the market.
The FCC has struggled with how to address these problems. In 2007, it realized that the industry players were not going to update CableCard to support two-way interactions, and issued rules intended to force it to do so. This ushered in the “true2way” standard at the heart of what was commonly referred to as “CableCard 2.0.” It also ushered in yet another certification regime. This time, CableLabs imposed an even greater degree of restriction on the design of third-party devices, insisting that the manufacturers surrender control of major portions of the user interface to their own restrictive “middleware”. This undermined one of the competitive advantages of these devices (better user interface), and mired their developers in the process of trying to comply with these arbitrary “compatibility” requirements. Although several consumer electronics vendors initially indicated their plans to support the standard, the last major vendor aborted its plans in 2010.
The next stage of this battle began when public interest groups filed a petition in 2010 asking for several fixes to the system, including ways to encourage the anemic third-party “smart video devices” market. Consumer electronics manufacturers supported this effort, and TiVo sent a letter explaining the various ways in which CableCard through its various instantiations had failed to facilitate a competitive market (reversing decades of a vibrant market for VCRs and other “cable ready” devices). The Commission released a Notice of Inquiry (NOI) (see the docket here) asking several questions about a possible new approach to the CableCard issue, which would ideally resolve some of the regime’s existing shortcomings. At the center of the FCC’s NOI was the notion of an “AllVid” standard that defines a single set of protocols that a video provider’s equipment must support so that other devices can both control tuning/interaction/etc and receive a video stream for display. The NOI then noted that the FCC may suggest Ethernet as the universal port, IP as the base protocol, and DTCP-IP (“Digital Transmission Content Protection over IP”) for encryption. Of course, this depends on “smart video devices” being able to receive and decrypt the digital video signal coming from one of these devices. The CableCard experience demonstrated that industry-based standards groups tend to use certification and encryption to restrict competitive consumer devices from displaying and recording content. In that sense, the Commission’s suggestion that the new adapters use DTCP-IP (and public interest groups’ surprising endorsement of this approach) represented more of the same. The DTCP-IP specification and licensing is closely held by the five corporations that developed it, and they only license the technology to implementers who pledge to restrict what end-users can do with the video.
The AllVid proceeding has not progressed. In the meantime, the FCC received a petition from cable companies that asked permission for them to encrypt the last bastion of unencrypted digital cable — “basic service” cable. The FCC has always required cable companies to continue providing this service in an unencrypted format because of the historical connection to “free and open” over-the-air broadcast. As a result, a small market for non-CableCard set-top-boxes that receive these “basic service” channels has been able to survive (in a bizarre twist, because they are not CableLabs-certified, they can record many of these unencrypted digital cable channels that third-party CableLabs-certified devices cannot). This ability to receive “basic tier” programming was likely to end if the FCC goes along with the cable companies’ petition. That possibility upset the startup company Boxee, whose users rely on this functionality in their Boxee set-top-boxes. Nevertheless, we learned last week that Boxee and Comcast sat down together and hashed out a workaround that they were both happy with. Here is what they claim to have come up with:
The initial solution involves the development as soon as possible of a high-definition digital transport adapter with an ethernet connector (“E-DTA”). This solution would enable a customer with a third-party device to access basic tier channels directly through an ethernet input on such third-party device or via the home network, and to change channels remotely in the E-DTA via a DLNA protocol.
The long-term solution, which would follow shortly after the initial solution, involves the creation of a licensing path for integrating DTA technology into third-party devices (“Integrated DTA”). Such a device could access encrypted basic tier channels without the need for a cable operator-supplied DTA or set-top box.
What do folks think of this approach?