[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 #28 from Henri Sivonen <hsivonen@iki.fi> ---
(In reply to comment #24)
> 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. 

The design of ISO Common Encryption and EME assumes that you contact the
license server at least once per video title. Unless most users stop, exit the
browser and later resume many times per title, trying to optimize away the
license server contact when resuming the previously started title still seems
like a totally wrong optimization, since one would assume that as far as the
burden on the license server goes, the contacts arising from initially starting
a title dominate compared to the contacts arising from resuming a title.

> For example - I
> acquire a license at work on a non-external server and then use that license
> when I am outside work. 

I am surprised that such a use case is considered to be in scope. I think we
need an explicit enumeration of use cases and discussion about which of those
are considered to be in scope, considering that fringe use cases such as
intranet DRM where you can start playing only on the intranet but can resume
playing outside the intranet bring complexity and privacy considerations that
aren't necessitated by the Netflix-like scenario.

(I wouldn't be at all surprised if browser vendors that deemed the Netflix
scenario worth supporting were unwilling to accept additional complexity or
adverse privacy characteristics in order to support resuming intranet content
outside the intranet.)

What mechanism do you assume for making sure that the media itself continues to
be available when you take your device outside your intranet?

> Also HTTPS is not appropriate for every situation requiring security. HTTPS
> is too heavyweight IMO if what you need is a REST like API.

There are plenty of sites of all sizes that are able to deploy https. Moreover,
browsers like Firefox and Chrome are trying to push the Web into an
https-everywhere future. I think it would be inappropriate for EME to try to
work against that direction or to postulate that the deployers of EME services
would somehow be less able to deploy https for the license transactions than
all the other sites that currently deploy https. In other words, I think we
should be able to assume that sites that think a network MITM would jeopardize
their license transactions are able to put the XHR traffic implied by EME over
https.

Still, the notion that an insecure network would make the license transactions
insecure seems bogus, because one of the underlying assumptions of EME is that
the browser isn't trusted with the content keys (hence the need for the
separate-trust-level CDM box). It seems implausible that a key system that has
been properly designed not to be vulnerable against an instrumented browser
dumping the content keys would be vulnerable against a network MITM dumping the
content keys.

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

Why do you assume that an in-browser VOD service design would work like that
instead of working like Netflix works? What mechanism do you assume for making
sure that the video content stays cached in the browser? It seems to me that
the current caching mechanisms in browsers are inappropriate for ensuring that
several gigabytes worth of data stay unevicted and you haven't explained why 
the mechanisms currently being proposed wouldn't also be able to take care of
caching the licenses so that the CDM itself wouldn't need to be able to
persistently store them.

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

Received on Tuesday, 26 February 2013 08:31:08 UTC