Teaching the FCC to Think Outside the Box

Much to the dismay of the FCC, Comcast announced a deal with Samsung, Roku, and others to be named later that will allow consumers to eliminate cable boxes. The technology consists of Comcast-written Xfinity apps for the Samsung and Roku platforms developed in collaboration with engineers from the two other companies. At a high level, the Xfinity app handles authentication and authorization on its own, and uses an API supplied by the TV folks to put pictures on the screen and sound in the speakers.

You Can’t Unlock a Box that Doesn’t Exist

One nice twist is that getting rid of your Comcast box doesn’t leave you without a DVR; Xfinity customers can use a cloud-based DVR supplied by Comcast. This is a for-fee service, but it doesn’t require leasing any hardware from Comcast. In addition to the Comcast DVR, there are apparently some limited DVR capabilities in the Roku box as well.

Contrary to appearances, this announcement isn’t a reaction to the FCC’s Notice of Proposed Rulemaking on opening up cable boxes to middlemen. The collaboration has been underway for a year or more. Something like this doesn’t simply come about overnight.

The approach Comcast and partners took in developing this app is based in the proposal that Comcast made to the DSTAC. This approach was rejected by the FCC in favor a proposal by Public Knowledge requiring (for all practical purposes) the ongoing presence of cable boxes in order to relieve innovators from the drudgery of too much engineering work.

Comcast Follows its DSTAC Proposal

The rejected DSTAC proposal relies on HTML5, a standard devised by the W3C, the principal standards body that extends and enhances the technical foundation of the web. Its main elements are described in the DSTAC report on page 3:

The WG3 (Working Group 3) HTML5 Security APIs proposal recommends that MVPD/OVDs (online video distributor5) and CE/CPE (customer premise equipment) companies adopt the security APIs in HTML5 as a non-exclusive security system interface between MVPD/OVD services and consumer electronic devices. According to its proponents, this proposal has the following characteristics:

HTML5 is the new standard defined in 2014 by the World Wide Web Consortium (W3C) as a common and open approach to deliver IP streaming media based on Internet protocols. HTML5 is a full application foundation, supporting both security elements and non-security elements. HTML5 and its Encrypted Media Extensions (EME), Media Source Extensions (MSE) and Web Cryptography (WebCrypto) extensions are being deployed across the Web today by multiple vendors on hundreds of millions of devices, and are widely supported by all major browsers.

The EME extension defines standard APIs (software programming interfaces) that permit HTML5 to support media under common encryption6, even while protected by a variety of DRMs. EME operates as a bridge that permits competing DRM security systems to operate on a variety of platforms, including platforms that offer hardware roots of trust7 and platforms that do not. EME enables device manufacturers and service providers to choose from a competitive market of commercial content protection technologies and enables security systems to advance ahead of, or in response to, the growing sophistication of attacks. By not mandating a single security system, it avoids creating a single point of attack for hackers.

The Alternate DSTAC Proposal is Vaporware

By contrast, the Public Knowledge proposal (AKA “Virtual Headend”) relies on standards that don’t actually exist yet, but which may come about at some future time (DSTAC report at page 4):

An MVPD may choose a system architecture for a Virtual Headend System that includes a device located at a consumer’s home, which provides a “local cloud” which has security system components downloaded to it as necessary, or the entire solution may be in their network “cloud” and offered as IP services directly to devices in the home. Because the interface to the home network (and retail devices) is standardized across MVPDs at the link protection, this enables nationally portable retail navigation devices.

Current efforts from MVPDs are cited as demonstrating that operators are working towards Virtual Headend System technology that defines a new set of interfaces to legacy network systems under a common set of IP network protocols, served from devices in the home or from the MVPD’s cloud that can serve a variety of navigation devices. Proponents have indicated that an existing link protection mechanism such as DTCP-IP would need to be modified to protect certain kinds of content (such as 4K) and for cloud-to-ground delivery.

So not only is the Comcast/HTML5 approach based on actual standards, it’s implementable today, obviously. The Public Knowledge/Virtual Headend approach is speculative, to be charitable, and there’s no reference implementation to prove its viability. The FCC’s preference for the PK white elephant is puzzling.

Public Knowledge Threatens Artists

PK’s best defense of their plan is a blog post by one of the company’s lawyers, Kate Forscey. It’s the kind of blog post that tries to make a case with sarcasm that can’t really be made with substance:

But let’s get real. This isn’t really about pirating cable over the box. It’s just a rerun of the same Hollywood complaint that applies to any computer, or your Roku or Apple TV, smartphone – flatly, anything that exists today that can connect to the internet and has search functionality. Opposing a competitive set-top proposal because you’re worried the internet more generally facilitates pirating makes about as much sense as opposing a competitive automobile marketplace because bank robbers sometimes use roads to flee the scene of the crime. It’s non sequiter [sic] at its highest.

We’ve seen this from Hollywood before, in 2011 and 2012 during their support of SOPA and PIPA laws which targeted internet technology out of the same fear of piracy. The end result was online protests from millions of Americans. Thankfully, Congress pulled itself back from harmful action before it was too late.

Forscey admits that the PK proposal doesn’t satisfy the obligations that MVPDs have to content creators, but insists that these binding legal obligations are unimportant. In defense of a plan that essentially invites consumers to pirate video programs, she offers a threat:

But should you get what you want, a reversion to an incumbent-controlled video model on anachronistic, closed devices, I get the feeling you’re likely to see a whole lot more unlawful viewership, not less. So it’s “do it my way or we’ll steal all your stuff anyway.”

The FCC’s Feelings are Hurt

Somehow the FCC went along with this plan. In a press statement following the announcement by Comcast, Samsung, and Roku, the agency expressed some hurt feelings:

While we do not know all of the details of this announcement, it appears to offer only a proprietary, Comcast-controlled user interface and seems to allow only Comcast content on different devices, rather than allowing those devices to integrate or search across Comcast content as well as other content consumers subscribe to [sic].

The regulator’s complaint is somewhat bizarre. It’s not the least bit surprising that the Comcast app only streams Comcast content, so I fail to see how it could do anything other than “only [providing] Comcast content on different devices.” It’s not the only app that runs on the Samsung and Roku devices, so there’s no reason to expect it to be all things to all people.

The FCC’s deeper complaint concerns the program guide. When it bemoans a possible inability of users to “search across Comcast content as well as other content,” the regulator demands a machine-readable program guide. This probably reflects the mistaken belief that Comcast is actually the source of the raw data with which its program guide is made, and that without this data, device and application developers can’t possibly know when and where particular programs will be aired.

How Program Guides Come to Be

But this is a mistaken belief. The program guides presented to users by MVPDs are based on raw data about program times and channels obtained by the MVPDs from program guide specialists such as Tribune Media Services. The MVPDs get raw data from TMS, massage it, make it easy to access, and feed it their set top boxes and DVRs.

TiVo does exactly the same thing: Instead of getting program guides from the MVPDs, who are middlemen in TV distribution anyhow, TiVo gets the guide from TMS, who gets it from the TV broadcasting networks that actually have control over it. TiVo then combines its own program guide with information from other services such as Netflix, Amazon, and Hulu to make a searchable program guide that spans a great deal of the video marketplace, but certainly not all of it.

Demanding free access to a machine-readable program guide from the MVPD is essentially the same thing as requiring Google to provide its map of the Internet to Bing. And we know the FCC would never do such a thing, even if it weren’t blatantly unlawful to do so.

Is This a Conspiracy to make the FCC Look Bad?

The timing of the Comcast/Roku/Samsung announcement may be fortuitous, but it shouldn’t be paranoia-inducing. Other MVPDs have been working with Roku and the TV companies for quite some time, so this isn’t even the first example we’ve seen of successful collaboration. Time Warner Cable and Charter Cable are both running trials of just this kind of collaboration. So this is just Comcast catching up.

Let’s hope this announcement pierces the fog of nostalgia that engulfs the FCC these days and helps Chairman Wheeler and his right hand Gigi Sohn (founder of Public Knowledge) to see that the market has already far outpaced their “Unlock the Box” crusade.