Encrypted Media proposal: Summary of counter-proposals

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 20:45:40 UTC