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

> From: glenn@skynav.com
> Date: Sat, 2 Mar 2013 11:07:42 -0700
>
...
> 
> Agreed. Perhaps it would be useful to distinguish 3 cases for publishing the details of a specific key system and encryption system implemented by a CDM:
>  1. All details are published as PAS.
>  2. Most details are published as PAS, while some details require an NDA to access.
>  3. No details are published as PAS, i.e., all details require an NDA to access.
> 
> I would suggest that it is desirable to maximize those systems that fall in to the first category, while recognizing that some legacy systems may fall into the second or third categories.
> 
> Regarding Fred's notion of "independently implementable", I would call all of the above three categories of systems "independently implementable" in the sense that two implementors given access to all necessary specifications can implement any of them.

Yes, this was the meaning I was trying to communicate, but I recognize the above alternatives too.

> However, I'm sure that Fred's definition of "independently implementable" is a subset of my definition, and could only be satisfied by the first category above. Since Fred would appear to rule out systems that require reference to any NDA governed specification material.

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.

> So, where are we today? Most existing systems fall into categories 2 or 3 above.
> I'm not aware of any complete DRM system that falls into category (1), though
> there are certainly some useable components fall into category (2), e.g., ISO/IEC 23001-7:2012.

> 
> It is clear that initial uses of EME by content service providers encumbered
> by content license restrictions will need to make use of CDMs that fall into
> category (2) or (3). One might suggest that with such an initial usage,
> things will never get better, i.e., move further towards category (1).
> I can't argue with certainty either way on this point. I can say that it is
> possible that genuinely useful CDMs will appear in category (1) that could
> be potentially accepted for use by content licensors. But I can't say if or
> when that will happen. In my mind, it should not be a pre-requisite for
> publishing EME, because this goes considerably beyond the technical
> matters of EME and falls into the domain of deployment. However,
> I recognize that this remains a concern, particularly for those parties
> that wish that controlled access content could be reasonably accessible
> on platforms that have made policy decisions about whether to permit
> portions of their platform to be non-open. Given that such platforms
> find ways to use proprietary processors for various purposes (i'm
> thinking of graphics here), I don't see why they couldn't also find
> ways to use proprietary processors for use with EME and open
> sourced user agents.

I think this is well said, and wish much of this were in the EME spec.

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.

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.

I expect the EME spec will be forced through, either here or as a
de facto standard.  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.

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.

cheers
Fred