W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Mark Watson <watsonm@netflix.com>
Date: Mon, 27 Feb 2012 23:45:41 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <4A3A017F-7C80-4C0A-96DF-B301FEB2ECAF@netflix.com>

On Feb 27, 2012, at 2:46 PM, Boris Zbarsky wrote:

On 2/27/12 5:35 PM, Mark Watson wrote:
Maybe technically, in principle, yes. But the Adobe web site lists specific versions of desktop browsers for specific platforms that are "supported" and specific devices that are "certified". And it isn't supported unless it's tested. Even if the full Flash test suite was available from Adobe then a new browser maker would still need to work with Adobe to fix any bugs and get onto their "supported" or "certified" list.

That's true, but being on that list is not a prerequisite for actually having a working Flash...

Some would say if it's not properly tested it's not "working" ;-)

I'm not familiar with the OS integration that Flash or SIlverlight use, if any, to support their content protection capabilities, but it's possible that being on the supported list is a prerequisite for content protection capabilities working - or being certified as working according to the plugin vendor.


My (albeit limited) experience with NPAPI suggests that just implementing from the specification probably isn't enough to have something as complex as Flash "just work".

That's almost certainly true; there are some edge cases that might be underdocumented.

But again, there are no legal restrictions preventing someone from looking at one of the two existing open-source codebases that have an NPAPI implementation that works with Flash and adjusting their implementation accordingly.

With our proposal, the new browser would need instead to support one or more Content Decryption Modules.

Right; the question is what that would actually entail.

This is a much simpler task over which the new browser developer has greater control and more options.

That's not obvious a priori.  I'd love to understand why this is the case.

It's simpler because the functionality in a CDM is a very small subset of the functionality in a plugin like Flash or Silverlight.

Unless I'm missing something, implementing a CDM without explicit permission from whoever controls it is likely to fall afoul of the anti-circumvention provisions of the DMCA, at least in the United States.  _Am_ I missing something?

I mean that browser integration with a CDM is easier than browser integration with a full-fledged plugin, because the functionality of the CDM is so much more constrained.

Implementing a CDM is a different matter.


The engineering costs to create and maintain a CDM is much less than the engineering effort to create and maintain a full-featured plugin like Flash or Silverlight.

Implementing the browser side of NPAPI is nothing like creating or maintaining Flash or Silverlight.

My mistake. What I said about creating a CDM vs creating Flash wasn't relevant (although it was true).

I meant that the costs to integrate with Flash or Silverlight (implementing NPAPI and working with Adobe/Microsoft on testing etc.) are higher than the costs to integrate with a CDM, again because the CDM is so much simpler, the API so much simpler, and there would be so many fewer test cases.


The licensing issues are no worse

I don't see why.  I'd love to understand that.

Again, compare integrating with a commercial CDM to integrating with Flash or Silverlight. Flash and Silverlight are a superset of the functionality of a CDM, so any licensing issues associated with the integration or shipping are no worse.


Companies interested in commercial video services might be motivated to create and distribute CDMs when they would not be interested in creating and distributing full-fledged plugins.

No one is asking them to create and distribute such plug-ins; the plug-ins are already there.

I feel like we're talking past each other here....

These are obviously fairly general statements - the proposal doesn't prescribe a model for where CDMs will come from and we appreciate opinions and ideas on that topic.

OK, let's try a concrete example.

Assume this system is implemented and working as desired.

What does a new browser codebase on Windows, say, have to do to end up being able to watch video provided by commercial video services?

The browser needs to define an API for integrating with CDMs (just as they do for plugins). A CDM supported by the commercial video service in question needs to be present on the users machine. There are many ways it could get there, including being shipped with the browser.


How does the answer change if the operating system is Linux?  How does it change if it's a new operating system?  How does it change if it's a new hardware architecture?

I don't think the above changes - mainly because I didn't answer how the CDM gets onto the users machine, which is because we don't prescribe a single approach to that. I don't want to list all the ways I can think of that the CDMs could get installed, because that is more of a commercial than a technical issue. Also because I'm sure my list is not exhaustive and that companies with an interest in this topic will be able to come up with innovative solutions, if the technical framework is there.

...Mark


I realize that even existing use of Flash is a problem in those last three cases, of course, but I'm worried about even the first case here.  Again, I am not a lawyer, all the standard disclaimers.

-Boris
Received on Monday, 27 February 2012 23:46:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC