Re: EME compatibility with existing DRM systems

On Tue, May 7, 2013 at 6:58 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
> There is one question that came up during the webinar regarding whether a
> Key System implementation is "allowed" to interact directly with a DRM
> server, without going through the user agent and application with a
> keymessage event.
> The speaker's response was that he wasn't sure whether it was specifically
> forbidden or not, but that he couldn't see why it would be needed.

Doing so would clearly go against the fundamental design of EME and
fail to benefit from the design of EME. The main benefit being that
when key server communications go from EME to JS to XHR (and back),
the user's session cookie goes along the XHR communication, so there's
no need to build a second session management mechanism for the DRM
system.

So that's a benefit for cases like Netflix where there is a concept of
login. For cases without login, the benefit is that XHR is subject to
the Same Origin Policy, so if a rogue site copies the video and the
JavaScript program, the Same Origin Policy prevents the JavaScript
program copied to another site from obtaining keys from the key server
of the site from which the video and the JavaScript program were
copied. (And the CDM prevents the playback of the video if keys
weren't obtained.) This should address the concern voiced e.g. by the
BBC representative about ensuring that video content appears in its
intended context instead of being embedded by rogue sites.

(Of course, enforcing the Same Origin Policy is the task for the
browser and in the EME model the browser is treated as un-trusted by
the content rights holders. It wouldn't make sense to be worried about
rogue sites that'd depend on rogue browsers for operation that'd rely
on the original key server instead of cracking the DRM. The users
trust the browsers for the privacy and to make a browser rogue in a
way that would allow the violation of the Same Origin Policy would
mean compromising user privacy, so it's unlikely that users would want
to obtain rogue browsers like that just to view content that would be
loginless *anyway* in the context of another site than the original.)

> He also mention in the talk that one of the goal of the EME spec was to at
> least allow existing DRM systems to be supported through the proposed
> architecture.

It's more like being able to use existing robustness solutions, the
name recognition of existing solutions and possibly existing license
rule systems than about being able to use existing solutions
wholesale, since, as you note, EME implies remapping the license
server communication protocol to fit into EME messages.

> In the lightweight, "on-demand", mode of Marlin, called MS3, which is often
> used when there is no persistent license delivered (a non-persistent
> lightweight license is sent back to an authenticated client, just for use
> within the context of a streaming session), the client needs a direct,
> non-intermediated, communication with a server.
> For scalability reasons, the protocol between the DRM client and the server
> is based on a mutually-authenticated TLS session, not on a signed/encrypted
> data payload that can be relayed (like a SOAP message could be in the case
> of PlayReady for example).

In that case, MS3 would not work with EME as-is (without defeating the
fundamental architecture of EME).

However, MS3 is already the third flavor of Marlin (after the original
and Broadband). Given the willingness of the Marlin Developer
Community to develop different flavors already, it shouldn't be a big
deal to develop an EME flavor of Marlin such that user identification
would be based on session cookies picked up by XHR and the other
semantics of the communications that currently go over the MS3 TLS
pipe would be mapped to EME key messages.

A relevant question, of course, is whether such a flavor is actually
being developed. Is such a flavor in development?

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 8 May 2013 05:58:03 UTC