w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
180 stars 80 forks source link

Bug 20944 - EME should do more to encourage/ensure CDM-level interop #192

Open paulbrucecotton opened 8 years ago

paulbrucecotton commented 8 years ago

Moving from Bugzilla (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944):

The current EME draft makes no attempt to encourage interop at the CDM level. For example, the current EME draft does not forbid or even discourage a UA vendor from promulgating a CDM that no other user-agent can support, and encouraging the creation of content for that CDM consumable only by that user-agent. Such an outcome would be antithetical to the mission of the W3C, and the W3C should not bless, appear to bless, or enable such scenarios.

...

paulbrucecotton commented 8 years ago

The HTML WG (predecessor of the HTML Media Extensions WG) was told that specifying characteristics of a CDM (ie generic license request/response protocol) was out of scope of the WG's media charter scope. See minutes.

Since this request would fall into the same area which is beyond the current HTML Media Extensions WG charter, we will mark this issue with Milestone VNext.

/paulc HTML Media Extensions WG Chair

jokeyrhyme commented 7 years ago

WebAssembly might be an interesting avenue to pursue in terms of interoperability. Once support is widely available, could we consider requiring CDM implementations to be provided in WebAssembly format?

This format is already showing promise in areas of video encoding / decoding, which in my naive appraisal would have similar performance requirements to other CDM functions:

https://hacks.mozilla.org/2017/02/webassembly-will-ease-collaboration-on-next-generation-video-codecs/

This would at least allow consumers to continue to use any device with a WebAssembly implementation, instead of only the devices that CDM vendors care to support (or are allowed to support).

mwatson2 commented 7 years ago

@jokeyrhyme The more general idea of specifying a virtual environment in which downloaded CDM code could run has been previously discussed (a little) here.

In order for the virtual environment, be it WebAssembly or anything else, to be suitable for running a DRM component, it needs to be robust, in the sense that word is used in conjunction with DRM. That means there must be a way for the downloaded DRM component to prove to the site that it is running within a robust virtual environment with certain properties around non-user-modifiability, security for the decrypted content etc.

It is certainly possible to imagine such a thing, for example for the virtual environment to have a key pair which can be used to sign attestations as to the environment itself and the downloaded code it is running.

I'm now aware of any projects of this nature.

mstattma commented 7 years ago

I don't think that it's feasible to expect a virtual environment to be able to implement anti-debug and data obfuscation mechanisms (i.e. can be robust as a DRM is required to be) without being a DRM itself. See a still valid overview here: https://www.w3.org/2000/12/drm-ws/pp/cloakware.html.

However (and noting that hardware dependency isn't favorable), there is a hardware based solution for that available on Intel CPUs: https://research.kudelskisecurity.com/2016/08/04/black-hat-talk-on-sgx/

gvlx commented 7 years ago

It would be interesting if some members of this WG could attend this webinar: "The Native vs Downloadable DRM Debate" .