RE: [Bug 20944] New: EME should do more to encourage/ensure CDM-level interop

> From: watsonm@netflix.com
> To: fredandw@live.com
> CC: public-html-media@w3.org
>
>> On Mar 4, 2013, at 5:07 AM, Fred Andrews wrote:
>>
>> Much of the web community already uses an open platform.
>> This use case is already addressed.  The concern is a
>> regression and an analysis of the EME/CDM and use cases
>> is need to assess this matter.  Some design changes might
>> be made to mitigate some of the regressions, but in any
>> case the impact of the EME API needs to be well communicated.

> Can you be more specific on what you mean by "regression" ?

Many of the issues were raised in bug reports, others will
be developed.

>> Users need to be told that content authors demanding
>> strong copy protect will demand that users computers
>> include an encumbered CDM in the video path to the
>> screen pixels that is not trivially compromised.

> I'm fine with this statement. But what role do you expect the
> EME specification to play in such communication to users ?

There are lots of areas that are affected: FAQ, use cases,
requirements, design, overview.

>> Users of free open source operating systems need to be
>> told that they will need proprietary CDM hardware in the
>> path to the screen pixels to view content that demands
>> strong copy protection.

> Proprietary CDM hardware is one solution and I'm glad
> we agree that there exists a solution for users of FOSS
> operating systems and browsers.
>
>
> I don't think we can claim with certainty that there are
> no other solutions for such users.

I think a strong technical case can be made for this, and it
should stand until shown otherwise.  Can anyone refute it?

> You seem to be assuming that any solution in which decoded
> media is passed to user-modifiable software is equivalent to a
> solution in which a convenient 'Save As…' option, outputting
> compressed media files, is provided.

No, this assumption about 'any solution' is not needed.   Someone
wanting to record the stream has the technical choice of using
a system with this capability.

> Some content authors may indeed consider all such solutions
> equivalent too, but the decision is a judgement call to be made
> by the content authors, not a technical issue or something that
> can be decided by you and I.  I don't think we should rule out
> such possibilities a priori, especially since we frequently
> hear that users of FOSS operating systems want services like
> Netflix to be made available on those platforms.

Such solutions offer protection against the user storing the
stream that is equivalent to a 'do not copy' fag would.  Since
such a flag is much simpler and has less security and privacy
issues, surely it would be preferred.

Could you please detail the architecture of the Netfix
'solution' for Firefox on FOSS systems so we can understand
your position more clearly?

>> Users need to be told that unencumbered CDMs do not
>> technically restrict them from storing the decoded output
>> and that the CDM back channel in this mode is of no
>> utility to the user and amounts to spyware.

> Obviously, a system which provided no impediment to saving of the
> media content - for example systems with a convenient Save As …
> function - has no value. Without an example of an 'unencumbered
> CDM', though, including information about how it is deployed and
> integrated with browsers, it's not possible to say that all such
> solutions fall into this category.

We can technically evaluate the ability of solutions to solve use
cases.

We can technically evaluate simpler solutions that give the
same level of protection.

If the CDM unencumbered then the content author has
no control over which web browser the user chooses to
use and thus it makes no difference how the CDM is
deployed and integrated with a particular web browsers.

> Again, as above, the question of utility to content authors is
> a judgement decision for them to make, not a technical issue we
> can determine in this forum.

We can develop sensible technical solutions to meet their use
case, but obviously we can not decide for them if these use
cases are of utility to them - but we are not trying to do so.

We are not compelled to standardize a particular technical
solution to use cases.  There are multiple stake holders.

Could you please articulate this use case, and why it would
not be solved by a 'do not copy' flag alone?

>> The web community needs to have these technical facts
>> communicated to them honestly and clearly.

> The things above that are facts are not technical facts: the
> first point on what content authors demand and the second point
> that hardware CDMs could be a solution for FOSS users. Both
> involve the judgement of content authors.

There may be some assumptions that the content author
behaves rationally etc, but this is only a fault in the wording
and it could be reworded to be more explicit.

For example, consider the first point.  A good technical case can
be made that only an encumbered CDM offers protection beyond a
'do not copy' flag and this could be objectively tested by
developing software that makes it trivial to record the decoded
stream in a system that users could choose to use.  Is anyone
refuting this could be done technically?  It is then just a matter
of logic that a content author who *wants* copy protection
beyond a 'do not copy' flag will need to use an encumbered CDM.
There is nothing here that is subjective except for the content
authors need to meet the use case which is outside the scope
of the technical solution itself.

If the task forces entire rational behind the EME specification is
that the use cases for a EME/CDM system and the technical
merits of such systems is entirely the choice of a content
author then this robs other shake holders of the ability
to have input into the solutions and I suggest this is hardly
an appropriate position for participation in this forum.

> Nevertheless, noone has tried to hide these things from anybody.

The task force has framed EME as an 'interface' to CDMs that
solve unspecific use cases.  This attempts to put the complete
solution beyond review, and the task force has opposed such
review.

The task force has bundled solutions to use cases that
could well have distinct solutions into one specification.

If the 'strong content protection' use case were unbundled
then the EME would be an interface to encumbered technology,
and it would be clear that it is not suitable for standardization
here.

If the 'unencumbered CDM' use cases were unbundled then
it would be clear that a much simpler 'do not copy' flag
would solve it and that this could be standardized.

If the 'secure transport' use cases were unbundled then it
would be clear that they can be solved in other ways and
could be standardized.

Sorry, but I believe this stinks of 'poor judgement' at the
very least.

>> I believe to do otherwise is not honest, and I do not respect
>> calls to limit this analysis.

>> It is clear that many here do not support such an analysis and
>> are calling for it to be done elsewhere.

> Suggesting that something be done elsewhere is not the same as
> not supporting it. In fact it would be inconsistent to
> simultaneously oppose something and call for it to be
> done (anywhere).

This is the appropriate forum, and the EME specification is the
appropriate document.

How much more discredited does this task force need to become
before it is not longer appropriate for it to have a voice in this forum?

> I think what Glenn and I have been saying is not that analysis
> should be limited, but that the analysis you propose is flawed
> and that even if it wasn't there is no technical impact on the
> EME specification.

I have tried to point out the impact on the EME specification,
and have refuted most of the claims you have made.  There is
always a chance that you are wrong!

>> You can be sure that when the EME spec. is again submitted for
>> CfC FPWD that the impact document will be submitted in
>> parallel and if you are not involved then you will have no
>> input.

> Of course you are entitled to submit whatever material you
> like. Glenn and I *have* been providing you with feedback
> throughout this long thread.

I would note that you do not claim to have provided good faith
constructive feedback!

cheers
Fred