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

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

> It would not be productive to continue this thread, since I would just
> be repeating what I've already said. We shall have to conclude that we
> disagree on principles and approaches.

Irrespective of Glenn's  personal views of the 'principles and approaches'
it should be expected that technical merits prevail.  If the technical
merits of your position are weak and you want to withdraw from
the decision making process then by all means do so.

> I will conclude that I believe your desire to document use cases is not
> a necessary or useful improvement to EME technically, and that there
> is no utility to introducing or exposing a taxonomy of CDMs at the EME
> API layer.

This is just Glenn's opinion and I dispute it.  A technical analysis of the
EME/CDM operation and use cases can lead to many objectively
verifiable conclusions and design improvements.

> Even if an API were added that allowed the code using a specific CDM
> to obtain metadata about the CDM, it would not be used by code.
> The reasons for that are very simple: the content owner in concert
> with the content distributor will determine which CDM or CDMs
> (among a number of choices) are acceptable, and will do this on an
> a priori basis, not by having client side code land on an arbitrary UA
> and then query local APIs about CDM characteristics. In other words,
> I don't see a use case for client side code to insert itself into the
> process of negotiating or determining which CDM will be used.

> 
> If there are legitimate use cases for exposing CDM metadata,
> including information about level of protection (however that
> might be qualified), about abilities of the CDM to save stream
> data, etc., then I would suggest bringing them forward as a
> future extension to EME. Nothing in EME as presently defined
> would need such a feature, and wearing my hat as a
> representative of a commercial video provider, I don't see
> any reason that we would use such a feature. So it seems
> to me that rather than proposing a feature tabula rasa, you
> need to go out and find real users that can document use
> cases then create a strawman proposal for such metadata
> extensions.


I have not suggested adding an API to allow code to obtain
meta data about the CDM!   This is just rambling.

> So far, you are simply suggesting a that design changes
> are needed without having real world use cases in hand
> or having real world users ready to use such yet to be
> defined features. That isn't very compelling as an argument
> for taking any concrete action.

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.

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.

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.

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.

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

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

cheers
Fred