DRM In HTML5 — Better Than the Alternative? 268
Underholdning writes "DRM is coming to HTML5. The W3C published a working draft yesterday of the framework that will support the use of DRM-protected media. Ars Technica's Peter Bright reports on it with an article claiming that DRM in HTML5 is a victory for the open web, not a defeat. Bright argues that if HTML5 does not support DRM, then content providers will move their content away from open standards and implement it with native apps — abandoning the web in the process. Quoting: 'Keeping it out of W3C might have been a moral victory, but its practical implications would sit between slim and none. It doesn't matter if browsers implement "W3C EME" or "non-W3C EME" if the technology and its capabilities are identical. ... Deprived of the ability to use browser plugins, protected content distributors are not, in general, switching to unprotected media. Instead, they're switching away from the Web entirely. Want to send DRM-protected video to an iPhone? "There's an app for that." Native applications on iOS, Android, Windows Phone, and Windows 8 can all implement DRM, with some platforms, such as Android and Windows 8, even offering various APIs and features to assist this.'"
Re:What's the difference? (Score:5, Informative)
Pretty much everything in the picture is standardized and can be implemented by any browser, but the Content Decryption Module (CDM) can be anything, and is selected by keySystem from the DOM data. There is a single reference system that merely decrypts blocks of the stream. But you can pretty much just dump the decrypted blocks into a file. I'm sure all this will really accomplish is requiring people to download proprietary CDMs, or only allow browsers that ship with them like IE or Chrome to play content. This is a shit solution.
Re:What's the difference? (Score:4, Informative)
Re:What's the difference? (Score:5, Informative)
But what is being proposed, is identical to that. Consumers will only be able to use services like Netflix where Netflix deigns to create an implementation of their proprietary EME plugin.
This is where the confusion lies. Nobody is suggesting making DRM itself a standardized part of the web; you're rooting for a side which isn't in the fight. They're talking about making a non-standard DRM component (something just as unportable as Flash and Silverlight, and subject to its ONE CREATOR'S whims) have standard API for the browser to use. This is a tiny little issue; Flash already used a defacto-standard API for the browser to inferface with. Such a defacto interface isn't maybe as good as a well-described one, so you could see this new API as a minor step forward, but it comes with the cost of legitimizing and endorsing something which is just completely ridiculous.
That is not being offered by this HTML5 compromise, and it won't get you closer to that. If Netflix, as the one and only party in the world who will have the closed trade secret to make the Netflix decrypter, should decide to ever see fit to allow the specific non-dominant platform that you're thinking of, to join the list of platforms they support by making a Netflix plugin for it, they're just as likely to decide to allow an app on that platform.
Allowing you to watch Netflix, is not something that is being standardized. That aspect would remain as closed as Flash's DRM. This is how all DRM must always be. The only way Netflix can ever be standardized such that you will be permitted to use it on a device of your choosing, is if they drop the DRM.
Or if they were to standardize the DRM itself, I suppose that would work. But they wouldn't want to do that, since the whole point of DRM is to keep people from implementing it! :-)