Are you aware of any plan to standardize the API/ABI of the CDM modules. It would be possible to do this without exposing content as the current proposal (EME) just specifies the existence of an API for passing around CDM specific data, such as initialization data derived from streams.
It may actually make sense to specify this API/ABI outside of the EME spec, such as through WHATWG. Having a small footprint in the API/ABI might help assuage fears that this is a backdoor to general DRM in HTML5.
Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document.
Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system.
It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams.
We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones.
Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does.
But later, Stallman said something that I found very surprising. He said that he has no problem with the firmware being burned into the hardware (via a ROM chip or the like). He said that he wanted a “black box”, and it’s obvious that he has no problem with proprietary firmware as long as it’s permanently embedded in the hardware rather than being loaded into it at boot time.
]
Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document.
Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system.
It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams. We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones.
Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does.
[EDIT: I found the reference I used for the comment about RMS, this is the quote from and article based on an interview with him (at http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-a...):