10 ms·

Tell W3C: We don't want the Hollyweb

179 points by hosay123 14y ago

hosay123 14y ago
There's a pretty lively thread over on Reddit: http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_we_dont_want_the_hollyweb_drm_in_html5/ http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_...
Daiz 14y ago
I'm actually a bit conflicted about support for DRM schemes in HTML5. I absolute loathe DRM and I wish every damn publisher of every damn type would come to their senses and actually sell DRM-free digital products. However, there is one case where some form of "DRM" does make sense, and that's actual renting - or more specifically, the popular case of "catalog subscription" (ala Spotify, Netflix and so on). You're clearly renting access to a catalog of goods in this kind of model, and therefore it makes sense that you'd want to stop people from permanently acquiring copies in such a scenario, especially if you're selling actual DRM-free downloads at the same time (in my ideal digital store where it makes sense they would offer both of these side-by-side). The catalog subscription model has some clear value to it, and I'd hate for it to disappear due to "technical unfeasibility". As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on. I can't really think of a good solution to this, unless you got the big wigs at various publishing outlets to accept that to do HTML5 streaming, you can only make downloading the rentable versions inconvenient for regular versions (instead of being able to use a heavy-weight closed DRM plugin), but I'm afraid that could be quite challenging. It has worked for Adobe and webfonts, though[1], so maybe there's hope. Forcing HTML5 to be DRM-free could eventually lead to this direction. [1] http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/ http://blog.typekit.com/2009/07/21/serving-and-protecting-fo...
- yarrel 14y ago
  Renting infinitely copyable goods doesn't make sense. Subscriptions to channels containing them does. DRM doesn't increase the convenience of those channels. It reduces them.
  - Daiz 14y ago
    The problem I have is that I can't really imagine the catalog subscription model to be feasible if any and all catalog entries were available to download without DRM. Someone with a fat pipe could just spend a month downloading absolutely everything, cutting the subscription and enjoying the goods for a long time to come, whereas the idea is that the user remains as a subscriber because of the limited time they have for consuming all the content. And while DRM is generally very inconvenient, there are also places where it's mostly "invisible" - Spotify and Netflix are pretty damn convenient on the whole, with pretty much the only major downside being the inability to watch stuff without an internet connection (though Spotify offers limited offline downloads for this reason too). The DRM in Steam is also generally quite invisible to the end-users, which is why people generally do not mind it - and also because Steam offers a lot more convenience with its service than what it takes away with its DRM. As I said, ideally I'd like to see digital stores that combine the catalog subscription model as well as individual DRM-free purchases. Think Netflix, except you could also buy the really good stuff that you like. This would allow you to download DRM-free copies in many formats whenever you want, they could also bundle purchases with stuff like extras, and best of all: since they have a streaming infrastructure in place already they could also offer unlimited streaming for bought titles, even if you don't have a subscription. I imagine it would make for quite the killer service. But if everything could be downloaded DRM-free with just the catalog subscription, the individual sales would not work, and subscriptions would probably have a terrible retention rate. Again, I just can't see the catalog subscription model working without at least some sort of "download prevention". I guess the biggest question is: Can we achieve that without the need for heavyweight black-box DRM schemes? I mean, you'd really just need to stop "casual" downloading - pirates will always find a way around protections, so they can't be stopped, but you'd just have to make sure a regular customer sees value in both the catalog subscription (which would be essentially renting) and individual title purchasing (actual buying).
    - TheCoelacanth 14y ago
      Even with DRM, I wouldn't be subscribed to a service for long if it wasn't continually adding new content.
    - 14y ago
- MatthewPhillips 14y ago
  > As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on. It's not really based on open stuff. EME isn't DRM, it provides a way to talk to a DRM service (probably a hardware DRM in most cases). They are creating a false-sense of "open standards" when this thing still won't work in Linux and most not-locked-down platforms.
  - Daiz 14y ago
    Yeah, that's the impression I've got as well, which is why I don't ultimately like EME. It would be a slight improvement compared to the current situation (since you could at least move stuff like video playback to HTML5), but would probably just make the situation of "closed binary blob DRM" more persistent and thus worse in the long run.
  - bzbarsky 14y ago
    It provides a way for script to talk to a DRM service. Assuming the browser has a way to talk to one already. It doesn't do anything towards providing a way for _browsers_ to talk to DRM services; that's up to the browser manufacturers to license or whatnot.
  - eridius 14y ago
    Unfortunately, this sort of problem is basically unsolvable for Linux (and other such "open" platforms). Either you get a proprietary blob that implements a protection scheme, or you simply don't get the functionality being promised. Objecting to efforts to make the situation better for HTML5 experiences on other platforms because it won't work on Linux is, honestly, pretty selfish. It can't work on Linux, so you're basically saying since it can't work for you, it shouldn't work for anyone else too. And that's just dragging down the state of the web to the lowest common denominator.
    - summerdown2 14y ago
      > And that's just dragging down the state of the web to the lowest common denominator. Or up to the state of most openness?
- webreac 14y ago
  Watermarking makes a lot more sense than DRM. If your name is on the film you just bought, you will not want to publish it on p2p.
  - Daiz 14y ago
    It wouldn't really be a feasible solution for video, though. You'd have to re-encode the whole thing for every individual user, which would be incredibly inefficient. Even if you're showing the watermark in just a few places, it'd still require a damn lot of resources. There's also quite a few things out there for removing video watermarks[1], so unless the watermarks were incredibly obtrusive, they'd probably be quite easy to get rid of. And of course you couldn't really put the watermark outside the actual video stream either, since then the user could just strip it out. [1] Like various Avisynth plugins for example: http://avisynth.org/mediawiki/External_filters#Logo_Removal http://avisynth.org/mediawiki/External_filters#Logo_Removal
    - benologist 14y ago
      Is it really true that they can't do it on the fly? Live streaming is creating the video on the fly completely isn't it?
      - Daiz 14y ago
        In case of live streaming, the video is only encoded once and then distributed to a whole bunch of users. If you were doing unique watermarks, you'd have to encode an individual stream for every single user. Encoding is much more taxing than decoding. The end result would be that you'd need a metric crapton of additional processing power, and the quality would be worse since you'd have to use sufficiently fast encoding settings to be able to do it in realtime (as opposed to being able to use a lot more expensive options when the encoding is done just once and separately from the actual streaming process).
        benologist 14y ago
        What about onlive, they stream(ed) cpu/gpu intensive games in real time on a one-to-one basis?
- bsimpson 14y ago
  Is anyone here familiar with the proposed spec? Would the DRM be a private binary included with the OS, or an open part of the browser? Unless they're just specifying an API, and all the actual work is done in a private binary, I don't understand how you can have effective DRM in a publicly specified project.
  - MatthewPhillips 14y ago
    Could be a private binary, could be a hardware component, but yeah, the actual DRM part is not in this spec.
randall 14y ago
I think DRM makes sense sadly because otherwise it'd be as simple as 'right click, save as' and you'd have the contents of a movie. There'd be little incentive to subscribe to Netflix past a month. Rdio too. Simple anti-copying provisions that are still defeatable, though through effort, help incentivize the migration of those channels. And that's what I really want. I want Hollywood to feel comfortable using the web, because then more open alternatives will emerge when it's a level playing field. (IE watching TV is watching the web.)
- CamperBob2 14y ago
  There'd be little incentive to subscribe to Netflix past a month. Have you actually used Netflix?
  - randall 14y ago
    Sure. Could you provide more context to your question?
    - CamperBob2 14y ago
      It sounded like you were under the impression that it's either possible or desirable to make your own local copy of the entire Netflix library. Why exactly would I want to do that, DRM or no DRM?
- darkchasma 14y ago
  No, this doesn't make sense in the slightest. Fact 1. If I want a movie or song without paying for it, I can get it. I don't need any more facts, this "solution" doesn't solve fact 1's problem. It simply breaks the internet. So what part of creating a burden that doesn't solve a problem make sense?
  - andylei 14y ago
    > Fact 1. If I want a movie or song without paying for it, I can get it. this is actually irrelevant. netflix is contractually obligated to distribute all their content through DRM'ed channels. Hollywood knows that DRM isn't going to stop copying, but they would still like to reduce it, and they certainly aren't going to license their content to services that make copying trivial.
tomelders 14y ago
It's hot HTML's job to fix broken business models.
- zanny 14y ago
  They are being pressured by businesses that want to support those broken business models like Google. Youtube is a great example - thousands of people are now living their lives off youtube ad revenue, yet you can get a simple addon for any browser to download the mp4s. DRM isn't necessary, old media just wants total control. I seriously think if we just play the battle of attrition, they will die off soon because they can't compete in an on-demand get-what-you-want information free era.
edgesrazor 14y ago
If DRM is inevitable, I'd take a properly implemented DRM that's been through community scrutiny than another Sony rootkit fiasco any time.
- yarrel 14y ago
  How would you like hooks in your web browser for the Sony root kit? That's what's being proposed at the W3C.
  - recoiledsnake 14y ago
    Please, that's hyperbole. Sony rootkit and the DRM present in Flash/Silverlight are worlds apart.
    - ihsw 14y ago
      Actually the description is apt -- the proposal is when a web page loads then a binary blob (that has OS-level hardware access) will be invoked. It would be as simple as including a highly-insecure JS file rather than installing a browser add-on/plug-in/extension/whatever. The security risks cause me imagine EME news that makes the recent Java 0-day news frighteningly tame.
    - pyalot2 14y ago
      It is not hyperbole. EME is a plugin API, and the plugin is not specified, and that is what the DRM is. It is inevitable this will result in another rootkit fiasco. But worse than that, the working of the DRM (called a CDM) will also sacrifice your privacy on the web, because it can inevitably act like a "supercookie" over which you will have no control.
- ncallaway 14y ago
  My understanding of the proposed EME is that it does not implement any DRM, and DRM implemented for it would likely be opaque software implemented without community scrutiny. The EME (again, by my understanding, I could be wrong) only defines an API to communicate with DRM systems. I don't think this helps us gain any scrutiny over DRM.
chjj 14y ago
A dark future for HTML. I can't really describe the melancholy I feel when thinking about this. In 10 years, we'll be reminiscing about how the web was once an open platform, and we'll kick ourselves for having said at the time, "I hate DRM...but then again, I do like netflix!"
kibwen 14y ago
The W3C requires at least two implementations before standardization can happen, right? Theoretically, if both Webkit and Gecko refused to implement it (or, more diplomatically, "indefinitely deprioritized its implementation"), would this be DOA?
- azakai 14y ago
  Google and Microsoft are supporters and working on the spec, https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... Which makes two implementations, I am afraid. Unless we can convince at least one of those to stop.
  - kibwen 14y ago
    Right, but it's Apple, not Google, who holds the keys to Webkit. Not that I presume that Apple is so benevolent (naive much?), but it wouldn't be the first time that Apple has outright rejected a Googler's patch (I can't remember the link now, something about Dart integration). Obviously Google could always fork the whole project for the sole purpose of implementing DRM, but what a fiasco that would be!
    - azakai 14y ago
      Google doesn't need to officially fork WebKit, it can keep these features in Chromium and not push them into WebKit - like many other features, including the one you mentioned (Dart support that Apple rejected). But Chrome is still a major implementation, it doesn't have to get into WebKit or not (for standardization purposes that we are discussing here).
      - kibwen 14y ago
        Thanks, I wasn't sure what was considered an "implementation" according to the W3C. In other news, azakai, you work for Mozilla, correct? Have they issued an official statement regarding this?
chrischen 14y ago
Isn't this going to be necessary for a site like YouTube to be able to fully switch off of Flash?
- schoen 14y ago
  Currently YouTube doesn't require Flash Player for the overwhelming majority of its videos. It's a bit unclear whether they are still using RTMPE for some Hollywood stuff (as they were a year or two ago), but if you go to https://www.youtube.com/movies https://www.youtube.com/movies the free movies work perfectly using all free and open source client software, with no Flash Player. Most (or all) of YouTube is implemented as FLV or MP4 files delivered over HTTP. You can watch this in action by using software like youtube-dl. So apart from the purported, perennial Hollywood threat to boycott things, the empirical answer with regard to the existing YouTube seems to be no. (Though maybe there is still some RTMPE lurking somewhere on the site.)
- pessimizer 14y ago
  All YouTube videos (as far as I know) are easy to download and in friendly formats.
pyalot2 14y ago
HTML DRM consists of two parts. The first part is EME (extended media extension) that defines the API how a browser interacts with the CDM (the actual implementation of the DRM) The EME is what is being standardized. The CDM is what is up to the platform provider (or any plug-in provider) to implement, such as Google, Sony, Microsoft etc. There are a couple problems with this. 1) The actual DRM functionality will not help keep people from having to deploy on flash/silverlight because the technology is ladden with proprietary licenses and NDAs. Ordinary web developers will not be able to make use of "HTML DRM" 2) Since the CDM requires to do some user specific encryption/restriction, the CDM will be able to uniquely identify each web user regardless of privacy settings, cookie blockers etc. You will not have control over what the CDM does, it will sacrifice your privacy on the web, absolutely. This is a supercookie on steroids. 3) Due to the CDM having to be provided by third parties as a proprietary blob, this will make it harder to support the DRM on free/libre/speech/beer implementations such as Firefox, Linux etc. 4) It will decrease compatibility of video on the web by fracturing already fractured video support (the codec wars) into the even more fractured DRM format wars. 5) Because the CDM is a proprietary blob, there is no scrutiny, code review and control over what it does. Fiascos such as Sonys rootkits and a host of security exploits in shoddily written proprietary DRM blobs are inevitable. 6) Companies like Google, Microsoft and Apple will use the DRM to gain leverage over their competitors by intentionally denying them compatibility to consume videos of services they created. 7) Companies like Netflix, Amazon etc. will use the DRM to gain leverage over their competitors by denying them the ability to produce videos compatible with their DRM implementation. 8) And finally DRM will be used by everybody implementing it to rise the barrier of entry for companies in the entire market, as well as to exclude innovation.
- bzbarsky 14y ago
  Actually, it's even worse. EME does NOT define how a browser interacts with the CDM at the moment. That's precisely why some people are objecting to it in its current state. EME defines how script in a web page can ask the browser to talk to the CDM. How the browser actually does that is up to the browser and CDM vendor. There is no requirement that any CDMs expose any sort of standardized API that browsers can use to talk to them. For example, given the current proposal Microsoft can ship a CDM on Windows that only IE can talk to, Google can ship a CDM that only works in Chrome, etc. So in its present state the setup can be trivially used to lock out third-party (and especially open-source) browsers: just don't let them talk to any CDMs.
ogmo 14y ago
I don't know what the solution is here, but I'm worried that if we don't implement this solution, the web will fall even faster out of favor to native apps. I'm talking about mobile. Right now running flash or silverlight on your desktop is no big deal. This "solution" is unnecessary. But on mobile we have a real problem: the only way for anyone to deliver encrypted media is via a native app, which is exactly what everyone is doing. That comes at the expense of the web. So now we have an entire generation of users growing up on apps (netflix, hulu, spotify) because those content licensing deals require DRM. The desktop is fading. If we want the web to stay relevant as everything moves to closed ecosystems, this may be a necessary evil, because the web+EME is infinitely more open than the an iPhone/Android app.
jessaustin 14y ago
There is more information at the EFF page [0] linked in TFA, although not quite the same "call to action". [0]: 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...

179 points by hosay123 14y ago

There's a pretty lively thread over on Reddit: http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_we_dont_want_the_hollyweb_drm_in_html5/ http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_...

Daiz 14y ago

I'm actually a bit conflicted about support for DRM schemes in HTML5. I absolute loathe DRM and I wish every damn publisher of every damn type would come to their senses and actually sell DRM-free digital products. However, there is one case where some form of "DRM" does make sense, and that's actual renting - or more specifically, the popular case of "catalog subscription" (ala Spotify, Netflix and so on). You're clearly renting access to a catalog of goods in this kind of model, and therefore it makes sense that you'd want to stop people from permanently acquiring copies in such a scenario, especially if you're selling actual DRM-free downloads at the same time (in my ideal digital store where it makes sense they would offer both of these side-by-side). The catalog subscription model has some clear value to it, and I'd hate for it to disappear due to "technical unfeasibility". As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on. I can't really think of a good solution to this, unless you got the big wigs at various publishing outlets to accept that to do HTML5 streaming, you can only make downloading the rentable versions inconvenient for regular versions (instead of being able to use a heavy-weight closed DRM plugin), but I'm afraid that could be quite challenging. It has worked for Adobe and webfonts, though[1], so maybe there's hope. Forcing HTML5 to be DRM-free could eventually lead to this direction. [1] http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/ http://blog.typekit.com/2009/07/21/serving-and-protecting-fo...

yarrel 14y ago
Renting infinitely copyable goods doesn't make sense. Subscriptions to channels containing them does. DRM doesn't increase the convenience of those channels. It reduces them.
- Daiz 14y ago
  The problem I have is that I can't really imagine the catalog subscription model to be feasible if any and all catalog entries were available to download without DRM. Someone with a fat pipe could just spend a month downloading absolutely everything, cutting the subscription and enjoying the goods for a long time to come, whereas the idea is that the user remains as a subscriber because of the limited time they have for consuming all the content. And while DRM is generally very inconvenient, there are also places where it's mostly "invisible" - Spotify and Netflix are pretty damn convenient on the whole, with pretty much the only major downside being the inability to watch stuff without an internet connection (though Spotify offers limited offline downloads for this reason too). The DRM in Steam is also generally quite invisible to the end-users, which is why people generally do not mind it - and also because Steam offers a lot more convenience with its service than what it takes away with its DRM. As I said, ideally I'd like to see digital stores that combine the catalog subscription model as well as individual DRM-free purchases. Think Netflix, except you could also buy the really good stuff that you like. This would allow you to download DRM-free copies in many formats whenever you want, they could also bundle purchases with stuff like extras, and best of all: since they have a streaming infrastructure in place already they could also offer unlimited streaming for bought titles, even if you don't have a subscription. I imagine it would make for quite the killer service. But if everything could be downloaded DRM-free with just the catalog subscription, the individual sales would not work, and subscriptions would probably have a terrible retention rate. Again, I just can't see the catalog subscription model working without at least some sort of "download prevention". I guess the biggest question is: Can we achieve that without the need for heavyweight black-box DRM schemes? I mean, you'd really just need to stop "casual" downloading - pirates will always find a way around protections, so they can't be stopped, but you'd just have to make sure a regular customer sees value in both the catalog subscription (which would be essentially renting) and individual title purchasing (actual buying).
  - TheCoelacanth 14y ago
    Even with DRM, I wouldn't be subscribed to a service for long if it wasn't continually adding new content.
  - 14y ago
MatthewPhillips 14y ago
> As such, I would at least prefer for most of the tech / architecture to be based on HTML5 stuff instead of closed plugins like Flash, Silverlight, Widevine and so on. It's not really based on open stuff. EME isn't DRM, it provides a way to talk to a DRM service (probably a hardware DRM in most cases). They are creating a false-sense of "open standards" when this thing still won't work in Linux and most not-locked-down platforms.
- Daiz 14y ago
  Yeah, that's the impression I've got as well, which is why I don't ultimately like EME. It would be a slight improvement compared to the current situation (since you could at least move stuff like video playback to HTML5), but would probably just make the situation of "closed binary blob DRM" more persistent and thus worse in the long run.
- bzbarsky 14y ago
  It provides a way for script to talk to a DRM service. Assuming the browser has a way to talk to one already. It doesn't do anything towards providing a way for _browsers_ to talk to DRM services; that's up to the browser manufacturers to license or whatnot.
- eridius 14y ago
  Unfortunately, this sort of problem is basically unsolvable for Linux (and other such "open" platforms). Either you get a proprietary blob that implements a protection scheme, or you simply don't get the functionality being promised. Objecting to efforts to make the situation better for HTML5 experiences on other platforms because it won't work on Linux is, honestly, pretty selfish. It can't work on Linux, so you're basically saying since it can't work for you, it shouldn't work for anyone else too. And that's just dragging down the state of the web to the lowest common denominator.
  - summerdown2 14y ago
    > And that's just dragging down the state of the web to the lowest common denominator. Or up to the state of most openness?
webreac 14y ago
Watermarking makes a lot more sense than DRM. If your name is on the film you just bought, you will not want to publish it on p2p.
- Daiz 14y ago
  It wouldn't really be a feasible solution for video, though. You'd have to re-encode the whole thing for every individual user, which would be incredibly inefficient. Even if you're showing the watermark in just a few places, it'd still require a damn lot of resources. There's also quite a few things out there for removing video watermarks[1], so unless the watermarks were incredibly obtrusive, they'd probably be quite easy to get rid of. And of course you couldn't really put the watermark outside the actual video stream either, since then the user could just strip it out. [1] Like various Avisynth plugins for example: http://avisynth.org/mediawiki/External_filters#Logo_Removal http://avisynth.org/mediawiki/External_filters#Logo_Removal
  - benologist 14y ago
    Is it really true that they can't do it on the fly? Live streaming is creating the video on the fly completely isn't it?
    - Daiz 14y ago
      In case of live streaming, the video is only encoded once and then distributed to a whole bunch of users. If you were doing unique watermarks, you'd have to encode an individual stream for every single user. Encoding is much more taxing than decoding. The end result would be that you'd need a metric crapton of additional processing power, and the quality would be worse since you'd have to use sufficiently fast encoding settings to be able to do it in realtime (as opposed to being able to use a lot more expensive options when the encoding is done just once and separately from the actual streaming process).
      - benologist 14y ago
        What about onlive, they stream(ed) cpu/gpu intensive games in real time on a one-to-one basis?
bsimpson 14y ago
Is anyone here familiar with the proposed spec? Would the DRM be a private binary included with the OS, or an open part of the browser? Unless they're just specifying an API, and all the actual work is done in a private binary, I don't understand how you can have effective DRM in a publicly specified project.
- MatthewPhillips 14y ago
  Could be a private binary, could be a hardware component, but yeah, the actual DRM part is not in this spec.

randall 14y ago

I think DRM makes sense sadly because otherwise it'd be as simple as 'right click, save as' and you'd have the contents of a movie. There'd be little incentive to subscribe to Netflix past a month. Rdio too. Simple anti-copying provisions that are still defeatable, though through effort, help incentivize the migration of those channels. And that's what I really want. I want Hollywood to feel comfortable using the web, because then more open alternatives will emerge when it's a level playing field. (IE watching TV is watching the web.)

CamperBob2 14y ago
There'd be little incentive to subscribe to Netflix past a month. Have you actually used Netflix?
- randall 14y ago
  Sure. Could you provide more context to your question?
  - CamperBob2 14y ago
    It sounded like you were under the impression that it's either possible or desirable to make your own local copy of the entire Netflix library. Why exactly would I want to do that, DRM or no DRM?
darkchasma 14y ago
No, this doesn't make sense in the slightest. Fact 1. If I want a movie or song without paying for it, I can get it. I don't need any more facts, this "solution" doesn't solve fact 1's problem. It simply breaks the internet. So what part of creating a burden that doesn't solve a problem make sense?
- andylei 14y ago
  > Fact 1. If I want a movie or song without paying for it, I can get it. this is actually irrelevant. netflix is contractually obligated to distribute all their content through DRM'ed channels. Hollywood knows that DRM isn't going to stop copying, but they would still like to reduce it, and they certainly aren't going to license their content to services that make copying trivial.

tomelders 14y ago

It's hot HTML's job to fix broken business models.

zanny 14y ago
They are being pressured by businesses that want to support those broken business models like Google. Youtube is a great example - thousands of people are now living their lives off youtube ad revenue, yet you can get a simple addon for any browser to download the mp4s. DRM isn't necessary, old media just wants total control. I seriously think if we just play the battle of attrition, they will die off soon because they can't compete in an on-demand get-what-you-want information free era.

edgesrazor 14y ago

If DRM is inevitable, I'd take a properly implemented DRM that's been through community scrutiny than another Sony rootkit fiasco any time.

yarrel 14y ago
How would you like hooks in your web browser for the Sony root kit? That's what's being proposed at the W3C.
- recoiledsnake 14y ago
  Please, that's hyperbole. Sony rootkit and the DRM present in Flash/Silverlight are worlds apart.
  - ihsw 14y ago
    Actually the description is apt -- the proposal is when a web page loads then a binary blob (that has OS-level hardware access) will be invoked. It would be as simple as including a highly-insecure JS file rather than installing a browser add-on/plug-in/extension/whatever. The security risks cause me imagine EME news that makes the recent Java 0-day news frighteningly tame.
  - pyalot2 14y ago
    It is not hyperbole. EME is a plugin API, and the plugin is not specified, and that is what the DRM is. It is inevitable this will result in another rootkit fiasco. But worse than that, the working of the DRM (called a CDM) will also sacrifice your privacy on the web, because it can inevitably act like a "supercookie" over which you will have no control.
ncallaway 14y ago
My understanding of the proposed EME is that it does not implement any DRM, and DRM implemented for it would likely be opaque software implemented without community scrutiny. The EME (again, by my understanding, I could be wrong) only defines an API to communicate with DRM systems. I don't think this helps us gain any scrutiny over DRM.

chjj 14y ago

A dark future for HTML. I can't really describe the melancholy I feel when thinking about this. In 10 years, we'll be reminiscing about how the web was once an open platform, and we'll kick ourselves for having said at the time, "I hate DRM...but then again, I do like netflix!"

kibwen 14y ago

The W3C requires at least two implementations before standardization can happen, right? Theoretically, if both Webkit and Gecko refused to implement it (or, more diplomatically, "indefinitely deprioritized its implementation"), would this be DOA?

azakai 14y ago
Google and Microsoft are supporters and working on the spec, https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... Which makes two implementations, I am afraid. Unless we can convince at least one of those to stop.
- kibwen 14y ago
  Right, but it's Apple, not Google, who holds the keys to Webkit. Not that I presume that Apple is so benevolent (naive much?), but it wouldn't be the first time that Apple has outright rejected a Googler's patch (I can't remember the link now, something about Dart integration). Obviously Google could always fork the whole project for the sole purpose of implementing DRM, but what a fiasco that would be!
  - azakai 14y ago
    Google doesn't need to officially fork WebKit, it can keep these features in Chromium and not push them into WebKit - like many other features, including the one you mentioned (Dart support that Apple rejected). But Chrome is still a major implementation, it doesn't have to get into WebKit or not (for standardization purposes that we are discussing here).
    - kibwen 14y ago
      Thanks, I wasn't sure what was considered an "implementation" according to the W3C. In other news, azakai, you work for Mozilla, correct? Have they issued an official statement regarding this?

chrischen 14y ago

Isn't this going to be necessary for a site like YouTube to be able to fully switch off of Flash?

schoen 14y ago
Currently YouTube doesn't require Flash Player for the overwhelming majority of its videos. It's a bit unclear whether they are still using RTMPE for some Hollywood stuff (as they were a year or two ago), but if you go to https://www.youtube.com/movies https://www.youtube.com/movies the free movies work perfectly using all free and open source client software, with no Flash Player. Most (or all) of YouTube is implemented as FLV or MP4 files delivered over HTTP. You can watch this in action by using software like youtube-dl. So apart from the purported, perennial Hollywood threat to boycott things, the empirical answer with regard to the existing YouTube seems to be no. (Though maybe there is still some RTMPE lurking somewhere on the site.)
pessimizer 14y ago
All YouTube videos (as far as I know) are easy to download and in friendly formats.

pyalot2 14y ago

HTML DRM consists of two parts. The first part is EME (extended media extension) that defines the API how a browser interacts with the CDM (the actual implementation of the DRM) The EME is what is being standardized. The CDM is what is up to the platform provider (or any plug-in provider) to implement, such as Google, Sony, Microsoft etc. There are a couple problems with this. 1) The actual DRM functionality will not help keep people from having to deploy on flash/silverlight because the technology is ladden with proprietary licenses and NDAs. Ordinary web developers will not be able to make use of "HTML DRM" 2) Since the CDM requires to do some user specific encryption/restriction, the CDM will be able to uniquely identify each web user regardless of privacy settings, cookie blockers etc. You will not have control over what the CDM does, it will sacrifice your privacy on the web, absolutely. This is a supercookie on steroids. 3) Due to the CDM having to be provided by third parties as a proprietary blob, this will make it harder to support the DRM on free/libre/speech/beer implementations such as Firefox, Linux etc. 4) It will decrease compatibility of video on the web by fracturing already fractured video support (the codec wars) into the even more fractured DRM format wars. 5) Because the CDM is a proprietary blob, there is no scrutiny, code review and control over what it does. Fiascos such as Sonys rootkits and a host of security exploits in shoddily written proprietary DRM blobs are inevitable. 6) Companies like Google, Microsoft and Apple will use the DRM to gain leverage over their competitors by intentionally denying them compatibility to consume videos of services they created. 7) Companies like Netflix, Amazon etc. will use the DRM to gain leverage over their competitors by denying them the ability to produce videos compatible with their DRM implementation. 8) And finally DRM will be used by everybody implementing it to rise the barrier of entry for companies in the entire market, as well as to exclude innovation.

bzbarsky 14y ago
Actually, it's even worse. EME does NOT define how a browser interacts with the CDM at the moment. That's precisely why some people are objecting to it in its current state. EME defines how script in a web page can ask the browser to talk to the CDM. How the browser actually does that is up to the browser and CDM vendor. There is no requirement that any CDMs expose any sort of standardized API that browsers can use to talk to them. For example, given the current proposal Microsoft can ship a CDM on Windows that only IE can talk to, Google can ship a CDM that only works in Chrome, etc. So in its present state the setup can be trivially used to lock out third-party (and especially open-source) browsers: just don't let them talk to any CDMs.

ogmo 14y ago

I don't know what the solution is here, but I'm worried that if we don't implement this solution, the web will fall even faster out of favor to native apps. I'm talking about mobile. Right now running flash or silverlight on your desktop is no big deal. This "solution" is unnecessary. But on mobile we have a real problem: the only way for anyone to deliver encrypted media is via a native app, which is exactly what everyone is doing. That comes at the expense of the web. So now we have an entire generation of users growing up on apps (netflix, hulu, spotify) because those content licensing deals require DRM. The desktop is fading. If we want the web to stay relevant as everything moves to closed ecosystems, this may be a necessary evil, because the web+EME is infinitely more open than the an iPhone/Android app.

jessaustin 14y ago

There is more information at the EFF page [0] linked in TFA, although not quite the same "call to action". [0]: 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...