9 ms·

Wow, Cory's article is totally over the top... as are some of the comments in this thread. Let's start with the facts. Here's the spec. It's called Encrypted

Wow, Cory's article is totally over the top... as are some of the comments in this thread. Let's start with the facts. Here's the spec. It's called Encrypted Media Extensions (EME). 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... The EME spec isn't that long, and the introduction has a nice diagram. Go check it out. The W3C spec does not put "DRM in browsers." It allows browsers to use "decryption modules" that already exist elsewhere, like in the OS platform. There are APIs to determine what sorts of "decryption modules" are available and to use them to decrypt media. If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. Sure, it'd be nice if the big media companies stopped insisting on using encryption to distribute their videos. But that's not likely to happen anytime soon. Premium video on the web requires either plug-ins or EME. I think most of us would pick premium web video + EME, rather than premium web video + plug-ins, or (perish the thought) no premium video on the web at all. BTW, open source browsers can easily implement this spec since it doesn't require the browser to implement a "decryption module" themselves. Also, there is a mode called "clear key" that can be used if the underlying platform doesn't have any "decryption module" available. Disclosure: I work at Netflix on streaming video in browsers.

dlitz 14y ago
> Wow, Cory's article is totally over the top... What makes you think it's over the top? We have a public-interest organization pushing DRM, a technology that is decidedly against the public interest. I'm surprised that this is upvoted to the top of the thread, when you haven't done anything except say "this is over the top" and given us a link that explains what DRM is---as if the DRM's detractors don't already know what it is or how it works. > Sure, it'd be nice if the big media companies stopped insisting on using encryption to distribute their videos. But that's not likely to happen anytime soon. That's only true because technologists continue to lie to media companies, telling them that DRM is feasible and not harmful to their interests (even though, in addition to being against the public interest, it tends to cause monopolization of their distribution chains---just ask the music industry happened with iTunes). Look, these media companies are looking to us for advice; We're doing both them an ourselves a disservice by continuing to sell them DRM snake oil.
- trunnell 14y ago
  > you haven't done anything except say "this is over the top" and given us a link that explains what DRM is The link is the Encrypted Media Extensions (EME) spec. EME is not DRM. It allows access to a decryption system outside of the browser. That is different than what Cory and others are claiming.
  - makomk 14y ago
    It is precisely DRM. The entire point of it is to protect media streams from copying, and the BBC has specifically demanded that it be robust enough DRM enough to trigger anti-circumvention laws and allow them to have anyone who does manage to copy the decrypted streams arrested and jailed.
    - trunnell 14y ago
      EME merely allows access to a DRM system. I know this distinction sounds overly precise, but the fact that EME does not mandate a DRM system makes a big difference if you want to implement this spec in a browser. Were EME to actually specify the DRM then this spec would never have been jointly proposed by Google, Microsoft, and Netflix. It is an effective but incorrect bit of rhetoric when Cory equates EME to DRM in the article.
      - shmerl 14y ago
        It's all just an empty demagogy in lawyers style. EME is about DRM, but the language was made generic to avoid mentioning DRM. So to make things fair and clear - EME is intended to serve the cause of those who push DRM on the Web. And it's enough of a reason to oppose EME.
        jshen 14y ago
        Look at ABC as an example. You can watch their video content via a Flash plugin, or via a native app for IOS. They do not let you watch their content via a browser without Flash. This is fairly common for media companies. Now think of the implications of not having EME. It creates a situation that pushes users away from the open web and onto native apps and proprietary plugins. EME is needed so that users don't move away from browsers to native apps. Users will go where the content is, no matter how vigorously you shout your ideology.
logn 14y ago
Thanks. I read the spec and saw this regarding open source browsers: "9.5. Can I ensure the content key is protected without working with a content protection provider? "No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. [...] In addition, it is not something that fully open source browsers could natively support."
- trunnell 14y ago
  Exactly. This illustrates why this W3C spec is not DRM. Some other DRM technology is needed for certain modes.
  - Natsu 14y ago
    So it's not DRM, it's just a way for 3rd parties to plug in their own DRM system. Sorry, that's worse, not better.
    - trunnell 14y ago
      Third parties, namely Flash and Silverlight, already plug in their own DRM systems via NSAPI. How is this worse?
      - trunnell 14y ago
        Oops, I meant NPAPI (not NSAPI).
      - darklajid 14y ago
        Depends. What Flash and Silverlight do is just as bad => This proposal isn't worse. But Flash and Silverlight are dead or dying and were never public specifications we cared about. What I consider 'worse' here in this proposal is that we'd kind of 'bless' the DRM layer in HTML. I fear a comment like "Hey, it's part of HTML 5 so it has to be good, right?" if nonsense like this is added.
      - Natsu 14y ago
yk 14y ago
A few question about the EME proposal: > BTW, open source browsers can easily implement this spec since it doesn't require the browser to implement a "decryption module" themselves. Does this mean, that the 'decryption module' is necessary closed source? And from the spec: >4.1 "Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified. The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed. Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received. This acknowledgement must also be in the form of a CDM-specific message. " Perhaps I misread, but the datastream is relayed from the browser to the CDM ( and the browser loads and potentially modifies the CDM), so how does the standard ensure that the proof of destruction is actually a message from the CDM and not from the browser? >9.1 "Everything from user-generated content to be shared with family (user is not an adversary) to online radio to feature-length movies." Does this imply that from the standpoint of the proposal the user is an adversary, unless specifically noted?
- mcintyre1994 14y ago
  > Does this mean, that the 'decryption module' is necessary closed source? Is there any precedent of anything being closed source behind standards implementations from the W3C? That seems unlikely, this seems terrible.
Gormo 14y ago
> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. So, a plugin-free web that requires plugins?
- jmodp 14y ago
  Smaller specialized standard plugins.
  - Turing_Machine 14y ago
    Smaller, specialized, closed-source plugins that are practically guaranteed to become attack vectors. Personally, I'm glad Flash is dying and am not in any real hurry to replace it.
- trunnell 14y ago
  No, it doesn't require plugins. The EME approach is agnostic to whether the "decryption module" is implemented by the OS, the browser, or a plug-in. Nothing specifies where they come from, but in practice I think they will usually be provided by the OS. We'll have to see what browsers end up doing. There will probably be a variety of approaches.
chime 14y ago
> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. I fail to see the technical reason why encryption is necessary for Netflix. HTML5 is a technical spec. It does not need to be riddled with extensions to fulfill business needs. I can't view a stream if I'm not a paying member logged in to the website or XBox/Roku/AppleTV device. Once I am able to view the stream, encryption or not, I can record it through a number of hardware/software mechanisms if I am technically savvy. If I'm not technically savvy, I can't record it regardless of encryption. If I can somehow access the stream without logging in, say the files are stored on CDN and available to everyone over HTTP(S), then you should work on preventing that. W3C/HTML5 are designing specs for the long haul. I am pretty sure I will be writing web apps in a decade too, like I did a decade ago. iTunes no longer has DRM'ed audio. Who knows, in a decade, Hollywood will give up DRM too, with pressure from Netflix, Apple, Amazon, and Google. But if engineers at these very companies that should be pushing for open-web, insist on burdening the spec to cope with DRM, I doubt we'll ever see that future.
- Lewisham 14y ago
  > The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.
  - chime 14y ago
    I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point. I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.
ferongr 14y ago
Content decryption modules are plugins by another name. The spec gives no guarantee that a given CDM can be interoperable with all browsers (being a binary it can possible arbitrarily reject to operate with a given browser), Operating system (because it's a binary) or that all browser functions and accessibility features will work with them (CDMs could completely bypass the browser's rendering pipeline and overlay the content using protected paths). The proposal is a step back for the openness and interoperability of the Web. Substituting plugins with binary CDMs is not progress and I doubt any kind of popular content which rights are held by the big copyright giants will be compatible with clearkey. I foresee that GNU/Linux users will be shafted and will not be able to access DRM'ed content and the proposal is toxic towards the Web.
- trunnell 14y ago
  Content decryption modules probably won't be plug-ins. > The spec gives no guarantee that a given CDM can be interoperable with all browsers. I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used. > The proposal is a step back for the openness and interoperability of the Web. If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web", then I disagree. This spec expands the set of applications that can be implemented in HTML5 and javascript. It doesn't immediately change the interoperability of these applications, which already have limited platform reach, but it at least opens the door for more platforms (like Linux).
  - ferongr 14y ago
    >I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used. The spec may not have specifics on the CDMs themselves but that doesn't really matter. A closed-source, platform specific CDM (e.g. one distributed with Windows containing keys for the major media distribution behemoths) is very bad for interoperability. Such kinds of CDMs will probably not find their way to GNU/Linux of BSDs. >If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web" The Web is the platform itself, not the services offered over it in my book. Companies and business models rise and die all the time but the platform of Web is what remains behind. It should not be saddled by companies like Netflix that use it and try to influence its direction to further their interests. And there is no open door for open-source, CDMs on open-source systems without a "Protected Media Path" or similar.
comex 14y ago
Simple question: Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay? I don't think it has any chance - DRM on PCs is always pretty quickly bypassed - which is why it frustrates me so: it will likely end up preventing Linux users from accessing content legitimately, or Mac users from AirPlaying content to their TVs, with no actual benefit against piracy. At least where it pertains to high value content, it is little but a lie mutually agreed upon with rightsholders. :(
- jedberg 14y ago
  > Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay? No, and that isn't the purpose. The purpose is so that Netflix can show you movies that Hollywood lawyers insist be encumbered with DRM because they won't try and understand that DRM doesn't actually do anything. Maybe one day Netflix will be big enough to push back, like Apple did with mp3 DRM, but until then, this is the only way to show premium content to people without requiring a plugin from Microsoft. > it will likely end up preventing Linux users from accessing content legitimately, Actually, the inclusion of EME in HTML5 is exactly what would enable you to watch content on Linux.
  - entropy_ 14y ago
    So we're including things in the HTML spec just to satisfy hollywood lawyers now? We would be saddling a spec(and any browser wishing to implement it) for what will probably be a decade and possibly more just so hollywood execs/lawyers can cover their asses and protect a dying business model which will probably be outlived by both the spec and implementing browsers. I find that stupid, to say the least. Especially since, it is highly likely that at some point, some company will be big enough to push back and distribute things DRM-free just like Apple did with iTunes.
    - jedberg 14y ago
      But once the model dies, why does it matter if it is in the spec? If a company (say Apple) gets big enough to demand no DRM, like Apple did with music, then no one will use the standard anymore. So why does it matter if the standard makes it easier to more widely distribute the content, which will only help in hastening its demise by allowing someone to grow big enough to push back?
Flenser 14y ago
Will EMEs be a new attack surface for security exploits? Who will be creating them and will we be able to rely on them to fix bugs responsibly and in a timely manner?
shmerl 14y ago
1. DRM is unethical. 2. DRM is a dying trend. 3. DRM goes against the principles of the open Web which W3C is supposed to promote. Given the above, it's not the business of W3C to promote DRM on the Web let alone to standardize it. Quite on the contrary, W3C should prevent DRM proliferation. And it's simply dumb to standardize the dying trends. Why doesn't someone propose to make Flash a Web standard for example? It's still widely used, but it's a dying trend for the Web. > The W3C spec does not put "DRM in browsers." It allows browsers to use "decryption modules" that already exist elsewhere, like in the OS platform. There are APIs to determine what sorts of "decryption modules" are available and to use them to decrypt media. See the W3C mail list. It is about putting DRM in the browsers. The language was watered down on purpose, but it doesn't change the reality. The bottom line - those who think they need DRM - let them stick with what they have. Those who want to move to open web - don't need plugins and don't need DRM either.
shmerl 14y ago
Netflix doesn't deserve respect for obliging the movie industry in pushing DRM to the Web.
duaneb 14y ago
So, if these decryption modules are already in the OS, what's to stop people from straight up ripping the streams?
charlieok 14y ago
So in this scenario, what is the “decryption module” likely to be? Software you download? Software that comes with the OS? Hardware baked into the chip or motherboard? What would prevent determined users from reading, and publishing, any “secret” keys used by such a decryption module? I'm assuming the answer is nothing, since this seems to have happened with every DRM scheme that has been tried.

dlitz 14y ago

> Wow, Cory's article is totally over the top... What makes you think it's over the top? We have a public-interest organization pushing DRM, a technology that is decidedly against the public interest. I'm surprised that this is upvoted to the top of the thread, when you haven't done anything except say "this is over the top" and given us a link that explains what DRM is---as if the DRM's detractors don't already know what it is or how it works. > Sure, it'd be nice if the big media companies stopped insisting on using encryption to distribute their videos. But that's not likely to happen anytime soon. That's only true because technologists continue to lie to media companies, telling them that DRM is feasible and not harmful to their interests (even though, in addition to being against the public interest, it tends to cause monopolization of their distribution chains---just ask the music industry happened with iTunes). Look, these media companies are looking to us for advice; We're doing both them an ourselves a disservice by continuing to sell them DRM snake oil.

trunnell 14y ago
> you haven't done anything except say "this is over the top" and given us a link that explains what DRM is The link is the Encrypted Media Extensions (EME) spec. EME is not DRM. It allows access to a decryption system outside of the browser. That is different than what Cory and others are claiming.
- makomk 14y ago
  It is precisely DRM. The entire point of it is to protect media streams from copying, and the BBC has specifically demanded that it be robust enough DRM enough to trigger anti-circumvention laws and allow them to have anyone who does manage to copy the decrypted streams arrested and jailed.
  - trunnell 14y ago
    EME merely allows access to a DRM system. I know this distinction sounds overly precise, but the fact that EME does not mandate a DRM system makes a big difference if you want to implement this spec in a browser. Were EME to actually specify the DRM then this spec would never have been jointly proposed by Google, Microsoft, and Netflix. It is an effective but incorrect bit of rhetoric when Cory equates EME to DRM in the article.
    - shmerl 14y ago
      It's all just an empty demagogy in lawyers style. EME is about DRM, but the language was made generic to avoid mentioning DRM. So to make things fair and clear - EME is intended to serve the cause of those who push DRM on the Web. And it's enough of a reason to oppose EME.
      - jshen 14y ago
        Look at ABC as an example. You can watch their video content via a Flash plugin, or via a native app for IOS. They do not let you watch their content via a browser without Flash. This is fairly common for media companies. Now think of the implications of not having EME. It creates a situation that pushes users away from the open web and onto native apps and proprietary plugins. EME is needed so that users don't move away from browsers to native apps. Users will go where the content is, no matter how vigorously you shout your ideology.

logn 14y ago

Thanks. I read the spec and saw this regarding open source browsers: "9.5. Can I ensure the content key is protected without working with a content protection provider? "No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. [...] In addition, it is not something that fully open source browsers could natively support."

trunnell 14y ago
Exactly. This illustrates why this W3C spec is not DRM. Some other DRM technology is needed for certain modes.
- Natsu 14y ago
  So it's not DRM, it's just a way for 3rd parties to plug in their own DRM system. Sorry, that's worse, not better.
  - trunnell 14y ago
    Third parties, namely Flash and Silverlight, already plug in their own DRM systems via NSAPI. How is this worse?
    - trunnell 14y ago
      Oops, I meant NPAPI (not NSAPI).
    - darklajid 14y ago
      Depends. What Flash and Silverlight do is just as bad => This proposal isn't worse. But Flash and Silverlight are dead or dying and were never public specifications we cared about. What I consider 'worse' here in this proposal is that we'd kind of 'bless' the DRM layer in HTML. I fear a comment like "Hey, it's part of HTML 5 so it has to be good, right?" if nonsense like this is added.
    - Natsu 14y ago

yk 14y ago

A few question about the EME proposal: > BTW, open source browsers can easily implement this spec since it doesn't require the browser to implement a "decryption module" themselves. Does this mean, that the 'decryption module' is necessary closed source? And from the spec: >4.1 "Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified. The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed. Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received. This acknowledgement must also be in the form of a CDM-specific message. " Perhaps I misread, but the datastream is relayed from the browser to the CDM ( and the browser loads and potentially modifies the CDM), so how does the standard ensure that the proof of destruction is actually a message from the CDM and not from the browser? >9.1 "Everything from user-generated content to be shared with family (user is not an adversary) to online radio to feature-length movies." Does this imply that from the standpoint of the proposal the user is an adversary, unless specifically noted?

mcintyre1994 14y ago
> Does this mean, that the 'decryption module' is necessary closed source? Is there any precedent of anything being closed source behind standards implementations from the W3C? That seems unlikely, this seems terrible.

Gormo 14y ago

> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. So, a plugin-free web that requires plugins?

jmodp 14y ago
Smaller specialized standard plugins.
- Turing_Machine 14y ago
  Smaller, specialized, closed-source plugins that are practically guaranteed to become attack vectors. Personally, I'm glad Flash is dying and am not in any real hurry to replace it.
trunnell 14y ago
No, it doesn't require plugins. The EME approach is agnostic to whether the "decryption module" is implemented by the OS, the browser, or a plug-in. Nothing specifies where they come from, but in practice I think they will usually be provided by the OS. We'll have to see what browsers end up doing. There will probably be a variety of approaches.

chime 14y ago

> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. I fail to see the technical reason why encryption is necessary for Netflix. HTML5 is a technical spec. It does not need to be riddled with extensions to fulfill business needs. I can't view a stream if I'm not a paying member logged in to the website or XBox/Roku/AppleTV device. Once I am able to view the stream, encryption or not, I can record it through a number of hardware/software mechanisms if I am technically savvy. If I'm not technically savvy, I can't record it regardless of encryption. If I can somehow access the stream without logging in, say the files are stored on CDN and available to everyone over HTTP(S), then you should work on preventing that. W3C/HTML5 are designing specs for the long haul. I am pretty sure I will be writing web apps in a decade too, like I did a decade ago. iTunes no longer has DRM'ed audio. Who knows, in a decade, Hollywood will give up DRM too, with pressure from Netflix, Apple, Amazon, and Google. But if engineers at these very companies that should be pushing for open-web, insist on burdening the spec to cope with DRM, I doubt we'll ever see that future.

Lewisham 14y ago
> The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.
- chime 14y ago
  I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point. I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.

ferongr 14y ago

Content decryption modules are plugins by another name. The spec gives no guarantee that a given CDM can be interoperable with all browsers (being a binary it can possible arbitrarily reject to operate with a given browser), Operating system (because it's a binary) or that all browser functions and accessibility features will work with them (CDMs could completely bypass the browser's rendering pipeline and overlay the content using protected paths). The proposal is a step back for the openness and interoperability of the Web. Substituting plugins with binary CDMs is not progress and I doubt any kind of popular content which rights are held by the big copyright giants will be compatible with clearkey. I foresee that GNU/Linux users will be shafted and will not be able to access DRM'ed content and the proposal is toxic towards the Web.

trunnell 14y ago
Content decryption modules probably won't be plug-ins. > The spec gives no guarantee that a given CDM can be interoperable with all browsers. I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used. > The proposal is a step back for the openness and interoperability of the Web. If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web", then I disagree. This spec expands the set of applications that can be implemented in HTML5 and javascript. It doesn't immediately change the interoperability of these applications, which already have limited platform reach, but it at least opens the door for more platforms (like Linux).
- ferongr 14y ago
  >I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used. The spec may not have specifics on the CDMs themselves but that doesn't really matter. A closed-source, platform specific CDM (e.g. one distributed with Windows containing keys for the major media distribution behemoths) is very bad for interoperability. Such kinds of CDMs will probably not find their way to GNU/Linux of BSDs. >If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web" The Web is the platform itself, not the services offered over it in my book. Companies and business models rise and die all the time but the platform of Web is what remains behind. It should not be saddled by companies like Netflix that use it and try to influence its direction to further their interests. And there is no open door for open-source, CDMs on open-source systems without a "Protected Media Path" or similar.

comex 14y ago

Simple question: Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay? I don't think it has any chance - DRM on PCs is always pretty quickly bypassed - which is why it frustrates me so: it will likely end up preventing Linux users from accessing content legitimately, or Mac users from AirPlaying content to their TVs, with no actual benefit against piracy. At least where it pertains to high value content, it is little but a lie mutually agreed upon with rightsholders. :(

jedberg 14y ago
> Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay? No, and that isn't the purpose. The purpose is so that Netflix can show you movies that Hollywood lawyers insist be encumbered with DRM because they won't try and understand that DRM doesn't actually do anything. Maybe one day Netflix will be big enough to push back, like Apple did with mp3 DRM, but until then, this is the only way to show premium content to people without requiring a plugin from Microsoft. > it will likely end up preventing Linux users from accessing content legitimately, Actually, the inclusion of EME in HTML5 is exactly what would enable you to watch content on Linux.
- entropy_ 14y ago
  So we're including things in the HTML spec just to satisfy hollywood lawyers now? We would be saddling a spec(and any browser wishing to implement it) for what will probably be a decade and possibly more just so hollywood execs/lawyers can cover their asses and protect a dying business model which will probably be outlived by both the spec and implementing browsers. I find that stupid, to say the least. Especially since, it is highly likely that at some point, some company will be big enough to push back and distribute things DRM-free just like Apple did with iTunes.
  - jedberg 14y ago
    But once the model dies, why does it matter if it is in the spec? If a company (say Apple) gets big enough to demand no DRM, like Apple did with music, then no one will use the standard anymore. So why does it matter if the standard makes it easier to more widely distribute the content, which will only help in hastening its demise by allowing someone to grow big enough to push back?

Flenser 14y ago

Will EMEs be a new attack surface for security exploits? Who will be creating them and will we be able to rely on them to fix bugs responsibly and in a timely manner?

shmerl 14y ago

1. DRM is unethical. 2. DRM is a dying trend. 3. DRM goes against the principles of the open Web which W3C is supposed to promote. Given the above, it's not the business of W3C to promote DRM on the Web let alone to standardize it. Quite on the contrary, W3C should prevent DRM proliferation. And it's simply dumb to standardize the dying trends. Why doesn't someone propose to make Flash a Web standard for example? It's still widely used, but it's a dying trend for the Web. > The W3C spec does not put "DRM in browsers." It allows browsers to use "decryption modules" that already exist elsewhere, like in the OS platform. There are APIs to determine what sorts of "decryption modules" are available and to use them to decrypt media. See the W3C mail list. It is about putting DRM in the browsers. The language was watered down on purpose, but it doesn't change the reality. The bottom line - those who think they need DRM - let them stick with what they have. Those who want to move to open web - don't need plugins and don't need DRM either.

shmerl 14y ago

Netflix doesn't deserve respect for obliging the movie industry in pushing DRM to the Web.

duaneb 14y ago

So, if these decryption modules are already in the OS, what's to stop people from straight up ripping the streams?

charlieok 14y ago

So in this scenario, what is the “decryption module” likely to be? Software you download? Software that comes with the OS? Hardware baked into the chip or motherboard? What would prevent determined users from reading, and publishing, any “secret” keys used by such a decryption module? I'm assuming the answer is nothing, since this seems to have happened with every DRM scheme that has been tried.