6 ms·

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 ineffectiv

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

by kxra 13y ago

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.