Re: Encrypted Media proposal: Summary of the discussion so far

On Mar 6, 2012, at 10:58 PM, Henri Sivonen wrote:

> On Tue, Mar 6, 2012 at 7:43 PM, Christian Kaiser <kaiserc@google.com> wrote:
>> In the browser market, I'd argue that barriers to entry would stay the same
>> as they are today if one assumes that the proposal would result in a CDM
>> plug-in model.
> 
> So far, I haven't seen anyone step forward saying that they intend to
> produce a pluggable CDM if browsers were to provide an integration
> point.
> 
> On the other hand, there's no indication from browser vendors that
> also have DRM back ends in-house (Google, Microsoft, Apple) whether
> they'd provide support for pluggable CDMs in their browsers (as
> opposed to only integrating their in-house DRM without a public API).
> 
> Considering what's been said so far, pluggable CDMs might be a
> theoretical thing that no one intends to produce.

Considering that the proposal was made only two weeks ago, it's not surprising that we haven't heard about implementation plans yet. I anticipate that developing this specification will take some time. And during that time, people will have a chance to consider product plans. Your arguments above would be appropriate to consider at a later time when the specification is mature and proposed for elevation to some more formal status.

> 
>> The hurdles to pass to allow plugging in CDMs seem pretty
>> similar to the hurdles to pass to allow plugging in Flash or Silverlight.
> 
> Indeed, which makes me wonder why previous messages in threads on this
> topic have implied the integration of pluggable CDMs would be simpler
> than the integration of NPAPI plug-ins.

What may be different is that you don't have to get Microsoft of Adobe to support your platform. Content protection vendors commonly provide source code for integration of their technology onto devices. It's in their interest to get onto as many platforms as possible. The source of Flash or Silverlight is not available.

Again, if it became clear that availability of CDMs was going to be a big problem that would be an argument for not approving this specification once it is more mature.

The playing field for browsers is not at all level right now because Flash and Silverlight are not available on a huge range of devices that we would like to support the web.

> 
>> I disagree with this statement. The proposal at hand enables (but does not
>> require!) the use of proprietary and/or royalty-encumbered standard CDMs.
>> It also enables innovation to allow e.g. non-proprietary, non-encumbered
>> CDMs to potentially emerge.
> 
> It would seem healthier to the Web to propose a non-proprietary,
> non-encumbered CDM from the start instead of opening the door to
> proprietary and encumbered CDMs

You also asked this question in another mail, so I'll answer it once here.

It's clearly true that a non-proprietary non-encumbered CDM would be better than the proposal we made. Unfortunately, I don't know how to design one. My understanding is that this would be a job for a large team of patent lawyers, not a team of engineers. In practice it may take some of the IPR-holders in this space to offer RF terms to achieve this. I'd love to be proved wrong. If anyone has the necessary legal resources to look at this, that would be great.

I believe the proposal we made, creating a space for substitutable competing CDMs, makes it much more likely that a non-proprietary non-encumbered CDM could emerge, compared to the status quo where the technology is locked in a few plugins. Christian also made some good comments along these lines.

> 
> A non-encumbered CDM emerging later might help new Web sites later but
> it won't help browsers if by that time there's enough popular legacy
> sites that depend on encumbered CDMs.

As mentioned above, things are already bad for browsers, since they're reliant on Flash and Silverlight to access these web services and Flash and Silverlight are not universally supported.

...Mark

> 
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
> 
>

Received on Wednesday, 7 March 2012 17:35:43 UTC