Sparring via FCC filings

On August 24, 2007 TiVo made a filing with the FCC in which they argue that OCAP, or the OpenCable Platform, is unsuitable for 3rd party bidirectional digital cable consumer electronics devices, such as a possible future TiVo. TiVo feels that the current OCAP specifications need significant changes to be suitable for a CE device, and that given the choice between the current OCAP specs and the CEA’s counter-proposal of DCR+, TiVo would have to back DCR+. However, the most interesting part of their filing, at least to me, is TiVo’s proposal for an interim standard that would be based off of Home Media Engine (starting on page 24). I’ve reformatted it slightly for the web – removed the page breaks and moved all the footnotes to the end of the quote:

V. TIVO PROPOSES AN INTERIM TWO-WAY SOLUTION THAT WILL BRING TO CONSUMERS THE BENEFITS OF COMPETITION WITHOUT FURTHER DELAY

Given the choice between the current OCAP regime proposed by NCTA and CEA’s November 7th proposal, TiVo has to support the CEA proposal since, as explained above, the current OCAP regime simply does not allow TiVo to build a competitive bidirectional product. As explained above, the current OCAP regime is no choice at all since the technical provisions of OCAP and the additional terms that are in effect via CableLabs licensing agreements prevent TiVo from dictating the design and functionality of its product. Although the purity of its offering may suffer to some extent, however, TiVo believes that some concessions may be necessary for consumers to realize the benefits of competition as promised by Section 629 in the near term, which in turn will promote the sale of digital cable ready devices and the DTV transition. TiVo thus proposes an interim solution below that reflects a compromise that would assure that all parties’ interests are adequately met in today’s market.

TiVo has created an efficient network-based client-server protocol using open standards for hosted applications. This protocol, which TiVo calls the Home Media Engine (“HME”) protocol, supports efficient rendering of modern multimedia user interfaces on remote devices, reporting remote control and other events back to a server running an application.40 The HME protocol is efficient, agile, thin and scalable. While HME was designed for graphics-rich multimedia applications served over unmanaged IP networks, the protocol will operate over any suitable network transport interface, such as bi-directional CableCARD. Applications can be quickly modified, upgraded and tested on the server without changing the code on the client (i.e., set-top box). Client requirements are minimal, simply displaying text, pictures, audio, video and graphical elements as dictated by the server application. Perhaps most importantly, TiVo already uses HME servers today to support millions of HME clients.41

TiVo believes that competitive CE manufacturers should be permitted to build non-OCAP bidirectional boxes that receive all programming channels offered by MSOs provided on a per channel basis and include a presentation engine such as HME that allows individual MSOs to run their proprietary bidirectional applications — such as VOD and PPV — remotely on their servers. Such two-way applications could be invoked on the competitive box through its native user interface.42 In this way, each MSO could control the presentation of their bidirectional applications without having to redesign the cable architecture and without needing the competitive set-top box manufacturer to do any development work. Under this proposal, cable operators can use OCAP for their leased boxes if they so desire; however, CE manufacturers’ devices can but need not run OCAP. This solution is both quick and fair — it can be deployed by February 2009 transition date; it addresses the cable industry’s concern about controlling the presentation of their proprietary bidirectional applications such as VOD and PPV; and it lets MSOs run their own applications without interfering with CE manufacturers ability to design competitive navigation devices. Such a solution would ensure that consumers finally are able to benefit from competition and innovation in the market for navigation devices as intended by Section 629. Were the Commission to favor this proposal, TiVo would promptly work with appropriate standards bodies to evolve HME into a suitable industry standard for creating such applications.

This proposed solution is “interim” because it would not result in retail boxes that support all interactive operator services. A fully-functional bidirectional retail set-top box would either require substantial modifications to OCAP and its licensing regime, or implementation of the CEA proposal. While TiVo wishes to create such a fully-functional bidirectional box in the future, we recognize that neither of these approaches would yield a retail device that could be deployed by Christmas 2009, much less the February 2009 transition date.

40 An early reference implementation of the TiVo HME protocol was released as open source in 2005, and can be found at http://tivohme.sourceforge.net. TiVo has been evolving and enhancing the protocol and its supporting toolsets internally since that time, using it to deploy an increasing number of production applications.

41 TiVo uses HME technology today for, among other things, its Swivel search feature, Fandango, Live 365, Podcaster, Yahoo! Photos, and Yahoo! Weather applications, as well as to present the TiVo user interface on Comcast’s leased DVR set-top boxes in the soon-to-be released Comcast-TiVo DVR service.

42 In order to keep their product(s) competitive, the competitive set-top supplier should have every incentive to ensure that entry to server-based services is easy and works well. Similarly, MSOs should have every incentive to ensure that the applications work well, as they derive revenue from these services and they are clearly elements of the cable service.

I think that is a very interesting proposal. (Aside: Did you notice ‘video’ in the list of things clients would support in HME? I’d love to see the public HME framework updated with that.) Cable MSOs could even run their OCAP applications on a central server in a kind of HME wrapper for display on the consumer device. I wonder if TiVo has considered taking HME to a standards body independent of this, to establish an industry standard way of accessing interactive services. It could help stimulate development if there were more device support.

Anyway, the gist of TiVo’s filing is asking the FCC to step in and settle the issue of two-way access once and for all. The fight between the cable industry and the CE industry has been going on for over four years and shows no sign of being settled. It looks intractable at this point, and the best hope for some solution is for the FCC to step in and force the issue.

On September 10, 2007 the National Cable & Telecommunications Association (NCTA) responded to TiVo, and the CEA in general with with own filing. It is more of the same from them – the only possible solution is OCAP, everything else simply cannot work. I don’t know, but every time I read one of the NCTA’s filings it seems like they’re not interested in finding a compromise. OCAP is just fine as is, despite what anyone may say. While they’re happy to point of flaws or missing pieces in the CEA’s DCR+ proposal, it seems to me that it would be more constructive to perhaps suggest changes or additions to the proposal to correct those issues. The CE side has made suggestions for changes to OCAP in the past.

And sometimes it seems like the NCTA just isn’t paying attention, or that they see and hear what they want to and not what is really said. For example, take this from page 25:

Likewise, TiVo’s suggested “compromise” is that each cable operator re-write its applications into a special format custom-designed to run on TiVo devices. Although apparently intended as some type of concession that cable consumers have a right to receive a cable operator’s services as they are provided by the cable operator, as a practical matter the proposal would create for TiVo a needless and redundant quasi-OpenCable Platform at cable’s expense. Instead of TiVo simply adding the OpenCable Platform to its device, every cable operator would have to duplicate all applications in yet another format, and build infrastructure to support this new application format. Other CE manufacturers might then demand similar accommodation, leading to even more duplication. Consumers would not be well-served by such an inefficient use of resources.

Read TiVo’s proposal above. Especially this bit:Were the Commission to favor this proposal, TiVo would promptly work with appropriate standards bodies to evolve HME into a suitable industry standard for creating such applications. I guess the NCTA just managed to overlook that. TiVo is not proposing that the cable industry write something just for HME, but that HME could be used as a starting point for an industry standard available to all vendors.

The NCTA filing also includes their point-by-point rebuttal of TiVo’s claims, starting on page 14. It looks like some of their responses are OK, but some of them seem to me to be either mis-interpreting, or spinning, TiVo’s statements so that the response makes OCAP look better.

I also have issues with some of their fundamental claims throughout the document. The biggest problem I have is their shrill objection to the possibility of any ‘secret’ information being leaked about how the systems work. In other words, security through obscurity. Which, as someone who has done professional network security work, drives me up a wall. It is as wrongheaded as you can get, security through obscurity is almost worse than no security, because all it takes is one leak and any supposed security is gone. And no matter what you do, leaks will happen – period. I’ll give you a prime example of security through obscurity – CSS encryption on DVDs. One leak is all it took to destroy copy protection on DVDs, now ripping them is trivial.

It is as stupid as you can get, and the NCTA seems paranoid about any of their ‘secrets’ getting out. You know what? If you have to worry about the secrets to your security implementation getting out, then it is a bad implementation. Period. If you have a good implementation then the only thing you should need to protect are the keys/passwords/tokens/whatever key unlocks the lock. You should be able to publish every detail of your lock/algorithm/system openly (as is done with public security standards such as AES) and not worry, because it is designed so well that knowing how it works doesn’t help attackers. The only reason to worry is if you have weak points in the design – and that means you should fix the design, not hide the weaknesses and hope no one ever finds out.

They also use arguments that do not hold up logically:

TiVo’s comments catalogue supposed deficiencies in the OpenCable Platform to support its claim that OpenCable is not practical for retail devices. Of course, the support of OpenCable by Samsung, Panasonic, and LG disproves that thesis.

Actually, no, it doesn’t. Something being possible does not necessarily mean it follows that it is practical. And even if something is practical for a relatively simple device like a TV, which only needs limited bi-directional support and doesn’t have a rich, complex native UI – and so OCAP applications don’t break a design theme, etc – doesn’t make them practical for a more complex device such as TiVo.

You know, honestly, I actually think that, at the fundamental level, the concept of OCAP is fine. I even think that a lot of the details of OCAP are fine. But I do agree with TiVo and the CEA that some of the restrictions and requirements of OCAP are excessive and restrictive. And that the inflexibility and lack of UI control is a serious, show-stopping issue for CE vendors like TiVo. I also know, without a doubt, that it would be possible to define standardized interfaces to access these services. They could even use OCAP middleware on the box to present the interfaces, to act as a translation layer between the various cable back ends and the CE devices. The need to handle these various back ends is one of the major arguments the NCTA makes in favor of OCAP – but they take it further into saying the MSO needs to control the interface. That’s just not true.

There are already precedents for flexible, dynamic, data-driven UIs and services. XML and SOAP are good examples of formats and frameworks that could be used, or just the concepts. How many modern applications are ‘skin-able’ – such as WinAmp, Firefox, etc. They use standard interfaces to the underlying data structures to connect with different UIs. There is no reason a standard data format could not be defined for CE devices to order VOD & PPV, or to tune SDV channels. Funnel it through OCAP middleware – which could run in the CE device, or even on a central server at the MSO – to handle interfacing with the legacy back end.

Does this mean that consumers could see different UIs and even have different availability of services on different devices in one home? Yes, of course – but so what? We already have different UIs and services on different devices – this issue is a complete red herring from the NCTA. They make it sound like it is a terrible thing for the consumer. Hell, right now I have a TiVo Series2 fed directly with cable, so it only gets analog cable services. I have an other Series2 with a cable box, so it gets analog and digital cable, and has some abilities, via the box, for VOD/PPV. And I have a Series3 with CableCARD which has analog and digital cable, with high-def, but no VOD/PPV access. We consumers already deal with different services on different devices, it isn’t a big deal. And if one CE vendors offers access to a richer palette of cable services than another, than that’s a competitive advantage. As it should be.

I think the FCC needs to step in. I don’t know that the CEA’s DCR+ proposal is really the right solution, in fact I think it has a number of serious issues in its current state that make it a poor solution. But the FCC could mandate changes to OCAP to address the major concerns from CE vendors such as TiVo. Or a compromise solution could be worked out – a little from one, a little from the other. But whatever approach is taken, the fight has gone on for too long already and if the kids can’t play nicely then they need to go to opposite corners for a time out while the adults make the decisions.

About MegaZone

MegaZone is the Editor of Gizmo Lovers and the chief contributor. He's been online since 1989 and active in several generations of 'social media' - mailing lists, USENet groups, web forums, and since 2003, blogging.    MegaZone has a presence on several social platforms: Google+ / Facebook / Twitter / LinkedIn / LiveJournal / Web.    You can also follow Gizmo Lovers on other sites: Blog / Google+ / Facebook / Twitter.
This entry was posted in OCAP, TiVo. Bookmark the permalink.
  • http://hdtivo.wordpress.com/ HDTiVo

    The FCC definitely does need to step in. That process is in the early stages now. Cable will say NO until no becomes a problem or threat to them, which only the FCC can create.

    Your last 4 paragraphs really hit the mark on the overall issue. However, TiVo is now the camel trying to put its nose under the tent.

    TiVo’s proposal is a complete joke. Suddenly TiVo should become the maker of Windows for the STB. :o y:

    Using HME is as absurd as the excessive OCAP demands. As you point out with the examples of other standards, a much simpler universal system could be adopted.

    TiVo’s audacity is amazing. Perhaps they didn’t intend a serious proposal but merely an illustration. For credibility I hope that is it.

  • http://www.gizmolovers.com/ megazone

    Actually, based on the technology, I don’t think TiVo’s proposal is a joke at all. In fact, I think it is a pretty solid compromise.

    The CE vendors object to OCAP because of the heavy burden it places on them – it turns the set top boxes into ‘fat clients’ which have to do some heavy lifting to host the OCAP platform. It also forces design choices by requiring special buttons on the remote, etc.

    Conversely, the cable industry objects to DCR+ or any SOAP-style interface because it puts all the onus on them to develop and deploy new server-side software that does all the heavy lifting but leaves all of the display choices up to the CE vendors.

    HME is in the middle – the server does more of the work, but since it is Java based it could even be evolved directly from OCAP software. It could be possible to develop OCAP software that can run on ‘fat client’ boxes *or* on a server OCAP platform, producing a variation on the UI for HME. Keep in mind that the entire OCAP TiVo port for Comcast and Cox was developed using the HME toolkit. You can produce a sophisticated UI using TiVo’s internal HME kit – it is much more evolved than the public kit. (Which is another issue entirely.)

    This allows CE vendors to have fairly ‘thin’ clients, while giving the cable vendors more control over the applications and presentation.

    It is a lot like the X Windows system from UNIX/Linux in functionality. It may even be preferable for some CE vendors as both DCR+ and OCAP require more work on the part of the CE platform.

    And I stress again that TiVo is not proposing that HME be the protocol, but that it can server as the basis for a protocol. The final protocol could, and probably would, see many changes. And it would be standardized outside of TiVos control – which could actually be a good thing in and of itself.

    But it is DOA unless TiVo gets support from other industry players.

  • http://hdtivo.wordpress.com/ HDTiVo

    As long as its illustrative of a concept its OK.

    Would you expect that the communication would occur only over the coax to/from the cable head end, rather than over ethernet/internet? I figure cable would want that over their “closed” network.

  • http://www.gizmolovers.com/ megazone

    Technically it could be either – I’d expect it to be over TLS/SSL if it were over the public network. Probably using certs for authentication for added protection. But insisting on using the private network seems like something the cable MSOs would want.