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

On Mar 4, 2013, at 5:07 AM, Fred Andrews wrote:



> From: glenn@skynav.com<mailto:glenn@skynav.com>
> Date: Sun, 3 Mar 2013 19:24:15 -0700
...


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


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 ?


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


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


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.

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


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

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.

  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.

…Mark


cheers
Fred

Received on Monday, 4 March 2013 16:28:58 UTC