Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

EME does not require Widevine; you can implement EME in its entirety yourself, in open code.

Widevine is only one of several implementations of a Content Decryption Module; it just so happens to be by far the easiest to license (though that doesn't mean that's easy!).



> you can implement EME in its entirety yourself, in open code

Noope. Netflix has explicitly stated, at W3C, that they absolutely won't use any open EME implementation.

In practice any open CDM that you implement yourself will be totally useless. The "open" parts of EME have no real utility, and exist only to be able derail criticism by making rhetorical arguments about hypothetical open implementation, even though it's by definition exactly the opposite what Netflix and Google designed EME for.


That's Netflix blocking you then, not Google.


An EME implementation is not complete without a decryption module. And getting one is the problem here.


So could I write a custom Content Decryption Module that would be able to decrypt Netflix content? Or would the content providers have to support my custom Content Decryption Module?


A website can decide which Content Decryption Modules it would like to support, because ultimately the site runs the keyservers and can decide which CDM's keys it would like to generate.

But EME includes a fully freely implementable Clearkey spec. Ultimately sites generally don't want to generate keys for it, but it can be done.


So... I can technically implement my own EME standards compliant web browser, but that browser won't actually be able to interoperate with the existing set of websites that make use of EME. What's the point of the standard again?


1. To serve Hollywood's delusion that DRM is useful

2. To create market barriers for anyone who wants to compete with existing streaming services like Netflix, Spotify, and Youtube Premium

3. To create market barriers for anyone who wants to compete with Chrome, Safari and Firefox

4. To replace old proprietary plug-ins from Adobe and Microsoft with new proprietary plug-ins from Google et al.


Certainly complying with EME isn't enough for web compatibility, but EME plus any given CDM isn't in reality interoperable either: sure, Firefox and Chrome both use a Widevine CDM, but Safari and Edge do their own things. As such, in principle a website could easily not support Safari and Edge (given you get the two larger browsers with one CDM).

To be fair, you can make a similar argument about what's the point of a standard for the video element: in reality, you need to support H.264 encoded video, so just supporting Ogg/Theora/Vorbis (as some early implementations did) doesn't suffice, so what's the point of that standard? (Also the img element, the object element, etc.)

But yes, EME is different because it fails to fulfil its use-cases in a fully free implementation (one can imagine, potentially in the future, a free software implementation that passes encrypted content to a hardware module that implements the decoding, but that seems like little gain and unlikely to happen).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: