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

On Tue, Mar 6, 2012 at 10:31, Kornel LesiƄski <kornel@geekhood.net> wrote:

> On Tue, 06 Mar 2012 17:43:46 -0000, Christian Kaiser <kaiserc@google.com>
> wrote:
>
>  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.
>>
>
> That sounds very reasonable, however in practice it may not turn out so
> well:
>
> - If closed CDMs become a de-facto requirement for web-compat, then
> open-endness and royalty-free status of the spec won't mean anything, as
> real-world use will require FOSS-incompatible components.
>

That would be a worst-case outcome.
I have faith (but obviously no guarantee) that content distributors will be
motivated to foster FOSS-compatible components if given an environment
where that's possible.

Consider a worst-case outcome on the other side.
Assume that demand for premium, high production value content remains high,
and business models for producers of such content do not significantly
change.
In this scenario:
- Content protection continues to be a requirement for content distributors.
- Since there is no way to satisfy these requirements within the framework
of open web technologies, premium content distribution stays on closed
proprietary frameworks.
- Therefore, the barrier to entry continues to be high for content
distributors, and after some time, only a small number of distributors
remain in the market.
- Every one of the content distributors has evolved their proprietary
technology for everything from UI to media playback, and some may even
offer closed playback devices.
- The web will matter less because a lot of users' time and money is spent
using these major content distributors (we assumed demand for high
production value content remains high)
- Since the competitive environment has become stable, innovation slows
down, and whatever user needs are not being satisfied may continue to not
be satisfied.

I'll leave it to you to judge
- whether that is indeed a possible outcome,
- if it is, how desirable or undesirable that outcome is, and
- how to trade that off against the worst-case outcome on the other side.

- Content owners could dictate certain limited set of CDMs to all
> distributors,


I don't see how content owners would be motivated to dictate CDMs. I would
assume they are motivated by having effective protection against revenue
loss, and care less about what the particular technology is.
However, content distributors in an environment of low competitive pressure
(see worst case outcome above) might be motivated to dictate CDMs because
switching costs are high, and platform lock-in is a viable strategy in such
a scenario.
The proposal, if implemented, lowers barriers to entry for content
distributors and might help avoid this scenario.


> and that would make differentiation in this area impossible. Currently
> e-book distributors have this problem: Adobe DRM is the only available
> option for newcomers, and it makes certain business models and innovations
> impossible (such as browser-based readers).


I'm not very familiar, but isn't the e-Book situation a result of some form
of proprietary platform lock-in, where the platform owner has no incentive
to support other mechanisms?
The proposal is trying to avoid this type of scenario on the web by
introducing well-defined interfaces and therefore substitutability for CDMs.


>  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.
>>
>
> Not quite, since CDMs add DMCA to the mix. Reliance on certain closed
> plug-ins has proven to be problematic (despite spec itself being free and
> open), so I think new specs should move away from this model, rather than
> repeat it.


I think Mark Watson's recent message about restrictive vs. expansive goals
treats this tension pretty well. Someone will need to make a decision which
goal to follow in this case.


>  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.
>>
>
> When important content on the web is going to use closed CDMs, than
> web-compatibility will require those CDMs, even if the spec doesn't say it
> explicitly. Theoretical spec-compliance isn't worth much.
>
> There are fundamental limits to effectiveness of a FOSS-compatible CDM, so
> we can already predict where that innovation will hit a wall.


I am not so pessimistic about this.

 I don't think that the proposal at hand doesn't allow video decoder output
>> to be available. You're making an assumption here.
>>
>
> However, it does allow it to be out of reach of the browser.
>

It is out of the reach of the browser today. The proposal opens up some
options where it's within reach.

If the spec limited what CDMs can do, it would be much more acceptable from
> perspective of security and implementability, but I think it's safe to
> assume that content owners will want to have option of using a full-stack
> DRM.


It seems there are conflicting goals here that won't be easy to resolve
today.

Christian

Received on Tuesday, 6 March 2012 21:10:00 UTC