[Bug 20965] EME results in a loss of control over security and privacy.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965

--- Comment #21 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
... 
> > My understanding was that EME was a UA interface to the non-UA-CDM and
> > that the CDM had privileges above and beyond the UA, and thus the UA
> > has little opportunity to protect the user.  The relationship between
> > the UA and the CDM needs to be clarified.
> 
> Sure. We don't say anything about that now.
> 
> But practically, some DRM vendor cannot magically integrate their CDM with a
> UA without support from that UA implementor. If the UA implementor opens up
> a public API for CDM integration (for example by defining EME extensions to
> NPAPI) then I agree with many of the points made, because all bets would be
> off about what kind of things the CDM might do and what kind of protections
> the UA could offer.
> 
> So I don't expect UA implementors to do that for exactly that reason. They
> will carefully choose what CDMs to integrate with taking all these issues
> into account and working with the CDM vendors.
>
> > Does EME even support the UA identifying the EME in a secure way
> > that the privileged CDM can not spoof?  If not then the UA has
> > absolutely not control.
> 
> I don't understand the question - do you mean 'UA identifying the CDM' ? If
> so, then it's nothing to do with the EME spec and everything to do with the
> UA implementation. The UA does need to know what CDM it is talking to.

So you are suggesting that the UA have a short-list of CDMs from which
it will select a CDM to 'load' based on the requested 'Key System string',
and that the details of how the UA identifies the CDM from this short list
is a UA implementation detail?

Or alternatively that a proprietary OS has a short-list and the user
trusts the OS to manage this, or the system interfaces to proprietary
hardware that implements the CDM and the user trusts this.

> > Clearly if the UA is to be able to protect the user from the CDM
> > then the CDM must be subordinate to the UA, and then the UA is free
> > to capture the output of the CDM and EME has not value for DRM.
...
> There are also scenarios where a UA integrates with a CDM that is provided
> as part of the Operating System or platform, through standard APIs. The CDM
> may then output media directly to the output device. In this case the UA
> implementor is relying on representations from the platform vendor about the
> privacy properties of the APIs they are using - but this is true for any
> platform APIs that the UA makes use of. For example, when clearing browsing
> data the UA relies on the APIs for deletion of data stored on disk to
> actually delete that data (in fact in this case those APIs probably don't
> expunge the data from the disk but simply delete the files - a UA
> implementor chooses whether this is adequate to protect the user or whether
> they need to use different APIs that will write random byte patterns over
> the disk sectors several thousand times etc.).

Can we reach a consensus that a UA controlled CDM can not support DRM and
that DRM demands that the OS vendor conspire with the CDM author to limit
the control the user has over their computer?

Can we reach a consensus that DRM is not applicable to open source stacks
because it is not possible to limit the control the user has over their
computer?

Can we reach a consensus that DRM could be supported in an open source
web browser that uses EME to interface to a proprietary CDM that runs
in a context that limits the control the user has over their computer?

Can we reach consensus that DRM requires the user to trust a proprietary
operating system or CDM hardware module?

Can we reach consensus that the UA has no ability to control security
or privacy when using DRM?

If we can agree on some of these matters then it may help discussions progress,
and can some non-normative text be added to the EME specification.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 23 February 2013 01:17:46 UTC