12 ms·

The W3C's plan for DRM in HTML5 is a betrayal for all web users

222 points by riordan 13y ago

deleted 13y ago
[deleted]
kxra 13y ago
TL;DR: # Myths 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 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 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 # Reality 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. (https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2 https://plus.google.com/107429617152575897589/posts/iPmatxBY...) 2. DRM in HTML5 doesn’t obviate proprietary browser plug-ins, it encourages them. (https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-out-w3c-standards https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...) 3. The Web doesn’t need big media; big media needs the Web. (http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc-attacks-the-open-web-gnulinux-in-danger/index.htm http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc...) # So sign the petition http://www.defectivebydesign.org/no-drm-in-html5 http://www.defectivebydesign.org/no-drm-in-html5
- cleverjake 13y ago
  Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?
  - bcoates 13y ago
    It isn't, that's why plugins are being killed off too.
    - cleverjake 13y ago
      >>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?
      - bcoates 13y ago
        I don't think I phrased that quite right. Modern web standards are attempting to render plugins like java, flash, and silverlight obsolete, because they're fragile, not universally available, single-sourced, proprietary, insecure and generally inconsistent with how the rest of the web works. There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed. You're right that EME is meaningless one way or another so long as plugins exist--That's why EME exists at all, it's essentially a new plugin architecture that solves none of the problems of the previous ones. It's a bad idea for the same reason plugins are.
        cleverjake 13y ago
        I still don't really understand what you are trying to say >> There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed. While I agree that there are people trying to kill off the need for plugins, I don't think anyone is killing off the APIs that allow for plugins - can you provide any example of this happening? (Outside of phones) >>You're right that EME is meaningless one way or another so long as plugins exist I never said that. Nor do I think that. My point is that EME is doing the same thing as other - long ago implemented - plugins, but with a lot less of a surface area of attack and more likely to be made up of better code. >> it's essentially a new plugin architecture agreed. >>that solves none of the problems of the previous ones. I don't believe that most people would list DRM-ablility as an issue with previous plugins. Could you elaborate what issues you are referring to? >>It's a bad idea for the same reason plugins are. I think that those plugins are bad because it gives flash/silverlight/java/anythingElse access to a lot of native APIs that most users are completely oblivious to. If anything, it removes most of the security issues shown in those plugin systems.
  - wmf 13y ago
    In theory perhaps it's no different. But I think EME would work out very poorly in practice. Some browsers either allow no plugins or only a few grandfathered plugins. What EME systems will they support? Imagine a future where Mobile Safari only supports FairPlay, IE only supports WMDRM, Chrome OS only supports Widevine, Android gets fragmented into a half-dozen different DRM schemes depending on vendor, desktop Linux has nothing, etc. This scenario is much worse than Flash.
    - cleverjake 13y ago
      Once someone supports EME, they would support anything written for EME. I don't believe there will be a way to 'grandfather' any old systems. That would require either a complete rewrite of the plugin in the browser, or a rewrite in an EME compatible code, in which case it will run anywhere EME exists. secondly, isn't the situation you describe exactly the situation we have now with flash/silverlight? I can't play WMAs on my Mac, Flash on my Droid, or any other number of combinations.
  - MatthewPhillips 13y ago
    Different, how? It's different in several ways. For one it's not a plugin framework, it's a DRM plugin framework; meaning it's designed specifically with 1 use case in mind. Secondly its expressed intent is to take away functionality; I'm not aware of any other instance where a web API is created to disable features of a user's computer. I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here.
    - deleted 13y ago
      [deleted]
    - cleverjake 13y ago
      >> For one it's not a plugin framework, it's a DRM plugin framework; A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it. >> Secondly its expressed intent is to take away functionality Take away what functionality? The ability to download audio/video? Again, playing the devil's advocate, I would imagine a vast majority of the content that would be streamed using the DRM encodes would not be streamed using the video element currently - it would be streamed over flash/silverlight, etc (think netflix, hulu). If that is the case, what is it we are losing? >> I'm not aware of any other instance where a web API is created to disable features of a user's computer To be fair, this isn't. EME is just a way for people to create addons that leverage native encryption. The same is true of the current plugin system. >>I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here. I am looking for logical reasons to say why adding EME hurts the open web so when I get into arguments I have better reasons other than 'I hate it'
      - yarrel 13y ago
        A DRM API in HTML5 harms users by legitimizing and enabling restrictive technology under the banner of the free and open web, with all the practical harm (lack of control, reduced bargaining power, security issues) that loss of freedom entails. If the framework is no different from existing frameworks, why do we need it?
  - shmerl 13y ago
    If one unethical junk already exists, why another needs to be created and specifically in HTML? Let's keep the Web clean.
    - cleverjake 13y ago
      To play to devils advocate - because that other unethical junk requires additional downloads and poses multiple security vulnerabilities. Right? Why wouldn't a sort of 'native plugin' be better in every sense of the word for the end user?
      - shmerl 13y ago
        See below: https://news.ycombinator.com/item?id=5599601 https://news.ycombinator.com/item?id=5599601 DRM by definition implies security and privacy risk. Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange. And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript. The risk caused by DRM won't get any less than it is already.
        kalleboo 13y ago
        > DRM by definition implies security and privacy risk Source please
        shmerl 13y ago
        Simple logic. DRM requires secret (from the user) code to run on user's machine. DRM doesn't trust the user (user is treated as potential criminal) for the sake of content owner interests. Such kind of predisposition makes it very reasonable for the user not to trust the content owner in return and to treat DRM by default as a privacy breaching malware and security risk (until proven otherwise - which isn't possible, since it's a black box). Trust is always mutual. How else can you view this?
        camus 13y ago
        because a drm plugin is a plugin,like flash or java applet. You'll have to download plugin DRM A,B or C to make it work.The only difference is that it will use the video tag.
  - bzbarsky 13y ago
    Well, one difference is that currently existing plug-in frameworks have well-defined APIs that are used to talk to the plug-in. This is why the same plug-in binary blob can be used in Firefox and Safari and Opera and Chrome, for example: they all implement NPAPI. One issue with the current EME spec is that it doesn't actually define an API for the browser to interact with the CDM. It defines an API for in-page JS to ask the browser to interact with the CDM, which is the web-facing bit, but how browsers and CDMs interact is entirely undefined. What that means in practice is that it would be perfectly spec-compliant for Google to ship a CDM that only works with Chrome, for Microsoft to ship one that only works with IE, and for Apple to ship one that only works with Safari. Should you then have the misfortune of not using one of those browsers, you wouldn't be able to view the video in question. Oddly enough, Google, Apple, and Microsoft are all in favor of this part of the spec last I checked.
- nness 13y ago
  Just to nitpick, the post you linked to by Ian Hickson does illustrate how DRM has been used to limit functionality, but both your post and his doesn't explain why "copyright protection" is a straw-man? I don't believe it is a fair argument to say that copyright protection and whatever functionality they enforce or prevent by use of DRM are mutually exclusive. Although, I do see the point that some parties could hide behind the "We need DRM to protect our copyright\prevent piracy" flag and instead use it to lock-in consumers and build a walled-garden.
  - rjempson 13y ago
    Calling "copyright protection" a straw-man is in itself a straw-man.
rocky1138 13y ago
What's the solution? Forking html?
- Millennium 13y ago
  The solution is waiting it out. They caved on music; they will cave here too. All that is required is patience: something that is admittedly rare in the tech world, but it works.
  - mlinksva 13y ago
    Not at all clear to me that waiting it out is a winning strategy. There is no deterministic path for other media to follow music away from DRM, and indeed there is a threat that a faux-standard as proposed will mean that DRM becomes the expectation and demand of/by record companies, again.
  - nemothekid 13y ago
    I wouldn't call it "caving" in on music. In a large part Apple effectively blind sided them, I'm sure if given another chance, the RIAA would never let iTunes exist.
- mlinksva 13y ago
  Short term, the solution is to convince W3C that moving forward will be an embarrassing disaster, nevermind what some of its for-profit members want. This has been accomplished before, in particular ~2001 when many wanted W3C to have a RAND (ie fee required OK) patent policy, but they were embarrassed into finally doing the right thing, ie mandating RF (royalty free) patent licensing by participants in W3C standards. Long term, help free culture become dominant. The post says "The Web doesn’t need big media; big media needs the Web" which is true, but web companies do fear and/or hope for an advantage over competitors by doing deals with big media, including deals selling out The Web writ large.
  - ndesaulniers 13y ago
    I wonder which ones sold out already? http://www.microsoft.com/playready/ http://www.microsoft.com/playready/ https://tools.google.com/dlpage/widevine https://tools.google.com/dlpage/widevine Bitches.
nwh 13y ago
DRM is based on obfuscation at the core. How would this ever work with open source browsers?
- JoshTriplett 13y ago
  It wouldn't. The explicitly stated plan from the people who originated this proposal involves proprietary browser plugins.
  - MatthewPhillips 13y ago
    Not necessarily browser plugins. Could be browser or OS or hardware.. Each website has control over what DRM it accepts, which leads to a world where hardware eventually becomes the requirement.
    - azakai 13y ago
      Regardless if it's technically a plugin or part of the OS accessed through a bridge, or anything else, EME fundamentally depends on proprietary code (and that code will not be part of any open source browser).
  - tomjen3 13y ago
    Then it would only be a matter of hacking one browser to claim to support drm scheme x and then not to get it to work. Since we have to distribute the run time in at least one browser, this shouldn't be a problem.
- flywheel 13y ago
  Do you have any clue how encryption works? There are plenty of open-source encryption algorithms that are very secure. I'm not sure how W3C is recommending the DRM be implemented, but it is in no way necessary for the source code for browsers to be 'closed' vs 'open' source in order to have effective DRM.
bcoates 13y ago
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. The Tiger Tree Hash system is already being deployed for this purpose in other systems.
ricardobeat 13y ago
NetFlix is one of the companies pushing this.
- magnacartic 13y ago
  Silverlight was great at keeping DRM from HTML5 till Microsoft decided to be 'cool'.
- shmerl 13y ago
  Also, note that Google is one of those companies as well. They forgot about "not being evil" with this one.
contingencies 13y ago
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.
- MatthewPhillips 13y ago
  I think Google has a checklist of Chromebook deficiencies and they are just checking Netflix off by doing this. That it will ultimately make it a little easier to do things like you suggest is just an added bonus.
verandaguy 13y ago
Wait, so the W3C is actually letting this happen? How the mighty have fallen.
- dthunt 13y ago
  It's still a proposal at this point. It should be opposed, obviously.
whiddershins 13y ago
What is the complaint. It isn't clearly summed up here. Noone will force you to use DRM on your website. Noone will force you to browse websites that use DRM. 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.
- Laremere 13y ago
  > Noone will force you to browse websites that use DRM. If you want to stay legal and watch their content, you bet they will. Major networks will require their distributors to use this DRM. Sure, you don't have to use their content, but the point of fighting it is that we want to use their content and are trying to prevent them from this step.
  - ndesaulniers 13y ago
    Excellent point. We take away the previous held concept of possessing media, making money by renting it to you repeatedly, then lobbying Washington with the profits to make it illegal to not play by our rules, and you're addicted so you can't break the habit.
    - whiddershins 13y ago
      What? Addicted? Really?
  - tonyarkles 13y ago
    Then don't watch their content, if you're morally opposed to how they're distributing it.
- MatthewPhillips 13y ago
  The primary complaint is that, for the first time since the <embed> tag, W3C is creating an API that by design won't work on some systems. If that isn't automatically bad to you on the face of it (it is to me, I want to be able to use random-OS-of-the-month as long as it has a good browser), you create a scenario where those on top stay on top by the grace of already being on top.
mmahemoff 13y ago
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. 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.
- comex 13y ago
  Indeed. Vendors won't be forced to make a HTML5 version - on the desktop the formula that's allowed them to provide browser plugins hasn't changed, and on mobile they're already making an iOS app and an Android app because today, apps provide a better experience than websites anyway. Sure, your niche mobile platform will be left without any way to experience the content, whereas if not for DRM they could provide an HTML5 player as a least common denominator, but it probably doesn't have enough users for them to terribly mind. That's not to say that HTML5 EME addresses this, just that nobody is going to be forced to use HTML5 in any case. (It's possible that a proprietary but common CDM standard could be created to allow the least common denominator on mobile, since the regular route of browser plugins won't work there, but that would be its own can of worms.)
cromwellian 13y ago
Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards. 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. 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. 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 all media that's DRMed. 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.
- nitrogen 13y ago
  Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards. In this case, forget consumers. Once in a while, something is more important than appeasing the masses. 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. Neither is a DRM-infested spec. Instead, you have uninformed consumers Googling for "how can I watch Game of Thrones Season 2 Episode 3 online for free", getting infested with malware, but still watching the show for free.
  - cromwellian 13y ago
    So if the vast majority of people end up using native apps, and more and more information gets siloed behind these native app clouds on DRM'ed mobile devices, because that's where the money is, and the Web becomes a ghost town, that would be better for everyone? The perfect is the enemy of the good.
coherentpony 13y ago
EME =/= DRM.
- ndesaulniers 13y ago
  Technically speaking, you're right. EME is not DRM, it's a facilitator. From the spec "facilitating the development of robust playback applications supporting a range of content decryption and protection technologies [read DRM]." I may have inserted that last part. Using a new acronym affords Hollywood more time to get implementations in major browsers while we try to raise awareness. Most consumers don't know about DRM, fewer still about EME!
rjempson 13y ago
I can't read the article, probably a HN DOS. 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). 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.
cromwellian 13y ago
Why are optional WebIDL bindings really any different than NPAPI bindings? foo.getDRMStream() is bad, but document.getElementById("drmpluginelement").getDRMStream() is somehow fundamentally better? 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.
- TazeTSchnitzel 13y ago
  Well, we can at least not make the situation worse. We already have NPAPI, let's not add another proprietary plugin API.
tn13 13y ago
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 ? 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. As I see it, web standards should be as open as possible.
mmastrac 13y ago
Here's a mirror (I think) of the post: http://permalink.gmane.org/gmane.org.freeculture.discuss/6814 http://permalink.gmane.org/gmane.org.freeculture.discuss/681...
shitlord 13y ago
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. 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. 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.
cantankerous 13y ago
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.
- bzbarsky 13y ago
  The W3C will ultimately do what is in its members' best interests: it's an industry consortium. Its members are whoever paid the membership fee. There are plenty of instances of the W3C doing things that its members asked for that were either irrelevant to the web or detrimental to it, because there is no "W3C" per se when it comes to getting stuff done, just the set of members.
snambi 13y ago
DRM is bad.
runn1ng 13y ago
I don't see the big deal. Right now DRM depends on proprietary plug-ins. If this is allowed in HTML5, DRM will still depend on proprietary plug-ins. What is different? 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.
- AnthonyMouse 13y ago
  >What is different? That's kind of the point. The people promoting this seem to be misunderstanding what the result would be. It would in no way reduce the amount of poorly written proprietary code full of security vulnerabilities. It would just move it around a little. But in the meantime it breaks the web. Even if you support the new HTML5 spec, you can't actually support it without having the proprietary black box necessary to make it work. You break the ability of the web to be platform agnostic. For the web to work at all you'll soon end up needing the black box, because once it's there sites will use it. So if the black box doesn't exist for your platform or you want to create a new platform then you'll be locked out of most of the web. How can that be acceptable?
  - runn1ng 13y ago
    But it is NOT platform agnostic anyway. That is my point. Right now, you have to have certain plugins to see certain sites. At this very moment. So according to the new specification, there won't be <embed> with a specified plugin in TYPE attribute (or something similar in <object>), but probably something else and similar with EME. Why does it matter so much? If this is not passed, evil corporations will use <embed> and <object> again. If this is and browsers will support it, they will use EME instead. Again, I can't see any big change.
    - AnthonyMouse 13y ago
      We should oppose the old plug-ins just like we do the new ones. The big change is that the old plug-ins have been starting to die out. People originally used Flash because it was the best way to play video in a web browser, not because it had DRM. As improvements to HTML eliminate the non-DRM need for such plug-ins, the plug-ins start to go away. Apple got away with prohibiting Flash on iOS because it became possible to use Youtube et al without it. We ought to be encouraging the legacy plug-ins to finish going away, not reintroducing new ones.
campuscodi 13y ago
This is because all you dummies were too busy lauding Google's services and nobody notices how "evil" they are. 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.
- NinjaWarrior 13y ago
  Yep, if Google implements DRM, no one can stop it. The web is a platform for big software vendors after all, because no other player can virtually implement and maintain this enlarged platform and browser runtimes. Evil browser vendors will take over the role of evil plug-in vendors. Game over. I predicted this catastrophe when everyone was attacking Flash.
blust 13y ago
I think it's good. 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.
alan_cx 13y ago
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?
lucb1e 13y ago
Site is incredibly slow (I see Wordpress is doing its job again). If it goes down, here is a copy of the html: http://pastebin.com/raw.php?i=fnutc6A3 http://pastebin.com/raw.php?i=fnutc6A3
rimantas 13y ago
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. Honestly, rants like this sound a lot like "allowing same-sex marriages will destroy the sanctity of marriage" and alike. How exactly? Will the ability to have DRM'ed content in HTML suddenly shut down "the open web"? No.
Intermernet 13y ago
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? 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 :-)
- zb 13y ago
  No, by definition, since that would no longer be Open Source. http://opensource.org/osd http://opensource.org/osd
smutticus 13y ago
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. 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.

222 points by riordan 13y ago

deleted 13y ago

[deleted]

kxra 13y ago

TL;DR: # Myths 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 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 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 # Reality 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. (https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2 https://plus.google.com/107429617152575897589/posts/iPmatxBY...) 2. DRM in HTML5 doesn’t obviate proprietary browser plug-ins, it encourages them. (https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-out-w3c-standards https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...) 3. The Web doesn’t need big media; big media needs the Web. (http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc-attacks-the-open-web-gnulinux-in-danger/index.htm http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc...) # So sign the petition http://www.defectivebydesign.org/no-drm-in-html5 http://www.defectivebydesign.org/no-drm-in-html5

cleverjake 13y ago
Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?
- bcoates 13y ago
  It isn't, that's why plugins are being killed off too.
  - cleverjake 13y ago
    >>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?
    - bcoates 13y ago
      I don't think I phrased that quite right. Modern web standards are attempting to render plugins like java, flash, and silverlight obsolete, because they're fragile, not universally available, single-sourced, proprietary, insecure and generally inconsistent with how the rest of the web works. There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed. You're right that EME is meaningless one way or another so long as plugins exist--That's why EME exists at all, it's essentially a new plugin architecture that solves none of the problems of the previous ones. It's a bad idea for the same reason plugins are.
      - cleverjake 13y ago
        I still don't really understand what you are trying to say >> There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed. While I agree that there are people trying to kill off the need for plugins, I don't think anyone is killing off the APIs that allow for plugins - can you provide any example of this happening? (Outside of phones) >>You're right that EME is meaningless one way or another so long as plugins exist I never said that. Nor do I think that. My point is that EME is doing the same thing as other - long ago implemented - plugins, but with a lot less of a surface area of attack and more likely to be made up of better code. >> it's essentially a new plugin architecture agreed. >>that solves none of the problems of the previous ones. I don't believe that most people would list DRM-ablility as an issue with previous plugins. Could you elaborate what issues you are referring to? >>It's a bad idea for the same reason plugins are. I think that those plugins are bad because it gives flash/silverlight/java/anythingElse access to a lot of native APIs that most users are completely oblivious to. If anything, it removes most of the security issues shown in those plugin systems.
- wmf 13y ago
  In theory perhaps it's no different. But I think EME would work out very poorly in practice. Some browsers either allow no plugins or only a few grandfathered plugins. What EME systems will they support? Imagine a future where Mobile Safari only supports FairPlay, IE only supports WMDRM, Chrome OS only supports Widevine, Android gets fragmented into a half-dozen different DRM schemes depending on vendor, desktop Linux has nothing, etc. This scenario is much worse than Flash.
  - cleverjake 13y ago
    Once someone supports EME, they would support anything written for EME. I don't believe there will be a way to 'grandfather' any old systems. That would require either a complete rewrite of the plugin in the browser, or a rewrite in an EME compatible code, in which case it will run anywhere EME exists. secondly, isn't the situation you describe exactly the situation we have now with flash/silverlight? I can't play WMAs on my Mac, Flash on my Droid, or any other number of combinations.
- MatthewPhillips 13y ago
  Different, how? It's different in several ways. For one it's not a plugin framework, it's a DRM plugin framework; meaning it's designed specifically with 1 use case in mind. Secondly its expressed intent is to take away functionality; I'm not aware of any other instance where a web API is created to disable features of a user's computer. I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here.
  - deleted 13y ago
    [deleted]
  - cleverjake 13y ago
    >> For one it's not a plugin framework, it's a DRM plugin framework; A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it. >> Secondly its expressed intent is to take away functionality Take away what functionality? The ability to download audio/video? Again, playing the devil's advocate, I would imagine a vast majority of the content that would be streamed using the DRM encodes would not be streamed using the video element currently - it would be streamed over flash/silverlight, etc (think netflix, hulu). If that is the case, what is it we are losing? >> I'm not aware of any other instance where a web API is created to disable features of a user's computer To be fair, this isn't. EME is just a way for people to create addons that leverage native encryption. The same is true of the current plugin system. >>I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here. I am looking for logical reasons to say why adding EME hurts the open web so when I get into arguments I have better reasons other than 'I hate it'
    - yarrel 13y ago
      A DRM API in HTML5 harms users by legitimizing and enabling restrictive technology under the banner of the free and open web, with all the practical harm (lack of control, reduced bargaining power, security issues) that loss of freedom entails. If the framework is no different from existing frameworks, why do we need it?
- shmerl 13y ago
  If one unethical junk already exists, why another needs to be created and specifically in HTML? Let's keep the Web clean.
  - cleverjake 13y ago
    To play to devils advocate - because that other unethical junk requires additional downloads and poses multiple security vulnerabilities. Right? Why wouldn't a sort of 'native plugin' be better in every sense of the word for the end user?
    - shmerl 13y ago
      See below: https://news.ycombinator.com/item?id=5599601 https://news.ycombinator.com/item?id=5599601 DRM by definition implies security and privacy risk. Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange. And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript. The risk caused by DRM won't get any less than it is already.
      - kalleboo 13y ago
        > DRM by definition implies security and privacy risk Source please
        shmerl 13y ago
        Simple logic. DRM requires secret (from the user) code to run on user's machine. DRM doesn't trust the user (user is treated as potential criminal) for the sake of content owner interests. Such kind of predisposition makes it very reasonable for the user not to trust the content owner in return and to treat DRM by default as a privacy breaching malware and security risk (until proven otherwise - which isn't possible, since it's a black box). Trust is always mutual. How else can you view this?
        camus 13y ago
        because a drm plugin is a plugin,like flash or java applet. You'll have to download plugin DRM A,B or C to make it work.The only difference is that it will use the video tag.
- bzbarsky 13y ago
  Well, one difference is that currently existing plug-in frameworks have well-defined APIs that are used to talk to the plug-in. This is why the same plug-in binary blob can be used in Firefox and Safari and Opera and Chrome, for example: they all implement NPAPI. One issue with the current EME spec is that it doesn't actually define an API for the browser to interact with the CDM. It defines an API for in-page JS to ask the browser to interact with the CDM, which is the web-facing bit, but how browsers and CDMs interact is entirely undefined. What that means in practice is that it would be perfectly spec-compliant for Google to ship a CDM that only works with Chrome, for Microsoft to ship one that only works with IE, and for Apple to ship one that only works with Safari. Should you then have the misfortune of not using one of those browsers, you wouldn't be able to view the video in question. Oddly enough, Google, Apple, and Microsoft are all in favor of this part of the spec last I checked.
nness 13y ago
Just to nitpick, the post you linked to by Ian Hickson does illustrate how DRM has been used to limit functionality, but both your post and his doesn't explain why "copyright protection" is a straw-man? I don't believe it is a fair argument to say that copyright protection and whatever functionality they enforce or prevent by use of DRM are mutually exclusive. Although, I do see the point that some parties could hide behind the "We need DRM to protect our copyright\prevent piracy" flag and instead use it to lock-in consumers and build a walled-garden.
- rjempson 13y ago
  Calling "copyright protection" a straw-man is in itself a straw-man.

rocky1138 13y ago

What's the solution? Forking html?

Millennium 13y ago
The solution is waiting it out. They caved on music; they will cave here too. All that is required is patience: something that is admittedly rare in the tech world, but it works.
- mlinksva 13y ago
  Not at all clear to me that waiting it out is a winning strategy. There is no deterministic path for other media to follow music away from DRM, and indeed there is a threat that a faux-standard as proposed will mean that DRM becomes the expectation and demand of/by record companies, again.
- nemothekid 13y ago
  I wouldn't call it "caving" in on music. In a large part Apple effectively blind sided them, I'm sure if given another chance, the RIAA would never let iTunes exist.
mlinksva 13y ago
Short term, the solution is to convince W3C that moving forward will be an embarrassing disaster, nevermind what some of its for-profit members want. This has been accomplished before, in particular ~2001 when many wanted W3C to have a RAND (ie fee required OK) patent policy, but they were embarrassed into finally doing the right thing, ie mandating RF (royalty free) patent licensing by participants in W3C standards. Long term, help free culture become dominant. The post says "The Web doesn’t need big media; big media needs the Web" which is true, but web companies do fear and/or hope for an advantage over competitors by doing deals with big media, including deals selling out The Web writ large.
- ndesaulniers 13y ago
  I wonder which ones sold out already? http://www.microsoft.com/playready/ http://www.microsoft.com/playready/ https://tools.google.com/dlpage/widevine https://tools.google.com/dlpage/widevine Bitches.

nwh 13y ago

DRM is based on obfuscation at the core. How would this ever work with open source browsers?

JoshTriplett 13y ago
It wouldn't. The explicitly stated plan from the people who originated this proposal involves proprietary browser plugins.
- MatthewPhillips 13y ago
  Not necessarily browser plugins. Could be browser or OS or hardware.. Each website has control over what DRM it accepts, which leads to a world where hardware eventually becomes the requirement.
  - azakai 13y ago
    Regardless if it's technically a plugin or part of the OS accessed through a bridge, or anything else, EME fundamentally depends on proprietary code (and that code will not be part of any open source browser).
- tomjen3 13y ago
  Then it would only be a matter of hacking one browser to claim to support drm scheme x and then not to get it to work. Since we have to distribute the run time in at least one browser, this shouldn't be a problem.
flywheel 13y ago
Do you have any clue how encryption works? There are plenty of open-source encryption algorithms that are very secure. I'm not sure how W3C is recommending the DRM be implemented, but it is in no way necessary for the source code for browsers to be 'closed' vs 'open' source in order to have effective DRM.

bcoates 13y ago

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. The Tiger Tree Hash system is already being deployed for this purpose in other systems.

ricardobeat 13y ago

NetFlix is one of the companies pushing this.

magnacartic 13y ago
Silverlight was great at keeping DRM from HTML5 till Microsoft decided to be 'cool'.
shmerl 13y ago
Also, note that Google is one of those companies as well. They forgot about "not being evil" with this one.

contingencies 13y ago

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.

MatthewPhillips 13y ago
I think Google has a checklist of Chromebook deficiencies and they are just checking Netflix off by doing this. That it will ultimately make it a little easier to do things like you suggest is just an added bonus.

verandaguy 13y ago

Wait, so the W3C is actually letting this happen? How the mighty have fallen.

dthunt 13y ago
It's still a proposal at this point. It should be opposed, obviously.

whiddershins 13y ago

What is the complaint. It isn't clearly summed up here. Noone will force you to use DRM on your website. Noone will force you to browse websites that use DRM. 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.

Laremere 13y ago
> Noone will force you to browse websites that use DRM. If you want to stay legal and watch their content, you bet they will. Major networks will require their distributors to use this DRM. Sure, you don't have to use their content, but the point of fighting it is that we want to use their content and are trying to prevent them from this step.
- ndesaulniers 13y ago
  Excellent point. We take away the previous held concept of possessing media, making money by renting it to you repeatedly, then lobbying Washington with the profits to make it illegal to not play by our rules, and you're addicted so you can't break the habit.
  - whiddershins 13y ago
    What? Addicted? Really?
- tonyarkles 13y ago
  Then don't watch their content, if you're morally opposed to how they're distributing it.
MatthewPhillips 13y ago
The primary complaint is that, for the first time since the <embed> tag, W3C is creating an API that by design won't work on some systems. If that isn't automatically bad to you on the face of it (it is to me, I want to be able to use random-OS-of-the-month as long as it has a good browser), you create a scenario where those on top stay on top by the grace of already being on top.

mmahemoff 13y ago

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

comex 13y ago
Indeed. Vendors won't be forced to make a HTML5 version - on the desktop the formula that's allowed them to provide browser plugins hasn't changed, and on mobile they're already making an iOS app and an Android app because today, apps provide a better experience than websites anyway. Sure, your niche mobile platform will be left without any way to experience the content, whereas if not for DRM they could provide an HTML5 player as a least common denominator, but it probably doesn't have enough users for them to terribly mind. That's not to say that HTML5 EME addresses this, just that nobody is going to be forced to use HTML5 in any case. (It's possible that a proprietary but common CDM standard could be created to allow the least common denominator on mobile, since the regular route of browser plugins won't work there, but that would be its own can of worms.)

cromwellian 13y ago

Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards. 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. 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. 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 all media that's DRMed. 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.

nitrogen 13y ago
Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards. In this case, forget consumers. Once in a while, something is more important than appeasing the masses. 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. Neither is a DRM-infested spec. Instead, you have uninformed consumers Googling for "how can I watch Game of Thrones Season 2 Episode 3 online for free", getting infested with malware, but still watching the show for free.
- cromwellian 13y ago
  So if the vast majority of people end up using native apps, and more and more information gets siloed behind these native app clouds on DRM'ed mobile devices, because that's where the money is, and the Web becomes a ghost town, that would be better for everyone? The perfect is the enemy of the good.

coherentpony 13y ago

EME =/= DRM.

ndesaulniers 13y ago
Technically speaking, you're right. EME is not DRM, it's a facilitator. From the spec "facilitating the development of robust playback applications supporting a range of content decryption and protection technologies [read DRM]." I may have inserted that last part. Using a new acronym affords Hollywood more time to get implementations in major browsers while we try to raise awareness. Most consumers don't know about DRM, fewer still about EME!

rjempson 13y ago

I can't read the article, probably a HN DOS. 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). 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.

cromwellian 13y ago

Why are optional WebIDL bindings really any different than NPAPI bindings? foo.getDRMStream() is bad, but document.getElementById("drmpluginelement").getDRMStream() is somehow fundamentally better? 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.

TazeTSchnitzel 13y ago
Well, we can at least not make the situation worse. We already have NPAPI, let's not add another proprietary plugin API.

tn13 13y ago

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 ? 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. As I see it, web standards should be as open as possible.

mmastrac 13y ago

Here's a mirror (I think) of the post: http://permalink.gmane.org/gmane.org.freeculture.discuss/6814 http://permalink.gmane.org/gmane.org.freeculture.discuss/681...

shitlord 13y ago

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

cantankerous 13y ago

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.

bzbarsky 13y ago
The W3C will ultimately do what is in its members' best interests: it's an industry consortium. Its members are whoever paid the membership fee. There are plenty of instances of the W3C doing things that its members asked for that were either irrelevant to the web or detrimental to it, because there is no "W3C" per se when it comes to getting stuff done, just the set of members.

snambi 13y ago

DRM is bad.

runn1ng 13y ago

I don't see the big deal. Right now DRM depends on proprietary plug-ins. If this is allowed in HTML5, DRM will still depend on proprietary plug-ins. What is different? 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.

AnthonyMouse 13y ago
>What is different? That's kind of the point. The people promoting this seem to be misunderstanding what the result would be. It would in no way reduce the amount of poorly written proprietary code full of security vulnerabilities. It would just move it around a little. But in the meantime it breaks the web. Even if you support the new HTML5 spec, you can't actually support it without having the proprietary black box necessary to make it work. You break the ability of the web to be platform agnostic. For the web to work at all you'll soon end up needing the black box, because once it's there sites will use it. So if the black box doesn't exist for your platform or you want to create a new platform then you'll be locked out of most of the web. How can that be acceptable?
- runn1ng 13y ago
  But it is NOT platform agnostic anyway. That is my point. Right now, you have to have certain plugins to see certain sites. At this very moment. So according to the new specification, there won't be <embed> with a specified plugin in TYPE attribute (or something similar in <object>), but probably something else and similar with EME. Why does it matter so much? If this is not passed, evil corporations will use <embed> and <object> again. If this is and browsers will support it, they will use EME instead. Again, I can't see any big change.
  - AnthonyMouse 13y ago
    We should oppose the old plug-ins just like we do the new ones. The big change is that the old plug-ins have been starting to die out. People originally used Flash because it was the best way to play video in a web browser, not because it had DRM. As improvements to HTML eliminate the non-DRM need for such plug-ins, the plug-ins start to go away. Apple got away with prohibiting Flash on iOS because it became possible to use Youtube et al without it. We ought to be encouraging the legacy plug-ins to finish going away, not reintroducing new ones.

campuscodi 13y ago

This is because all you dummies were too busy lauding Google's services and nobody notices how "evil" they are. 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.

NinjaWarrior 13y ago
Yep, if Google implements DRM, no one can stop it. The web is a platform for big software vendors after all, because no other player can virtually implement and maintain this enlarged platform and browser runtimes. Evil browser vendors will take over the role of evil plug-in vendors. Game over. I predicted this catastrophe when everyone was attacking Flash.

blust 13y ago

I think it's good. 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.

alan_cx 13y ago

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?

lucb1e 13y ago

Site is incredibly slow (I see Wordpress is doing its job again). If it goes down, here is a copy of the html: http://pastebin.com/raw.php?i=fnutc6A3 http://pastebin.com/raw.php?i=fnutc6A3

rimantas 13y ago

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. Honestly, rants like this sound a lot like "allowing same-sex marriages will destroy the sanctity of marriage" and alike. How exactly? Will the ability to have DRM'ed content in HTML suddenly shut down "the open web"? No.

Intermernet 13y ago

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

zb 13y ago
No, by definition, since that would no longer be Open Source. http://opensource.org/osd http://opensource.org/osd

smutticus 13y ago

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