[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 #24 from Joe Steele <steele@adobe.com> ---
(In reply to comment #22)
> (In reply to comment #14)
> > My point was about the
> > persistence of unique identifiers, not how global they are. I am *not*
> > arguing for the existence of a globally unique persistent identifier exposed
> > to all sites, nor is it required for CDMs (at least not the one I am most
> > familiar with)
> 
> Can you, please, elaborate on that? The Adobe Access 4 Overview document
> links to from comment 5 says:
> "The Flash Player or Adobe AIR runtime client acquires a unique digital
> certificate (called a machine certificate)
> from an Adobe-hosted server.
> 
> This process of assigning a unique certificate is called individualization.
> Individualization uniquely identifies both
> the computer and the Flash Player or Adobe AIR runtime used to playback
> content.
> 
> The individualization process allows the downloaded licenses to be bound to
> a specific computer on which the
> client is installed. Every computer is given a unique machine credential
> (machine private key and machine
> certificate). If a specific client were to become compromised, it can be
> revoked and barred from acquiring licenses
> for new content."

The Access machine certificate that is acquired is unique per application, not
per computer. That documentation is incomplete. Thanks for pointing it out. 

> > Here are some of the benefits:
> > * Allows the license provider to lower their cost (less network transactions
> > required) which can result in lower costs for the user.
> 
> This seems like a wrong optimization. The network transactions for
> re-contacting the license server are tiny compared to the network
> transactions involved in the transfer of the media itself and even in the
> transfer of the HTML, CSS and JavaScript around the media.

The network operations themselves are usually trivial (though non-zero). The
bigger cost in this case can be the encryption/decryption operations which may
take place on licensing server. These can involve contacting other servers,
HSMs, etc. It can be a significant cost factor. This is also a factor in not
using HTTPS. 

> > * Allows the user to request a license in a secure environment and then
> > continue to play back content when they are in an insecure environment
> > without having to reacquire the license over the insecure network. 
> 
> We have https for secure transactions over an insecure network.

That is correct, however in this case I am more concerned about a license
server that is not accessible from the current location. For example - I
acquire a license at work on a non-external server and then use that license
when I am outside work. 

Also HTTPS is not appropriate for every situation requiring security. HTTPS is
too heavyweight IMO if what you need is a REST like API. This is not a concern
for every protocol, but it I don't see a need to mandate HTTPS when a
lighter-weight channel will do. HTTPS is subject to MITM attacks when the
application cannot verify the servers certificate directly. Currently the EME
does not provide for this and relies on the UA and the application to perform
network operations.

> > * Reduces the number of times the user needs to authenticate.
> 
> Can you elaborate on this? In a Netflix-like case, you need to login to
> resume an interrupted movie anyway. On a site similar to thedailyshow.com,
> there is no user-facing authentication in the first place.

It is common in the VOD model for the user to acquires a license that is valid
for longer than a single session. This license can be acquired once and then
the video can be played back multiple times without having to re-authenticate,
since authentication may only be required in the license acquisition phase. 

> > > 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?
> 
> My point is that if the CDM manages its own storage, there can be snoopable
> data left there after of browser function to wipe browser-managed storage,
> such as the HTTP cache, has been used. To remedy this, persistent storage
> for the CDM, if needed at all, should be browser-mediated.

That is a valid approach.

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

Received on Monday, 25 February 2013 18:10:31 UTC