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

On Mon, Mar 5, 2012 at 5:06 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

>  We can also force specs to be clear about the fact that they're de
> facto requiring closed-source and/or royalty-encumbered technology in
> implementations, rather than allowing them to hide behind a
> trojan-horse tech that will see little to no use.  It's dishonest to
> attempt to claim that a spec does not include DRM and does not require
> closed-source and/or royalty-encumbered technology when it will, in
> practice, require precisely that.

I do not see any dishonesty in the proposal, which simply says, 'No "DRM"
is added to the HTML5 specification...' This is a fact - as people have
pointed out, there is no specification for the CDM or how it works. In
addition, "DRM" is in quotes because it is a broad term that has a lot of
interpretations, including full rights management. The
proposal acknowledges that content and the keys may need to be protected,
and makes no claims about open-/closed-source or royalties.

Clear Key is not a trojan horse. I honestly hope some content providers
will choose to use it given universal support and a low barrier to entry.
It is also useful for browser and application development and
experimentation. The proposal also leaves open the possibility of adding
other standard CDMs - maybe someone will come up with one that offers
stronger assurances for content owners while still being implementable in
FOSS. It seems very unlikely that would happen in the status quo.

>> Sure, and I have a right to require any browser I use to not
> >> interoperate with closed-source blackboxes that impair my computer's
> >> security.  So it's a question of user's rights.
> >
> > I agree you have that right. This proposal would help you exercise it.
> Your browser could inform you about CDMs and you could turn them off.
> Unlike today, where you have to forgo Flash/Silverlight and all the non-DRM
> functionality they provide in order to exercise that right.
> >
> > Both you and the content author can have their rights respected - it
> doesn't have to be a choice.
>


In effect, you're claiming that offering a "Do you want to be able to
> watch videos? Y/N" dialog is sufficient for respecting our users'
> desires.  I and several other browser developers do not agree that
> this is the case.  We believe that the demands of content distributors
> are unreasonable.


Users aren't even given this option today. Nor do they have an option to
choose a CDM that is more acceptable because content providers only support
the one that is part of the larger plugin stack. If we can remove the need
for proprietary stacks, providers will be more likely to support multiple
CDMs and users can vote with their feet.

On Tue, Mar 6, 2012 at 1:09 PM, Christian Kaiser <kaiserc@google.com> wrote:

> 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.
>>
> It's worth noting that this content is already unavailable to the "open
web", and implementing NPAPI does not necessarily make it available. Sure
many platforms have Flash, but I'm guessing many fewer have Flash Access or
Silverlight support. The proposal allows other companies to provide the CDM
functionality on new platforms without convincing a content provider to
adopt an entire plugin stack. The proposal doesn't mean currently available
content will be locked up. Some content may even be made more available if
Flash, etc. are only being used to provide transport security.


>
>> 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.
>
It's possible that CDMs will compete on such functionality similar to what
I mentioned above. The proposal at least opens up the possibility that
currently unavailable content can be used in this way.

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