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

On Sun, Mar 3, 2013 at 4:46 PM, Fred Andrews <fredandw@live.com> wrote:

>
>
> > From: glenn@skynav.com
> > Date: Sun, 3 Mar 2013 14:27:12 -0700
>
> >
> > On Sun, Mar 3, 2013 at 5:33 AM, Fred Andrews <fredandw@live.com> wrote:
> >
> >> From: glenn@skynav.com
> >
> >> I don't rule them out at all, but believe they are not technically
> compatible with systems that the user controls including many open source
> operating systems because it is trivial to access the decoded output.  I
> would like to see this recognized and believe it would impact the design of
> the EME API, and might affect a decision to advance EME.  Even if EME is
> advanced, I would still like it recognized to avoid 'dumb copyrights' being
> inflicted on the open source community.
>
> >
> > Please indicate how the "design of the EME API" should be changed. I
> don't know what you mean by "dumb copyrights". Copyright is a well accepted
> legal term. The adjective "dumb" does not apply. The copyright and access
> control applied to copyrighted content is wholly in the purview of the
> content owner. As a distributor or user of that content, one is obligated
> to satisfy any controls subject to applicable law.
> >
>
> If it were recognized that different classes of CDMs met different use
> cases then the EME API could be constrained to meet only these use
> case for a given class of CDM and this could improve security and
> privacy for some classes of CDMs.
>
> I'll refrain from using the term 'dumb copyrights' again, as it's beyond my
> competence to discuss, but you might be interested in the following:
>
> http://harvardcrcl.org/2013/02/19/a-summary-of-laurence-lessigs-chair-lecture-at-harvard-law-school/
>
>
> > This forum is not about discussing the legitimacy or utility of
> copyright.
>
> I am not discussing the 'legitimacy' of copyright.   It is not
> clear what you mean by 'utility', but I believe the technical
> effectiveness of proposed solutions would be in scope
>
> In any case I do not recognize your authority to make this
> decision and would defer to a decision from others.
>
>  ...
>
> > I think this is well said, and wish much of this were in the EME spec.
>
> > Why? There is nothing about what I said above that is necessary to know
> to implement or use EME. There is no obligation to provide such background
> information in a technical specification. If you think otherwise, try
> reading ISO and ITU standards. That being said, I wouldn't object to a
> summary of what I said above being provided in an informative annex if it
> would help reduce the number of misunderstandings or objections to this
> work.
>
> Yes, I might understand your position, but believe explaining the
> technical basis for decisions is necessary because they are disputed
> and it would have been constructive to have been able to file bugs
> against them and work towards consensus in this forum.  It looks
> likely that alternative forum(s) will emerge.  Enough said here probably.
>
> > However, it is not clear to me how category (1) CDMs could even
> > provide any real protection against the user storing the content
> > because when implemented in user controlled systems the
> > decoded stream is available.
>
> > Well, for example, the content author may decide to use such a
> > system along with a EULA that requires the user to agree to not
> > copy or modify content, and then use watermarking of content
> > as a way to enforce that license. If a user violates the EULA and
> > is discovered (by watermark detection), then the content author
> > could bring legal action.
>
> Yes, a content author could ask customers to accept not using
> a 'save as' feature in their web browser or operating system -
> any terms are possible.
>
> Watermarking is not an EME use case, and does not require EME,
> and I am not disputing its use.
>
> I dispute your position that technically ineffective solutions to
> use cases should be advanced and believe that doing so
> would damage the community.
>
>
> > It is up to the content authors/owners to determine what
> > systems and what level of protection are appropriate to their
> > business interests.
>
> This is not a technical matter, and would be a matter to be
> disputed in courts.
>
> > Further, EME is designed to be an open system w.r.t. to possible
> > CDMs. Someone may come along tomorrow and publish a full PAS
> > of a system that doesn't exist today. So you can't say (with
> > certainty) that it could not happen.
>
> Designing a technical specification, with significant security
> and privacy concerns, to be more 'open' than it needs to be
> to meet the uses cases at hand may not be a sound approach.
>
>
> >> Using a proprietary co-processor in the video path to implement
> >> the CDM in otherwise open source systems is one option, and
> >> I suggest is the only real option.   Surely it would be useful to
> >> document this in the EME specification.
>
> > Again, that is an implementation detail that isn't related to EME
> > or the CDM concept. You need to understand where it is necessary
> > to write things into a spec to obtain interoperability at the
> > specification level versus avoiding writing things that are
> > implementation dependent.
>
> It would affect the use cases, requirements, and design of the EME.
>
> >> The task remaining is to defend open source
> >> stacks from 'dumb copyrights' which might be done by ensuring
> >> that CDMs advertised to offer content protection are restricted to
> >> proprietary systems or components where it is even remotely
> >> effective.  I anticipate that the proponents will claim that weaker
> >> CDMs might be adequate for some content and provide some
> >> 'friction' to copying, but this can be countered by ensuring that
> >> user controlled systems have a 'frictionless' feature that can
> >> record any stream and that it is simple enough to use that even
> >> 'mum' could do so.
>
> > This is out of scope of EME and the HTML WG charter. Feel free
> > to propose a community group to do this.
>
> The scope of use cases, the technical effectiveness of proposals
> to address them, and consideration of the interaction with other
> standards all seem well within the scope of activities here.
>
>
> >> If the different classes of CDMs could be recognized then more
> >> could be done to protect security and privacy when using
> >> category (1) CDMs by removing the back channel when using
> >> them and also giving the UA control of the state etc.
> >> The stream can be recorded so it is not possible to use these
> >> CDMs to enforce a rental model anyway, so lets not try.
>
> > This is a meta level issue outside the scope of defining EME.
> > It's sort of like starting a conversation about what kind of
> > content should be allowed to be written in HTML. That may
> > be an interesting activity for some with philosophic tendencies,
> > but it isn't a very productive use of this group's time IMO.
>
> I dispute your interpretation of this activity.  It seems
> technically sound to classify CDMs based on the use
> cases they solve and to restrict the EME appropriately.
>
>
> > Regarding recording of media played back with EME, this is
> > really a conversation for one of the Media Capture or Media
> > Downloading and Recording task forces. I suggest you raise
> > your concerns there, since once again, it is not in scope for EME.
>
> User controlled systems do not need a consensus standard
> to record streams, they are more than capable of recording
> them and this is a technical reality for EME solutions to take
> into account.
>
> Your calls to limit technical analysis, to limit discussion, and to
> move them elsewhere does not seem constructive, or a path
> to consensus.
>

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

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.