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

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 08 Mar 2012 15:25:18 +0100
To: public-html@w3.org
Message-ID: <op.wauvog0rsr6mfa@kirk>
On Tue, 06 Mar 2012 18:43:46 +0100, Christian Kaiser <kaiserc@google.com>  

> On Tue, Mar 6, 2012 at 02:04, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Mon, 05 Mar 2012 20:57:23 +0100, Christian Kaiser  
>> <kaiserc@google.com>
>> wrote:
>>  On Mon, Mar 5, 2012 at 08:48, Tab Atkins Jr. <jackalmage@gmail.com>
>>> wrote:
>>>  Engineers are generally unable to come up with innovative approaches
>>>> when their hands are tied by contracts and anti-circumvention laws.
>>> True in some cases. They also can't innovate if the barrier to entry is
>>> too
>>> high. Lowering the barrier to entry is one of the IMHO positive side
>>> effects of the proposal at hand.
>> If we're talking about innovation within and entry to the browser  
>> market,
>> this doesn't make sense.
> As previously mentioned, the proposal enables innovation through
> competition *between content distributors*, which in turn is enabled by
> lowering the barriers to entry.
> Content distributors' interests are closely aligned with users' interests
> since more convenient and full-featured distribution services will win  
> in a
> competitive landscape. (Of course, this only holds water if you think  
> that
> users should be able to choose for themselves.)
> In addition to that, content distributors are motivated to keep the cost  
> of
> content protection low (since they're probably carrying some of their
> costs), and are therefore seeking simple, cheap and standardized  
> solutions.
> The concepts of "open source" and "royalty free" are compatible with  
> these
> motivations.
> So I would claim that lowering the barriers to entry for content
> distributors and aligning with their needs is positive for users and for
> the web.

Thanks for clarifying that it is not browser innovation and competition  
that this is enabling.

I must ask, though, if the sponsors of this proposal truly believe that  
the outcome of this will be a royalty-free CDM that can be implemented on  
any platform, why bother with the intermediary steps?

> 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. The hurdles to pass to allow plugging in CDMs seem pretty
> similar to the hurdles to pass to allow plugging in Flash or Silverlight.

There's a huge difference in that we know what the current de facto  
standard plug-ins are, but don't know what the de facto standard CDMs will  
be or who will control them. As I have stated repeatedly, it would help  
immensely to evaluate the risks if the details of the CDMs intended for  
production use were publicly disclosed. Discussion without the full  
information is frustrating for all parties.

>> The proposal at hand requires a few proprietary and/or  
>> royalty-encumbered
>> de facto standard CDMs to emerge,
> 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.

There's no need to enable innovation in CDMs that can be implemented  
royalty-free on any platform, as such CDMs cannot keep the data out of the  
hands of the user and are thus no more effective than the Clear Key CDM or  
http+aes. In other words, the only point of a CDM plug-in system is to  
enable proprietary and/or royalty-encumbered CDMs.

>> which can do nothing but *raise* the barriers of entry. Because browsers
>> cannot have full control over the CDMs, it will also limit their  
>> ability to
>> fix bugs, optimize and to innovate -- e.g. one couldn't add
>> brightness/contrast controls because the video decoder output is not
>> available.
> I don't think that the proposal at hand doesn't allow video decoder  
> output
> to be available. You're making an assumption here.

Quoting the proposal: [1]

"Can a user agent protect the rendering path or protect the uncompressed  
content after decoding?

Yes, a user agent could use platform-specific capabilities to protect the  
rendering path."

What is this, if not a CDM that controls both the video decoder and its  
output? It's enough that one such CDM becomes widely used for overlays to  
become a required part of the platform, with the negative effects that I  
have described.


Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 8 March 2012 14:25:44 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC