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

On Feb 27, 2012, at 6:34 PM, Boris Zbarsky wrote:

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

That's an interesting point. It's definitely the intention that all the legal/IP issues are on the CDM side of the divide. Indeed that's the whole point of the CDM concept.

On the one hand, that could be an argument for defining that API more explicitly so that this topic can be subject to public review. On the other hand, browser developers might be more comfortable defining their own APIs that meet their own requirements in this respect.

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

If there is no common API, this is the situation by default.

If there is a common API, then I guess CDMs could place such restrictions, though I am not sure why they would ?

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

That just depends on whether you consider commercial video part of the "web". If you do, then this is the situation today: the 'binary blob' is Flash or Silverlight (or QuickTime, or a Netflix or YouTube native app, or ...).

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

Making the 'blobs' smaller with a well-defined and highly-constrained function should be an improvement. Making them go away altogether might be a bigger improvement by some measures but by others (range of content available) might be quite negative.

> 
> 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 04:01:52 UTC