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

On Sun, Mar 3, 2013 at 5:33 AM, Fred Andrews <fredandw@live.com> wrote:

>
>
> > From: glenn@skynav.com
> > Date: Sat, 2 Mar 2013 11:07:42 -0700
> 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.

This forum is not about discussing the legitimacy or utility of copyright.



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

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.


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

It is up to the content authors/owners to determine what systems and what
level of protection are appropriate to their business interests.

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.



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



> I expect the EME spec will be forced through, either here or as a
> de facto standard.
>

I don't know what you mean by "forced through". Although there are a few
vocal individuals that have expressed objections to EME, it is up to the
W3C membership as a whole to make that decision. There is no "forcing" the
process. The process happens just like always.



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



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

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.