[pornel]

The EME spec is a useless junk. It describes a fictional architecture that no browser has implemented. It's not possible to use it for any actual DRM implementation — if it was, it wouldn't be DRM! The authors of the spec are on the record saying they would never use the implementation described in the spec.

The real specs that all the browsers and media vendors used for DRM are vendor-specific closely guarded secrets, as they have always been.

The only purpose the spec ever had was laundering DRM with W3C's reputation.

[charcircuit]

???

Pretty much all streaming companies of DRM protected content use EME with Widevine as the CDM. How is it useless if everyone is using it?

[pornel]

Because it's not relying on the EME spec. If you want to use Widevine, you have to sign an NDA with Google and use their proprietary spec for it. Exactly like you'd have if EME did not exist.

The EME spec only documents how to use a "Clear Key" scheme that is a complete trash defeated in 1 line of code, and of course not allowed by any website with DRM.

The EME spec says nothing about Widevine or any real-world DRM API. The CDM side, that does 99.99% of the actual work, is not documented in the EME spec. It's only a hypothetical construct alluded to in the spec, but not an actual API. The actual browser implementations don't even use the architecture outlined in the EME spec. Almost all of the EME spec is non-normative, or for the decoy Clear Key non-DRM.

EME is like a spec that says Adobe Flash is <object type="application/vnd.adobe.flash" />. There, Adobe Flash is now an open web standard. You have everything you need to handle .swf files without plug-ins, except the content playback module, which is a detail left for each vendor to figure out.

[peaBerberian]

I get what you're saying about the implementation of the CDM internals not being documented, but to me - a MSE/EME player developer - it seems that the main chunk of the Encrypted Media Extension API does also apply when Widevine, PlayReady and so on are used.

The user-agent is still relying on the same interfaces and concepts (MediaKeySession, key id, same events, same methods, same way to persist licenses) and the application generally can work transparently without doing exceptions for each key system (well, in reality, there are a lot of compatibility bugs in a lot ot EME implementations, but those are not on purpose).

For example the server certificate concept generally does not apply to clear key implementations at all but is frequently used when using Widevine.

Clearkey is thoroughly documented because that is the only key system that SHOULD be implemented in all user agents with an EME implementation, though nobody, even the writers of that specification, think that it is a good idea for real production usage.

In my work we rely a lot on the EME specification, and refered to it many times in exchanges with our partners when we thought that their CDM implementations (e.g. on specific set-top boxes, smart tvs, game consoles etc.) lead to non-compliance to that spec (e.g. unusable keys not being properly announced etc.).

_PS: off-topic but I came across your projects and comments online many times, IIRC mostly about image encoders / decoders and on Rust (both subjects on which I love to read). That was always very interesting, thanks!_