Re: Comments on w3ctag/eme/

Peter, Yehuda,

Do you have any thoughts on Henri’s comments (below) about the Layering section of

  https://github.com/w3ctag/eme

? Please feel free to edit the text directly.

Cheers,

Jeni

------------------------------------------------------
From: Henri Sivonen hsivonen@hsivonen.fi
Reply: Henri Sivonen hsivonen@hsivonen.fi
Date: 19 February 2014 at 05:55:11
To: www-tag www-tag@w3.org
Subject:  Comments on w3ctag/eme/

[snip]
> > In the case of EME, according to the layering principle, it should  
> be
> > possible to specify a set of primitive APIs that would enable  
> a DRM
> > system to be built in Javascript. Many of the pieces that would  
> be
> > needed for this are already in progress, such as:
> >
> > * Streams API
> > * Crypto API (with access to hardware crypto and tokens)
> > * WebAudio API
> > * Canvas (with tainting) for video output
>  
> The discussion of layering misses the point on at least three  
> counts:
> 1) EME integrates into the HTML5 video stack better than the APIs  
> mentioned.
> 2) The more layers a CDM subsumes, the better from the studio perspective.  
> 3) The royalty economics don't favor JS-based solutions from  
> the site
> perspective.
>  
> Let's look at each one in turn:
>  
> 1) The Open Web Platform does not actually provide API surface  
> for a
> JavaScript program to receive elementary stream data (unencrypted  
> or
> encrypted) from the video stack and to return video frames as  
> ArrayBuffers or WebGL textures to the video stack. Yet, an EME  
> CDM
> gets to plug into the media stack on this sort of level. The point  
> of
> EME is to reuse the HTML5 media stack to the maximum extent DRM  
> Robustness & Compliance rules allow. On the other hand, if you  
> want to
> implement codecs that output to Canvas or the Web Audio API, you  
> have
> to also re-implement the rest of the media stack in JS. In this  
> sense,
> EME is better at layering than what the draft opinion puts forward.  
>  
> 2) If EME was truly about "encryption technologies" and not about  
> DRM,
> to layer things properly assuming CENC files, you'd just stick  
> the
> "[de]cryption technology" between the MP4 demultiplexer and  
> the code
> that deals with unencrypted codec data in the existing media  
> stack and
> you'd be done. However, in such a properly layered design the  
> "[de]cryption technology" would only have a chance to hide the  
> decryption key from the rest of the code. The decrypted elementary  
> stream data would be exposed to the User Agent, and in the DRM threat  
> model, the user is the adversary and the copyright holders tend  
> to be
> interested in hiding more than just the key.
>  
> Please take a look at the bulleted list at https://hsivonen.fi/eme/  
> .
> Having the CDM merely decrypt is just a theoretical baseline.  
> In
> practice, a marketable CDM needs to also do decoding inside the  
> black
> box, which already conflates two layers. But that exposes the  
> pixels
> to the User (i.e. Adversary) Agent. To hide those and thereby  
> get
> access to a broader range of content, you need to conflate the  
> layers
> even more. Therefore, clean layering and DRM are at odds.
>  
> 3) Now, what if the Open Web Platform had an API to enabled
> Worker-backed codecs and Worker-backed CDMs? A JavaScript  
> program
> would run in a worker and the browser would send a piece of
> unencrypted (in the mere codec case) or encrypted (in the CDM  
> case)
> elementary stream data to the Worker and the worker would put  
> YUV
> frame data in an ArrayBuffer at some offset and tell the browser  
> which
> ArrayBuffer and what offset. This way, the ArrayBuffer could  
> be an
> asm.js heap. Or, if WebGL in Workers happens, the Worker could  
> put the
> frame data in a WebGL texture.
>  
> Awesome, right? Now browsers wouldn't have to provide DRM. A  
> site
> could provide DRM as an asm.js program and, in principle, make  
> it as
> obscure as any native code disassembly.
>  
> Well, three problems:
>  
> a) You'd only get to conflate the decryption and decoding layers.  
> You
> couldn't compete with the kind of device-resident DRM that hides  
> the
> pixels from the browser.
>  
> b) You couldn't leverage hardware H.264 decoders, so the solution  
> would be less competitive on battery life (at least) than
> device-resident CDMs.
>  
> c) The site would be liable for third-party royalties that whoever  
> distributes the CDM to end users would be subject to, starting  
> with
> H.264 decoder royalties in a world where sites have a substantial  
> investment in using H.264 and device-resident CDMs use H.264.  
> In the
> case of device-resident CDMs, royalty liabilities arising  
> from CDM
> distribution are not the site's problem.
>  
> The mention of the possibility of an asm.js program being able  
> to be
> obscure leads to my last point:
>  
> > such as a secure JS worker that would only have access to a narrowly  
> > limited set of APIs, and would run in a special context that could  
> not
> > be inspected by the user
>  
> This is a terrible idea compared to EME. Please take this out of  
> the opinion.
>  
> If the browser is responsible for making the program running  
> in the
> Worker non-inspectable, the "robutness" (i.e. the capacity  
> of the
> solution to resist attempts by the end-user to read or write the  
> data
> inside the DRM box) of the solution hinges on the browser and the  
> browser itself falls into the DRM realm. This is worse than EME,  
> which
> maintains a separation between the User Agent (trusted by the  
> user)
> and the CDM (trusted by studios).
>  
> Since you seem to be worried about the browser becoming subject  
> to
> anti-circumvention law, such as the DMCA, you shouldn't want  
> the
> browser to fall into the DRM realm. That is, you shouldn't want  
> the
> robustness of the solution to hinge on the browser.
>  
> If you want a Worker-based solution, you should suggest the Worker  
> to
> be explicitly an inspectable white box and leave it to the
> site-supplied JS program running in the provided environment  
> to be
> sufficiently obscure to defy inspection.
>  
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/

--  
Jeni Tennison
http://www.jenitennison.com/

Received on Saturday, 22 February 2014 13:37:29 UTC