Re: Encrypted Media proposal: Summary of counter-proposals

I like this idea a lot. It introduces a generic way to plug extensions into the video and image (and presumably the audio) element with functionality that is chosen through extra mime type parameters. I would, however, suggest not to use "audio/mpeg+keysystem" as the mime type, but rather mime type "audio/mpeg; keysystem=xxx".

Silvia.



On 09/03/2012, at 7:45 AM, Charles Pritchard <chuck@jumis.com> wrote:

> TL;DR: This document includes my TL;DR recommendation, a summary of three proposals, and ends with a longer recommendation.
> 
> We are here, and it's contentious:
>    var video = document.getElementById("video");
>    video.generateKeyRequest("org.w3.clearkey", null);
> Let's go here:
>    var video = document.getElementById("video");
>    video.getContext('experimental-ecmd').generateKeyRequest("org.w3.clearkey", null);
> "Encrypted Media Context Draft".
> 
> At issue is proving that getContext is appropriate for HTMLImageElement and HTMLVideoElement.
> Beyond that, the item can be developed through a different outlet than public-html.
> 
> Hixie's "enc:*" proposal has merit. It does not solve the full problem, but it is an improvement on current web operations with respect to CDN usage.
> 
> The Encrypted Media Extensions document has merit. Key systems should be added to the mime type. There's no point in telling a user that they support the mime type but not the key system.
> This does nothing: "DOMString canPlayType(in DOMString type, in DOMstring? keySystem);"
> This makes more sense: "audio/mpeg+keysystem"
> 
> The encrypted media extensions document should be examined from the perspective of supporting encrypted images in addition to HTMLMediaElement.
> 
> The long reply is in thread.
> 
> 
> -Charles
> 
> On 3/7/2012 2:08 PM, Mark Watson wrote
>>> >  My issue with Hixie's side is that it does not try to or want to address the idea of isolated media playback, as found in some devices; and my issue with the other side, is that the use case focuses solely on DRM content of publicly accessible media -- there's no concern for actual media security, just DRM as it applies to content distributors.
>>> >  >  If Netflix can not do the work to reach-out beyond their own use case, and examine Encrypted Media for secured communications, then that's a real let-down. I'd say the same to Hixie; if a method is not available to marshal data through the OS for hardware-based encryption, that's a real let-down.
>> That all seems fair enough to me. I've no objection to talking about additional requirements (such as fully secured communications, as you say), just an objection to excluding requirements that are important to us.  This side-thread started because Henri asked about the motivation for ISO Common Encryption.
> 
> That's good to hear. So let's move forward with these threads.
> 
> For counter-proposals; I've noticed two schools of thought.
> 
> SCHOOL 1:
> a) Add a protocol/uri layer; such as prefixing "enc:<string>:" on http and other URLs when accessed via Media elements.
> It was introduced as: "http+aes:"
> 
> An example of this [extension] methodology is: "blob:". Blob works well these days. The "web+" prefix has been rather iffy; the FileSystem API brings in "filesystem:" in practice, but it's actually up to the implementer.
> 
> The enc proposal is intended to make serving encrypted content over clear HTTP connections easier on developers. Currently, developers must use various techniques with XHR and ArrayBuffer to handle encryption on their own. At the end, the developer either creates a blob: uri or is working with the media source API.
> http://html5-mediasource-api.googlecode.com/svn/trunk/draft-spec/mediasource-draft-spec.html
> 
> Once passed to the Media element, additional processing can be done via stream processing APIs and CSS:
> (in Short)
> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/webrtc-integration.html
> Full specs.
> http://www.w3.org/TR/streamproc/
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
> 
> This proposal enables:
> Uploading encrypted data to an untrusted service, referencing it in static documents.
> 
> This proposal permits:
> The full media processing pipeline.
> CSS based and DOM based fallback mechanisms.
> 
> This proposal may be deprecated in part:
> By dynamic documents, where the scripting environment can otherwise handle cryptography and assigning blob uris.
> By a proposal which includes additional block ciphers, or key methods such as "enc:keycard:" "enc:blowfish:".
> 
> This proposal does not address:
> Client/server key and encryption negotiation/methods.
> Isolating media playback from the UA, through hardware-based playback or other means.
> 
> 
> SCHOOL 2:
> b) Move the Encrypted Media Extension from the HTMLMediaElement interface into a sub-context, accessible through HTMLMediaElement.
> This was introduced as "generalizing" the Encrypted Media Extension interface.
> 
> This method has been used with some success with the HTMLCanvasElement, using "getContext" to access extensions.
> The 'webgl' extension has been able to grow under the getContext auspices without much controversy.
> 
> An HTMLMediaElement getContext method would enable a general access point for Media Element extensions.
> 
> The Encrypted Media proposal would be moved into its own IDL, instead of extending HTMLMediaElement
> and could be accessed via a getContext method call.
> 
> This proposal permits:
> General extensions to HTMLMediaElement.
> 
> This proposal does not address:
> HTMLSourceElement selection.
> 
> 
> SCHOOL 3:
> Circling back to the Encrypted Media proposal:
> 
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
> 
> This proposal enables:
> Selection of HTMLSourceElement with key system selectors.
> 
> This proposal permits:
> Isolated media playback and scripted negotiation of encrypted media.
> 
> This proposal does not address:
> Referencing encrypted media streams from static documents.
> Container-specific decryption modules.
> 
> 
>>> >  It seems we've all agreed that HTTPS/TLS is great, but that we want something more agnostic to the networking protocol.
>> Actually, we find HTTPS to be a bit of a pain. At least for delivering the media itself it's much simpler operationally - and cheaper when using third party CDNs - to use HTTP with encrypted files (files distributed in thousands upon thousands of CDN edge caches are in practice going to be accessible to a fair number of people. Even if only the CDN employees, thats quite a few. For a CDN to ensure these are secure - as they would have to if they were in the clear - requires work on their part).
> 
> 
> I also find it to be a bit of a pain. An extra layer of encryption never hurt anyone. And yes, passing around encrypted data means that caching of secure content is a real option.
> HTTPS is great for isolated transactions. Passing around account information, secured web app usage. But for broad content distribution and/or "mesh" style distribution, encrypting the content itself makes more sense.
> 
> As I've said: we have consensus on this issue. HTTPS/TLS does not serve the full needs of "secure communication"/"media encryption". Because it does not serve those needs, we're looking at proposals to extend existing mechanisms.
> 
> Hixie has proposed a client-side extension to uris, "enc:"/"*+aes:". I've noted that these can be accomplished with Web Apps APIs and JS, to some extent, but not in static documents. Other's have pointed out that the "web+" scheme was not properly vetted; the "http+" scheme may suffer a similar fate. However, an "enc:" prefix seems quite tolerable in the long run if consensus can be gained. "enc:<string>" and/or "enc:format:<string>:" as a prefix seems like a very good thing over the long term.
> 
> Hixie's proposal does not address hardware and OS-level encryption mechanisms. So, while there is absolutely value to it, it is not a complete solution to media encryption.
> HTTPS/TLS is a complete solution, but it's an unsatisfactory one with current/pragmatic CDN usage. Like Hixie's proposal, it does work with static documents.
> 
> We're looking at dynamic documents and OS-level messaging which in some sense, puts us in the realm of webapps APIs.
> It may be the case that a general key system would apply to streams beyond <audio> and <video>.
> They may apply to <img>, or to <canvas>, for example.
> 
> 
> 
> My recommendation:
> Move the proposal from "partial interface HTMLMediaElement" to its own context: "[NoInterfaceObject] interface EncryptedMediaContext1Draft"
> Add "getContext" to HTMLMediaElement and HTMLImageElement via partial interface.
> Add the behavior "getContext('experimental-ecmd')" to connected to EncryptedMediaContext1Draft.
> 
> Instead of adding a key system attribute to HTMLSourceElement, use the type attribute.
> It's needed anyway. It really is part of the type.
> 
> Example:
> <source src="/path/to/media.mp4" type="audio/mp4+myKeySystem">
> 
> Within this context, only one item needs to be introduced to HTML interfaces; the getContext method, adding it to Media and Image.
> The Canvas element already has such a method.
> 
> 
> -Charles
>

Received on Thursday, 8 March 2012 21:19:47 UTC