[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 #23 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> ... 
> >
> > > 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?

That's one possibility, yes. See Henri's response on this as well.

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

No, I think more likely for the case of CDMs embedded in the OS or hardware
there will be an API for each specific CDM that the UA will code to, if they
decide to support that CDM on that platform.

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

No, I don't believe either of the above are obvious. We may have different
definitions of DRM.

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

We obviously can't limit what a user can do with their machine. DRM relies on
providing software or hardware components which are hard to modify whilst
retaining their intended functionality. That's a different thing.

Given that difference, then yes DRM could be supported in an open source web
browser that integrated with components of that kind.

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

No, there are also software solutions which are not part of the operating
system.

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

No, this depends on the interface between the UA and the CDM and the security
and privacy properties of the CDM.

> 
> 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 Monday, 25 February 2013 17:58:35 UTC