API to add wasm packaged CDM

[AMorgaut]

As of today, serious OTT video providers need either:

• to have back-ends providing different decryption keys for at least one supported Content Decryption Module (CDM) per browser, meaning they usually have to support at least(1) :
  • Google Widewine
  • Microsoft Playready
  • Apple Fairplay
  • Adobe PrimeTime (facultative, only for legacy browsers)
• to deliver an external player plugin/app using a specific drm technology (Cisco, Verimatrix, Nagra, ...)

(1) cf https://drmtoday.com/platforms/

It happens that sometimes, such plugin/external app decrypt their video in an HTML5 canvas and either kind of reinvent the wheel by polyfilling the HTML5 video element API or providing a vendor specific API.

With Web Assembly, I'm kind of seing a path to make them provide compiled cross-platform decryption modules.

They could try to port these whole player app/plugin via EMScripten, potentially via EGL Support in Emscripten or something similar, and some will probably do it in the end.

Wouldn't it be way more efficient if we could just have an API to register vendor provided wasm Content Decryption Modules usable directly via the native HTML5 player?

[AMorgaut]

By the way something that could be interesting when I see some discussions about EME concerns, is that Web Assembly CDMs would be meant to be sandboxed, of course with a potential performance cost, but still.

When I see that we now have some implementations of SharedArrayBuffer with Canvas WebGL contexts (ex: https://bugzilla.mozilla.org/show_bug.cgi?id=1147441), I'm pretty optimist we could have quite good enough performances

[mwatson2]

The idea of a virtual environment within which downloaded CDM code could execute is an interesting one and would indeed simplify things for service providers. It has been discussed here before (#166).

As noted there, though, the challenge is the issue of robustness. Just as service providers require an assurance that the CDM code executing on the client is indeed the thing they expect it to be (and will thus behave as they expect it to), they would require assurance that the virtual environment was indeed the thing they expect it to be and would behave as they expect it to, specifically with respect to the handling of the decrypted decoded content.

As far as I understand it, addressing this robustness aspect touches on many of the issues which caused us to leave the CDM out of scope of this activity, but it is certainly an interesting future direction if there are real proposals.