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.
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.
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.
> 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.
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.
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!"
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?
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.
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.
I agree, there needs to be one open DRM specification that everybody can implement. There can then be discussion and debate about what level of DRM is reasonable; balancing rights of content holders and content consumers. Nobody is going to be perfectly happy but such is life. Every time the drm is broken there can be a new revision of the spec, so if you want to play netflix your browser has to be up to date. Ideally there would an open source reference implementation shared by the open source browsers (webkit,firefox) so the impact on development resources are minimized.
You will get a Sony rootkit fiasco this time around as well.
The HTML DRM (EME) is nothing but a plugin API. The plugin is something like Widevines DRM, called a CDM, (already in use on chromebooks) that browsers will no install on your machine without your consent.
The working of the CDM/DRM itself is not specified in any way. Repeated request at specification have repeatedly been rebuffed and ridiculed by Google, Netflix and Microsoft.
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.)
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?
Currently Silverlight and Flash are NPAPI plugins, which means that Chromium and Firefox users can use it, so studios can't force any anti-features on users.
But by pushing EME that requires unspecified CDMs without public API the studios will be able to license them only to browser vendors who agree to their wishes and cut off other vendors with DMCA anti-circumvention laws.
They can let Chrome-proper with Google Widevine DRM to work, and cut off Chromium users.
EME+CDM doesn't enable any broader interoperability than NPAPI does. It's still a binary blob. They still don't care about Linux. Apple still won't let them put plugins in iOS Safari.
EME+CDM doesn't give them better browser integration, because the DRM must bypass browser's media stack entirely (otherwise you could modify Firefox or Chromium to dump the video).
But EME+CDM kills NPAPI as binary-DRM-blob interface and shifts power from browser vendors to CDM providers.
Anything on netflix exist on torrent sites, and yet, netflix get paid subscribers.
A lot of people subscribe on netflix for the service. Netflix maintain the hardrives, servers, and catalogs of films. They deal with "downloading" of the new movies when they are released.
Even if "right click, save as" was enabled, you still need to download it from a friend or some torrent third party site. You need to know the name of the movie, and deal with software for downloading. You need to know about magenet links and torrent files and seed scores and whatnot. If you just got home from a 10hour work shift, then many people just want to sit down and be entertained for a few hours. Thus there is a need for a service which provides in easy package that will fulfill this need.
netflix provides the same service as a DVD stall at the gas station. It just do not compete with torrent sites. People don't by the content, they buy the service.
Everything that's on Netflix is on The Pirate Bay (or other torrent sites) for free. By your logic there'd be little incentive to subscribe to Netflix at all today.
So how come Netflix has customers? Either you're wrong or some piece of the puzzle is missing (if so, what?)
Rdio is a great example as they currently don't use any form of DRM (if you use the Chrome UA and don't have flash player installed). So I could download songs from Rdio and save them away, but I've never bothered because I want to listen from wherever I am -- the value of the service isn't just having a bunch of music files, but all the other stuff too.
Netflix is probably similar (though I personally use it only infrequently) they provide a huge amount of value via recommendations and having a client on every device (versus downloading the stream, setting up some kind of local server to watch movies on my iPad/TV/whatever, only it'll have a clunkier interface, no recommendations, bad metadata, etc).
I guess what I'm saying is that these guys should all be able to keep people honest by offering the best experience -- a better experience than the illegal alternative.
As an aside: I work on browsers and I really don't like the idea of having to sign agreements and ship binary modules to have a "working" browser. Chrome started shipping widevine a while ago, though I'm not sure where that gets used. It's a bad road which locks out the little guy (but pragmatically that's the way things go...).
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.
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 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.)
[+] [-] pyalot2|13 years ago|reply
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|13 years ago|reply
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.
[+] [-] randall|13 years ago|reply
[+] [-] Daiz|13 years ago|reply
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-fo...
[+] [-] MatthewPhillips|13 years ago|reply
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.
[+] [-] yarrel|13 years ago|reply
Subscriptions to channels containing them does.
DRM doesn't increase the convenience of those channels. It reduces them.
[+] [-] webreac|13 years ago|reply
[+] [-] bsimpson|13 years ago|reply
[+] [-] hosay123|13 years ago|reply
[+] [-] chjj|13 years ago|reply
[+] [-] kibwen|13 years ago|reply
[+] [-] azakai|13 years ago|reply
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.
[+] [-] bzbarsky|13 years ago|reply
So that's one implementation, in WebKit.
[+] [-] tomelders|13 years ago|reply
[+] [-] zanny|13 years ago|reply
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|13 years ago|reply
[+] [-] yarrel|13 years ago|reply
That's what's being proposed at the W3C.
[+] [-] ncallaway|13 years ago|reply
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.
[+] [-] gerdusvz|13 years ago|reply
[+] [-] pyalot2|13 years ago|reply
The HTML DRM (EME) is nothing but a plugin API. The plugin is something like Widevines DRM, called a CDM, (already in use on chromebooks) that browsers will no install on your machine without your consent.
The working of the CDM/DRM itself is not specified in any way. Repeated request at specification have repeatedly been rebuffed and ridiculed by Google, Netflix and Microsoft.
[+] [-] randall|13 years ago|reply
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.)
[+] [-] darkchasma|13 years ago|reply
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?
[+] [-] pornel|13 years ago|reply
https://plus.google.com/107429617152575897589/posts/iPmatxBY...
Currently Silverlight and Flash are NPAPI plugins, which means that Chromium and Firefox users can use it, so studios can't force any anti-features on users.
But by pushing EME that requires unspecified CDMs without public API the studios will be able to license them only to browser vendors who agree to their wishes and cut off other vendors with DMCA anti-circumvention laws.
They can let Chrome-proper with Google Widevine DRM to work, and cut off Chromium users.
EME+CDM doesn't enable any broader interoperability than NPAPI does. It's still a binary blob. They still don't care about Linux. Apple still won't let them put plugins in iOS Safari.
EME+CDM doesn't give them better browser integration, because the DRM must bypass browser's media stack entirely (otherwise you could modify Firefox or Chromium to dump the video).
But EME+CDM kills NPAPI as binary-DRM-blob interface and shifts power from browser vendors to CDM providers.
[+] [-] belorn|13 years ago|reply
A lot of people subscribe on netflix for the service. Netflix maintain the hardrives, servers, and catalogs of films. They deal with "downloading" of the new movies when they are released.
Even if "right click, save as" was enabled, you still need to download it from a friend or some torrent third party site. You need to know the name of the movie, and deal with software for downloading. You need to know about magenet links and torrent files and seed scores and whatnot. If you just got home from a 10hour work shift, then many people just want to sit down and be entertained for a few hours. Thus there is a need for a service which provides in easy package that will fulfill this need.
netflix provides the same service as a DVD stall at the gas station. It just do not compete with torrent sites. People don't by the content, they buy the service.
[+] [-] rmc|13 years ago|reply
So how come Netflix has customers? Either you're wrong or some piece of the puzzle is missing (if so, what?)
[+] [-] ihsw|13 years ago|reply
They propose to run third-party binary blobs with OS-level hardware access -- all the security nightmares of Flash/Java plug-ins but even worse.
[+] [-] randallu|13 years ago|reply
Netflix is probably similar (though I personally use it only infrequently) they provide a huge amount of value via recommendations and having a client on every device (versus downloading the stream, setting up some kind of local server to watch movies on my iPad/TV/whatever, only it'll have a clunkier interface, no recommendations, bad metadata, etc).
I guess what I'm saying is that these guys should all be able to keep people honest by offering the best experience -- a better experience than the illegal alternative.
As an aside: I work on browsers and I really don't like the idea of having to sign agreements and ship binary modules to have a "working" browser. Chrome started shipping widevine a while ago, though I'm not sure where that gets used. It's a bad road which locks out the little guy (but pragmatically that's the way things go...).
[+] [-] CamperBob2|13 years ago|reply
Have you actually used Netflix?
[+] [-] ogmo|13 years ago|reply
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|13 years ago|reply
[0]: https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...
[+] [-] chrischen|13 years ago|reply
[+] [-] schoen|13 years ago|reply
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|13 years ago|reply