Traditional DRM systems are complete stacks: app framework, DRM, file formats, etc all for one client endpoint. E.g. netflix only supported on silverlight, so only on desktop. Using the <video> tag we want to expand the web platform to allow such use-cases across the web.

Overview preso of how EME works: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Current status: last call working draft (?)

Desktop impls: IE (prefixed version, current spec), Chrome (prefixed version, older spec), and shipping in millions of TVs?. WebKit? has an implementation and some things are exposed in Mavericks. Opera & mozilla haven't said anthing. YouTube?, Google Play, and Netflix are shipping content using EME. ChromeCast? also supports EME for some contents.

What is the point of all this if the DRM impls are separate from EME? Generic API to use it, but specific impl in browser is still need.

CDM conceptually separate from the UA; sometimes built into the HW/OS platform, so we need to talk to them. Unlikely to define DRM that everyone will agree to, so using the HW-provided option is best opportunity. Main goal is to reduce the protection stack to as little as possible. E.g. do licensing/keying/etc in CDM, but the rest happens in the open. Media at rest is encrypted with a single set of keys, UAs? just need the right key for the appropriate license server. Important bit is that the different DRMs? can share the same media.

Walk through of the main interaction flow between the browser's media stack, the JS application, and the CDM: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#introduction

MS is doc'ing how to integrate PlayReady? into EME; WideVine?'s integration impl is open-source in chrome.

does the canvas get tainted by EME?

Spec is non-normative on this point; browser's choice.

wouldn't it be more appropriate to use canvas's cross-origin write-only protection?

currently that's a quality-of-implementation concern. Some platforms' pipelines don't allow the pixels to be read back. Impl detail.

MediaKeys? object is the parent of all EME interaction MediaKeys?.createSession() creates MediaKeySession?, which models the interaction with the JS application (license requests, key insertion, etc).

EME with MSE: when you appendBytes() does EME tell you whether the bytes are encrypted, or what?

crypto bits are in the container, so if you can parse the container headers you can know what's going on.

Spec has a lot of container-specific guidelines; these are non-normative. DASH.js has MS patches for EME.

are there efforts to have a unified JS library for parsing containers?

ideally there would be such a library. Right now would be tricky b/c implemented APIs? are quite different (IE11? has newer version of spec, Chrome still needs to catch up to spec updates)

interface to the DRM subsystem: are there any efforts/ideas to standardize this? (to avoid every browser having to impl every CDM's APIs?).

Assumption is that browsers will have a short list of CDMs?. One of the security & privacy considerations is that browser vendors are responsible to vet CDMs? to ensure they fit into security/privacy models (since they're binary blobs and thus scary). Additionally, HW usually includes at most one such block. So a given browser on a given platform is unlikely to support many CDMs?. Previous proposals & open bug on interop ponder a uniform CDM API, and/or "enforcement" of such uniformity, but ... MS is writing up / open-sourcing instructions for how to integrate platform-specific HW for apps. Widevine APIs? for Android & desktop are checked into chrome.

Content publisher needs to encrypt depending on the CDM of the device where they're delivering to?

streams are the same (mod codecs/containers), but license server is per-CDM.

how can this be?

"Common Encryption". WebM? & ISO have a key ID field, the request for the keyid is CDM specific, but the key, once gotten, can be applied to the (singly-) encrypted media regardless of CDM system.

There's no standard for CDM APIs?; even the widevine API (which is open-source) has been evolving, so clearly too early to standardize.

are there use cases for "normal" web developers (not the youtubes/netflixes of the world)

Kaltura gave examples of concurrency/renting agreements for educational uses, enterprises have restrictions on redistributions (for confidentiality), etc.

Would be nice to have a single CDM system, but not happening. There is a ClearKey? CDM that is open-source, and its API is spec'd (and required). This might change in future.

who's using this (in the room?)

netflix & youtube using it, kaltura looking at it.

is the widevine server compatible with EME?

the legacy widevine server doesn't support EME. They have a new server for EME. Unclear what availability is for non-netflix/youtube/google-play use cases. Contact widevine@google.com to learn more.

does this work with any existing DRM system or just some subset?

some DRM systems rely on the transport layer using TLS, which is incompatible with EME, as is origin-based protection (they are orthogonal to EME). Adobe's doing something but not sure what. As long as messages are passed through browser there's nothing specific to playready or widevine.

if I wanted to try this out today it would be difficult for lack of server?

ClearKey? can be used to test the API/interactions/etc. YouTube? has used this for development. There should be test servers (in the future). It's possible to write your own server for widevine CDM but you probably don't want to do that. Email widevine@google.com

could you do a client-side impl of ClearKey? in JS?

Yep; demo: http://simpl.info/eme/clearkey/src/ (source at https://github.com/samdutton/simpl/tree/master/eme/clearkey)

Bug tracker & public mailing lists are linked from https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html