DRM In HTML5 — Better Than the Alternative?

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.'"

Comments

What's the difference?

[Hatta]

Neither can be used on a free platform, so what's the difference? How are platform specific encryption modules any better than platform specific native apps?

Re:What's the difference?

[gl4ss]

Browser components, surprising how many applications require them. once this is in will it create other unforseen content controls?
Also I can't wait for the first client side security vulnerability.

the way I see the html5 drm thing right now is like this: some dudes who would gain something from it are pushing it after having a conversation that went like: "ah darn it, ain'nt anyone doing plugins anymore, 'dem plugins have soo bad reputation. We should design a platform for running closed source code inside browser! and make it html5! and with hooks!"

point being, I don't see it fixing anything in the current system. they could just implement plugins with the old plugin system for things they want to run closed..

Re:What's the difference?

[blackiner]

http://www.w3.org/TR/2013/WD-encrypted-media-20130510/#introduction

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?

[magic maverick]

Exactly. I won't be able to see restricted media on my system anyway. Because DRM - digital restrictions management - don't work without locking you out. It doesn't matter if it's an "open standard" or not. And, as noted in the article, this HTML5 thingy doesn't even provide an open standard for DRM. It provides hooks. That's it. The DRM will still be closed, will still not be a standard, and will still probably not run on open systems (most desktop Linux).

And the W3C should have taken the pragmatic approach and said, "we don't want DRM to be associated with us, as it will tarnish our good name".

This "standard" won't make things any better, because there will still need to be a closed blob to decrypt the restricted media. Whether it's viewable via a web browser, or not, is irrelevant.

Re:What's the difference?

[blackiner]

And now they have paved the way for allowing only Microsoft and Google owned and patent encumbered DRM schemes. What progress.

Re:What's the difference?

[Cajun Hell]

If the web does not have DRM then consumers can only use services like Netflix where Netflix deigns to create an app (plug-ins are on their way out).

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.

If DRM is a standardized part of the web then anyone with a standards compliant browser can access those services.

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.

I want the choice to be able to stray beyond the dominant platforms and still use Netflix.

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! :-)

Oh the horror!

[maxwell demon]

There would be content on the internet that is not on the web? Oh the horror! </sarcasm>

Seriously, I want them to provide their own programs for DRM-protected stuff. That stuff just doesn't belong on the web. After all, even if it were made with HTML5+DRM and accessed through web browsers, it would still not really be part of the web, because I could not just fire up any web browser and watch it; I'd first have to install their proprietary DRM. So what is the big difference, if I have to install some proprietary code anyway? If it's a separate program, I'll at least know up front that it's not part of the web.

Also, in my experience, native programs tend to have the better interfaces anyway.

Re:This is retarded.

[BasilBrush]

Have they not learned that DRM only hurts the honest people? The pirates will get their crappy content anyways.

This is a false dichotomy. Whilst there are people that only ever use legally acquired stuff at one end of the scale, and people that always pirate non-free stuff at the other end, the vast majority lie in the middle of those extremes, pirating if it's easy and the result is good enough for them, buying when that's easier, or has the quality they require and is within their budget.

DRM doesn't come free for the industry. It would be cheaper to ship without DRM than with. The areas where DRM doesn't help the media industry's bottom line, such as songs, has already been abandoned. Areas where they keep investing in DRM, they do so because it works well enough to raise their bottom line vs not doing it.

If it didn't work, they wouldn't put money into it.

Re:DRM should not be standardized

[devent]

EME is not a standard of DRM. EME is a standard to access DRM via API. That is a very big difference.
_If_ EME would be a standard of DRM, then anyone could implement the DRM and see the videos.

But EME just make the API standard do access DRM to decrypt the content. DRM can not be standardized, it's the very nature of DRM.