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

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

cheers
Fred