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

On Mon, Mar 4, 2013 at 6:07 AM, Fred Andrews <fredandw@live.com> wrote:

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

I've been attempting to draw out a technical problem or proposal from you,
and it has not appeared yet. So rather than belabor the point, I'm not
going to continue this thread (with you). Good luck in achieving your aims
described above.