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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 27 Feb 2012 21:34:09 -0500
Message-ID: <4F4C3D21.6020703@mit.edu>
To: Mark Watson <watsonm@netflix.com>
CC: "<public-html@w3.org>" <public-html@w3.org>
On 2/27/12 6:45 PM, Mark Watson wrote:
> Some would say if it's not properly tested it's not "working" ;-)

Who said it's not properly tested?  There's a difference between "not 
tested" and "not tested by Adobe".

But this is incidental.

> 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.

That's a good question.  If that's the case, I'd love to hear about it.

>> 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.

Assuming there's an actual published standard for integrating with CDMs, 
sure.

> /Implementing/ a CDM is a different matter.

I strongly suspect that's what minority browsers will have to end up 
doing in practice in order to not be locked out of content.  That's 
certainly how things have worked historically...

> 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

Well, I'd hope it's simpler.  It's not defined so far.

> 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.

As far as I know, the API between Flash and Firefox does not entail 
anything whose implementation on the browser side would be covered by 
the anti-circumvention provisions of the DMCA.

Again, I have no such faith in the interaction between browsers or CDMs 
so far.  If it turns out this is the case, great.  I'd need to see a 
competent legal analysis of a specific proposed API here, I suspect....

>> 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.

OK.  And CDMs could require running in a particular browser, yes?  Is 
this likely to be a common requirement on the part of CDMs?

>> 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.

Which is actually the other part of my concern.  In my ideal world, 
creating new platforms that can browse the web would be "cheap" in the 
sense of not entailing more than the technical work of creating the 
platform.  That would encourage competition and lead to a better user 
experience.  If browsing the web, in the sense that most people 
understand it, requires having particular binary blobs running on your 
web-browsing hardware, though, that raises pretty significant barriers 
to entry for new platforms.

We have such barriers to entry to some extent now, with Flash (and 
Silverlight, and to some extent Java), but I think we should be reducing 
such barriers, not enshrining them in the web platform.

What I'm not seeing, yet, is a way to reconcile all this with the goals 
of this proposal.  :(

-Boris
Received on Tuesday, 28 February 2012 02:34:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT