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
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?
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?
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.
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 email@example.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 firstname.lastname@example.org
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