TL;DR:<p># <i></i>Myths<i></i><p>1. that DRM doesn’t work; that it exists to protect creators, but since it is easily cracked and can be worked around, it is largely ineffective and irrelevant<p>2. that DRM in HTML5 is a necessary compromise to finally bring an end to the proliferation of proprietary browser plugins such as Adobe Flash Player and Micrisoft Silverlight<p>3. that the web needs DRM in HTML5 in order for Hollywood and other media giants to finally start giving the Web priority over delivering media over traditional means<p># <i></i>Reality<i></i><p>1. DRM is not about protecting copyright. That is a straw man. DRM is about limiting the functionality of devices and selling features back in the form of services. (<a href="https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2" rel="nofollow">https://plus.google.com/107429617152575897589/posts/iPmatxBY...</a>)<p>2. DRM in HTML5 doesn’t obviate proprietary browser plug-ins, it encourages them.
(<a href="https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-out-w3c-standards" rel="nofollow">https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...</a>)<p>3. The Web doesn’t need big media; big media needs the Web.
(<a href="http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc-attacks-the-open-web-gnulinux-in-danger/index.htm" rel="nofollow">http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc...</a>)<p># <i></i>So sign the petition<i></i><p><a href="http://www.defectivebydesign.org/no-drm-in-html5" rel="nofollow">http://www.defectivebydesign.org/no-drm-in-html5</a>
Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards.<p>There is nothing to be won by resisting hooks for DRM in the browser however appealing it seems to take a principled stand. The content suppliers will gleefully go with native apps, flash, silverlight, even Emscripten-cross-compiled codecs. With content consumption going mobile, the push for native apps is even stronger.<p>Really, all you'll do by resisting this, is teach the majority of consumers who don't know any better that the Web sucks, and all of the enjoyable things they want are to be found on iOS or other proprietary locked down distribution platforms. That if you want apps that deliver the stuff you are interested in, you have to look outside the web.<p>Back when Chrome proposed dropping H264 support, I was infuriated, even though I fully support WebM as the mandatory to implement codec. I don't think "purity" really serves the platform, flexibility does, and the best way to register you don't like DRM is to simply stop consuming any and all media which uses it. Not just Web media, but <i>all</i> media that's DRMed.<p>A DRM free HTML5 spec is not going to force Hollywood to allow you to play Games of Thrones on your open source Linux browser.
I can't believe that DRM is even on the table. It's ONLY purpose is to prevent third parties from accessing content, which is pretty much the antithesis of the web and open standards.<p>For me, what it all comes down to is this: HTML5 is supposed to have open standards, so if I implement those standards' specifications in my own web browser, I expect to be able to view and use websites that are HTML5-conformant.<p>If DRM goes through, this is what will probably happen: Internet Explorer and Google Chrome (two closed source browsers) will definitely implement it. Opera might implement it (who really knows what they'll do?). Chromium and Firefox probably won't implement it. DRM content will likely only be viewable on those two browsers, and only on a supported platform. If you use Firefox on Linux Mint, you're SOL. If you developed your own web browser, you're SOL. Even if you use Firefox on some closed source operating system like OS X, you're SOL.
My take is that Google in particular likes this development (though are probably trying to stay away from it publicly for political reasons) because it allows them to easily (ie. with studio blessing) pilot monetizing their vast YouTube-watching userbase by offering paid content services and user profiling far beyond what is available on cable networks (eg. by selling 'anonymized' matches of consumer viewing behaviour in conjunction with email, location, sleeping-schedule as determined by a cross-section of Google services, etc.). Existing Google projects and their recent significant investment in video (patents, new LA offices, Android 'Smart TVs', ChromeOS Google Fiber) all look like they will benefit from this type of development. With all due respect to people who work at Google, please consider protesting internally in parallel to this public effort, or leaving.
Back in the real world, the web is not inevitable. The alternative to HTML5 DRM is for vendors to turn away from the web and HTML5 altogether.<p>The web is still open by default, versus other platforms being closed by default. The best architecture is to support fine-grained plugins with well-defined semantics than just some big black box <object> element that could be running anything.
What is the complaint. It isn't clearly summed up here.<p>Noone will force you to use DRM on your website. Noone will force you to browse websites that use DRM.<p>What do you care what others choose to do with their sites and content, unless you believe you have the right to access everything everyone creates, in an unrestricted fashion, for free, in perpetuity.
This is because all you dummies were too busy lauding Google's services and nobody notices how "evil" they are.<p>This came as a proposal from Google. It was tested in Chromium first. The DRM is essential for their "World-saving" ChromeOS that nobody really cares about.
It appears that the spec for EME doesn't provide a mechanism to reliably detect decryption failure, this will be inconvenient to end users. This could be alleviated by adding a mandatory tag that includes a hash of the decrypted video for verification purposes, to be tested by the client while streaming the content. If the hash is missing or incorrect the media must not play.<p>The Tiger Tree Hash system is already being deployed for this purpose in other systems.
The W3C must ultimately do what it thinks is in the web's best interest. Not the interest of big media companies, or the interest of those against DRM. If they implement a system by which DRM can be reasonably added to the spec to bring those users and companies into the fold, I don't think I'd have much to call them out on, even though I don't like DRM. That bone is to be picked with the media companies themselves.
Consumers don't care about DRM or No-DRM they care about convenience. Large players do not care about technology either they just want control over their market. Under this circumstances the question is what stand should W3C take ?<p>Should they try to keep web as open as possible or should they play to the tunes of Google and Microsoft and introduce features that benefit them.<p>As I see it, web standards should be as open as possible.
Why are optional WebIDL bindings really any different than NPAPI bindings? foo.getDRMStream() is bad, but document.getElementById("drmpluginelement").getDRMStream() is somehow fundamentally better?<p>Seems like mostly a distinction without a practical difference. Some browser platforms won't be able to ship with the bindings for this, likely the same browser platforms that can't ship the NPAPI plugin.
Whether or not Encrypted Media Extensions(EME) is included in HTML5 SHOULD NOT be construed as a referendum on DRM. The HTML5 standard is not the place to determine if something is ethically/morally good, advancing humankind, or will even work.<p>If some orgs or people want a means to retrict the playing of media in HTML5 by downloading keys from a license server then so be it. The HTML5 standard should be as inclusive as it needs to be to represent the needs of all parties. If enough parties desire this functionality then who are we to say they cannot or should not have it.
I can't read the article, probably a HN DOS.<p>However, I really can't see the point of doing DRM in html5, it will just result in browsers becoming the equivalent of the evil plugin everyone hates(only certain browsers/platforms will be able to run the content).<p>Why not just leave html5 video open, and let those who wish to distribute DRM'd content build their own client-side players for the OS's they wish to support. Or let them build apps on top of Adobe AIR or Silverlight out of browser.
Just wondering, is there any provision in any OSS license (or scope to add one) that prevents the code being used in any DRM software or firmware?<p>I know it wouldn't act retrospectively, and I'm not sure if any OSS libraries are actually in use in any DRM software, but it may at least set a trend. I'd love to see the next open source game changer be open to all except those who oppose openness :-)
I don't see the big deal.<p>Right now DRM depends on proprietary plug-ins. If this is allowed in HTML5, DRM will still depend on proprietary plug-ins.<p>What is different?<p>edit: also, browser vendors don't have to implement it if they don't want to. Really, I don't like this DRM thing that much, but I am kind of indifferent to this.
I think it's good.<p>Once it's implemented, you can just patch Firefox or Chromium to dump the unencrypted video stream before sending it to the H.264/WebM codec, and you get an universal method to trivially liberate all "DRM"-encumbered web content.
Site is incredibly slow (I see Wordpress is doing its job again). If it goes down, here is a copy of the html: <a href="http://pastebin.com/raw.php?i=fnutc6A3" rel="nofollow">http://pastebin.com/raw.php?i=fnutc6A3</a>
Here's a mirror (I think) of the post:<p><a href="http://permalink.gmane.org/gmane.org.freeculture.discuss/6814" rel="nofollow">http://permalink.gmane.org/gmane.org.freeculture.discuss/681...</a>
Forgive my lack of knowledge, but does this mean that in future motherboards or CPUs could be sold that lock out non DRM files, or something in our hardware like that?
Alas, article does not explain where the betrayal is. Or even what the author considers "web". Someone is too self-centric and has no idea what an average web user is and what he wants.<p>Honestly, rants like this sound a lot like "allowing same-sex marriages will destroy the sanctity of marriage" and alike. How exactly?<p>Will the ability to have DRM'ed content in HTML suddenly shut down "the open web"? No.