5 ms·

OK, I am gonna catch hell for this, but there is one major reason for having DRM in HTML 5. NetFlix. Streaming video sites are handcuffed to the media owners.

OK, I am gonna catch hell for this, but there is one major reason for having DRM in HTML 5. NetFlix. Streaming video sites are handcuffed to the media owners. Those media owners(Viacom, Time Warner, etc.) REQUIRE DRM in any contract with a streaming video provider. NetFlix uses Silverlight for this reason. Without DRM, NetFlix can never move to HTML5 and VP9. It's sad, but true. The W3C is not just being a buncha dicks. They're listening to all sides. Who cares if there's DRM in the spec, anyway? It doesn't mean people have to use it. And we all know it'll be cracked in a matter of SECONDS upon formal implementation.

jlgreco 13y ago
Who cares if Netflix needs it? If Netflix wants to do DRM in the browser, then they can continue to do it the painful way with traditional proprietary plugins. Why should we oblige them and dirty the standard in the process?
- VonGuard 13y ago
  Because not doing so concedes this type of market to Microsoft. Open standards are a way to ensure no specific company has control over stuff like this.
  - jlgreco 13y ago
    > Because not doing so concedes this type of market to Microsoft. Bullshit. 1) I am able to gleefully avoid it these days, but in the past flash worked with Linux. Furthermore, all relevant DRM systems work with Apple devices including OSX. Netflix works on Android, and on Google's ChromeOS. 2) Even if it did, who gives a shit? I'd rather have people who absolutely must watch netflix on their laptop do it with windows than have the standard dirtied with this shit. 3) Nothing about this shit being added to the standard will make Netflix work on Linux with open-source browsers anyway. You are high if you think this will allow you to use Netflix on your GNU/Linux box. Netflix already has their shit working with google-chrome, on a Linux kernel, in ChromeOS (Linux, but not "GNUy", for lack of better terminology). They don't allow that to work with regular GNU/Linux because they don't trust the rest of the stack to keep their precious bits secret.
    - VonGuard 13y ago
      1, 2 good for you. 3 is EXACTLY what this is about, actually. Read about VP9.
      - jlgreco 13y ago
        VP9 has nothing to do with this. Why would netflix build their CDM for Linux? (They wouldn't, and they won't.)
    - quaint- 13y ago
      Netflix actually already "works" in Linux, or at least did back when I last looked it up, and most probably their CDM would as well. I'm of course speaking of using wine. (Having not actually tested the solution, I cannot verify it nor tell about its shortcomings.) Or perhaps they would rely on secure/trusted path this time. I doubt that - the hardware simply isn't there for their customers. Anyhow, I certainly wouldn't want W3C to endorse any type of DRM, or have them make it easier to abuse DRM. It's a good thing that Flash and Silverlight are restricted to PCs. It's a good thing that plugins annoy people; it makes them less desirable. We really shouldn't be building a new framework for plugins on all platforms. Furthermore, I'd like to assure everyone reading this that DRM-free media is (still) thriving on the Internet. It's unfortunate that some people fail to play along; this only means that money doesn't go to the right people even if it's their media that's being exchanged.
      - lucian1900 13y ago
        Netflix only sort of maybe works with Wine + Firefox. If you're lucky.
  - duncan_bayne 13y ago
    I sound like a stuck record here but: the proposed EME standard in no way standardises the underlying DRM mechanisms in individual vendors' CDMs.
    - tmzt 13y ago
      Are you aware of any plan to standardize the API/ABI of the CDM modules. It would be possible to do this without exposing content as the current proposal (EME) just specifies the existence of an API for passing around CDM specific data, such as initialization data derived from streams. It may actually make sense to specify this API/ABI outside of the EME spec, such as through WHATWG. Having a small footprint in the API/ABI might help assuage fears that this is a backdoor to general DRM in HTML5. Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document. Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system. It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams. We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones. Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does. [EDIT: I found the reference I used for the comment about RMS, this is the quote from and article based on an interview with him (at http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-are-more-equal-than-others/ http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-a...): But later, Stallman said something that I found very surprising. He said that he has no problem with the firmware being burned into the hardware (via a ROM chip or the like). He said that he wanted a “black box”, and it’s obvious that he has no problem with proprietary firmware as long as it’s permanently embedded in the hardware rather than being loaded into it at boot time. ]
- dragonwriter 13y ago
  > Who cares if Netflix needs it? If Netflix wants to do DRM in the browser, then they can continue to do it the painful way with traditional proprietary plugins. I thought part of the reason for DRM-plugins-with-standardized-hooks-in-HTML is that it was the one particularly widely-used current use case for plugins that browser vendors weren't aiming to replace completely internally with HTML, CSS, and/or JS APIs, and switching to a standard mechanism for it would allow browser vendors to deprecate general purpose proprietary plugin mechanisms.
  - jlgreco 13y ago
    Why do you think they want to switch away from the old general purpose proprietary plugin mechanisms, which are specific to the browser? Because that stuff is a pain in the ass. I say let us keep it that way.
    - dragonwriter 13y ago
      > Why do you think they want to switch away from the old general purpose proprietary plugin mechanisms, which are specific to the browser? They (note that the people who want that I referred to in the post you responded to are the browser vendors, not the DRM-ed content suppliers) want to switch from that model because they want to narrow the interface to external software and encourage developers to do more with HTML and related technologies, to keep browsers more focussed and to provide more opportunities for HTML/CSS/JS-based extensions to interact with content. They "want" to keep DRM available through a narrowed-, specifiic plugin interface because there is enough demand from major content sources that the alternative is either keeping general purpose plugin interfaces alive (which browser vendors mostly don't want) or driving certain major uses of the internet out of browser entirely (which browser vendors want even less) or sites that want to deliver content for which the owners demand DRM make their own browsers with propietary DRM baked in.
duncan_bayne 13y ago
> OK, I am gonna catch hell for this, but there is one major > reason for having DRM in HTML 5. NetFlix. The W3Cs proposal will not bring NetFlix to Linux. What they - the W3C and Netflix - are proposing is a standardised interface between Javascript and CDMs. CDM vendors, like Netflix, will be under no compulsion to provide CDMs for other platforms. And they won't.
deleted 13y ago
[deleted]

jlgreco 13y ago

Who cares if Netflix needs it? If Netflix wants to do DRM in the browser, then they can continue to do it the painful way with traditional proprietary plugins. Why should we oblige them and dirty the standard in the process?

VonGuard 13y ago
Because not doing so concedes this type of market to Microsoft. Open standards are a way to ensure no specific company has control over stuff like this.
- jlgreco 13y ago
  > Because not doing so concedes this type of market to Microsoft. Bullshit. 1) I am able to gleefully avoid it these days, but in the past flash worked with Linux. Furthermore, all relevant DRM systems work with Apple devices including OSX. Netflix works on Android, and on Google's ChromeOS. 2) Even if it did, who gives a shit? I'd rather have people who absolutely must watch netflix on their laptop do it with windows than have the standard dirtied with this shit. 3) Nothing about this shit being added to the standard will make Netflix work on Linux with open-source browsers anyway. You are high if you think this will allow you to use Netflix on your GNU/Linux box. Netflix already has their shit working with google-chrome, on a Linux kernel, in ChromeOS (Linux, but not "GNUy", for lack of better terminology). They don't allow that to work with regular GNU/Linux because they don't trust the rest of the stack to keep their precious bits secret.
  - VonGuard 13y ago
    1, 2 good for you. 3 is EXACTLY what this is about, actually. Read about VP9.
    - jlgreco 13y ago
      VP9 has nothing to do with this. Why would netflix build their CDM for Linux? (They wouldn't, and they won't.)
  - quaint- 13y ago
    Netflix actually already "works" in Linux, or at least did back when I last looked it up, and most probably their CDM would as well. I'm of course speaking of using wine. (Having not actually tested the solution, I cannot verify it nor tell about its shortcomings.) Or perhaps they would rely on secure/trusted path this time. I doubt that - the hardware simply isn't there for their customers. Anyhow, I certainly wouldn't want W3C to endorse any type of DRM, or have them make it easier to abuse DRM. It's a good thing that Flash and Silverlight are restricted to PCs. It's a good thing that plugins annoy people; it makes them less desirable. We really shouldn't be building a new framework for plugins on all platforms. Furthermore, I'd like to assure everyone reading this that DRM-free media is (still) thriving on the Internet. It's unfortunate that some people fail to play along; this only means that money doesn't go to the right people even if it's their media that's being exchanged.
    - lucian1900 13y ago
      Netflix only sort of maybe works with Wine + Firefox. If you're lucky.
- duncan_bayne 13y ago
  I sound like a stuck record here but: the proposed EME standard in no way standardises the underlying DRM mechanisms in individual vendors' CDMs.
  - tmzt 13y ago
    Are you aware of any plan to standardize the API/ABI of the CDM modules. It would be possible to do this without exposing content as the current proposal (EME) just specifies the existence of an API for passing around CDM specific data, such as initialization data derived from streams. It may actually make sense to specify this API/ABI outside of the EME spec, such as through WHATWG. Having a small footprint in the API/ABI might help assuage fears that this is a backdoor to general DRM in HTML5. Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document. Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system. It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams. We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones. Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does. [EDIT: I found the reference I used for the comment about RMS, this is the quote from and article based on an interview with him (at http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-are-more-equal-than-others/ http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-a...): But later, Stallman said something that I found very surprising. He said that he has no problem with the firmware being burned into the hardware (via a ROM chip or the like). He said that he wanted a “black box”, and it’s obvious that he has no problem with proprietary firmware as long as it’s permanently embedded in the hardware rather than being loaded into it at boot time. ]
dragonwriter 13y ago
> Who cares if Netflix needs it? If Netflix wants to do DRM in the browser, then they can continue to do it the painful way with traditional proprietary plugins. I thought part of the reason for DRM-plugins-with-standardized-hooks-in-HTML is that it was the one particularly widely-used current use case for plugins that browser vendors weren't aiming to replace completely internally with HTML, CSS, and/or JS APIs, and switching to a standard mechanism for it would allow browser vendors to deprecate general purpose proprietary plugin mechanisms.
- jlgreco 13y ago
  Why do you think they want to switch away from the old general purpose proprietary plugin mechanisms, which are specific to the browser? Because that stuff is a pain in the ass. I say let us keep it that way.
  - dragonwriter 13y ago
    > Why do you think they want to switch away from the old general purpose proprietary plugin mechanisms, which are specific to the browser? They (note that the people who want that I referred to in the post you responded to are the browser vendors, not the DRM-ed content suppliers) want to switch from that model because they want to narrow the interface to external software and encourage developers to do more with HTML and related technologies, to keep browsers more focussed and to provide more opportunities for HTML/CSS/JS-based extensions to interact with content. They "want" to keep DRM available through a narrowed-, specifiic plugin interface because there is enough demand from major content sources that the alternative is either keeping general purpose plugin interfaces alive (which browser vendors mostly don't want) or driving certain major uses of the internet out of browser entirely (which browser vendors want even less) or sites that want to deliver content for which the owners demand DRM make their own browsers with propietary DRM baked in.

duncan_bayne 13y ago

> OK, I am gonna catch hell for this, but there is one major > reason for having DRM in HTML 5. NetFlix. The W3Cs proposal will not bring NetFlix to Linux. What they - the W3C and Netflix - are proposing is a standardised interface between Javascript and CDMs. CDM vendors, like Netflix, will be under no compulsion to provide CDMs for other platforms. And they won't.

deleted 13y ago

[deleted]