This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The purpose of EME is to replace existing DRM solutions implemented using non-HTML technologies such as Flash or Silverlight with a HTML-based solution. Both these existing technologies have at their core a platform-independent VM. To not include a platform-independent VM in EME would be a step backwards. A platform-independent VM could be included either by reference to an existing standard (e.g. Java or .NET) or by defining a new VM. If a single VM cannot be agreed upon, another option would be to allow several different VMs. If a new VM was to be defined, one approach would be to use ECMAScript + Typed Arrays as the VM. This would be advantageous in that many browsers already have very good ECMAScript VMs. A binary encoding for ECMAScript (or a subset thereof) could be defined to help satisfy CDM providers' concerns for obfuscation. Existing browsers could easily translate this binary encoding to standard ECMAScript, or bypass the textual representation and convert it directly to their own internal representations of compiled ECMAScript. Any CDM implemented on a platform-independent VM will inevitably need to access native services. While these services themselves are platform-specific, it is possible to define bindings between VM and native code which are mostly platform-independent. Consider for example P/Invoke on .NET, or JNI or JNA under Java. If one or both of these existing VMs were to be adopted, then these existing technologies could be used to provide this facility. Alternatively, were a new VM to be defined (such as my suggestion to base one on ECMAScript + Typed Arrays), one could define a native binding API for it based on the model of P/Invoke and JNA. Some small platform-specific extensions may be required (e.g. platforms that support multiple calling conventions, such as Windows), but the binding could be defined in an extensible manner, and such extensions could be standardised for all the major platforms. One might also need to provide an object-oriented binding for those platforms where object-oriented APIs are prevalent (e.g. COM on Windows, Objective C on MacOS/iOS), but again the cores of these OO technologies are similar enough that a common extensible binding could be shared between them, with some small platform-specific extensions. A single CDM could operate on multiple platforms by dynamically determining what platform it was running on, and then invoking the appropriate native services for that platform.
Let me respond to one piece of this. Although Flash does include a VM, the VM is largely irrelevant to the functioning of the Flash DRM (Adobe Access). The VM is just the mechanism for exposing the Adobe Access methods as ActionScript. In an EME world, the JavaScript VM would serve this purpose and the EME methods specified would be the interface to the underlying Access CDM functionality.
(In reply to comment #0) > A platform-independent VM could be included either by > reference to an existing standard (e.g. Java or .NET) or by > defining a new VM. I object to using DRM as a pretext to make the Web Platform dependent on a massive additional execution environment that's strongly affiliated with a single vendor (Java, .NET or NaCl). The Web already has a standards body-defined VM that has multiple independent implementations: JS. > If a single VM cannot be agreed upon, > another option would be to allow several different VMs. That's not particularly great compared to several different CDMs. > If a new VM was to be defined, one approach would be to use > ECMAScript + Typed Arrays as the VM. This would be > advantageous in that many browsers already have very good > ECMAScript VMs. Using asm.js (http://asmjs.org/spec/latest/) in a Web Worker with a special-purpose global scope that provides integration points into the <video> pipeline would make much more sense than relying on Java, .NET or NaCl. asm.js performance as implemented in OdinMonkey is currently roughly half as fast as native compilation of the same C code, so the performance of asm.js is already in the Java/.NET ballpark. > A binary encoding for ECMAScript (or a > subset thereof) could be defined to help satisfy CDM providers' > concerns for obfuscation. Existing browsers could easily > translate this binary encoding to standard ECMAScript, or bypass > the textual representation and convert it directly to their own > internal representations of compiled ECMAScript. Gzipped JS is an easily translatable binary representation of JS. Another binary representation is not worthwhile, because if the mapping from the binary representation to the normal representation is known, it wouldn't really provide true obfuscation, as it would be possible to provide tools that translate the primary representation to the normal representation. > Any CDM implemented on a platform-independent VM will > inevitably need to access native services. If the input the the Worker is the bytes of an ISO Common Encryption file and the key messages of the nature outlined in EME, the output can be buffers representing frames or audio samples without any access to native services.
Discussed on the telcon: http://www.w3.org/2013/02/26-html-media-minutes.html This is one proposal for how to deal with CDM interop. Making a duplicate of 20944, which addresses this issue. Note that the task force disagrees with the notion that the purpose of EME is to replace existing DRM solutions. *** This bug has been marked as a duplicate of bug 20944 ***