[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 #20 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > (In reply to comment #13)
> > > > (In reply to comment #10)
> > 
> > > > In any case, persistent storage of licenses gives a person with access to
> > > > the computing device information about what sites have been accessed.
> > > 
> > > This is dependent on how the information is secured on disk. The browser
> > > cache seems like a more likely target for snooping though, since the
> > > location you downloaded the movie from is probably much more informative. If
> > > I have local access to the computing device I can gather information on the
> > > user in any number of ways. 
> > > 
> > > Or is your point that the user can get access to the list when the DRM
> > > vendor might not want them to?
> > 
> > I think the point is that if the CDM has a secret persistent store, then the
> > 'clear browsing history' function of the UA might not operate the way the
> > user expects.
> > 
> > But again, I think we have to remember that the browser implementors have
> > reputations to protect and privacy experts to help them with that. I expect
> > they will make careful decisions as to what CDMs to integrate with based on
> > detailed information about what those CDMs do and also about what the UA
> > *allows* the CDM to do for the case where the CDM runs in some kind of UA
> > sandbox.
> 
> 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.

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

Not necessarily. There are use-cases where the output of the CDM is decrypted
decoded media samples and the purpose of the CDM is primarily to protect the
key and the encoded samples.

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

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

Received on Saturday, 23 February 2013 00:08:34 UTC