5 ms·

1. The only way to have even somewhat secure Digital Restrictions Management is to have some proprietary binary on the local machine which can authenticate itse

1. The only way to have even somewhat secure Digital Restrictions Management is to have some proprietary binary on the local machine which can authenticate itself to the display device. This requires a level of access permission which you do not want to provide to the web in general. 2. If the DRM blob were delivered via the web, then it would be trivially easy to connect through a proxy that delivered its own ineffective DRM blob. Content companies would not accept this solution. 3. The goal of EME is not to increase the number of people who can access restricted content, it's to provide a replacement for the rapidly collapsing Flash Player pseudo-standard. The various content companies require their distributors to use something at least as good as Flash, but YouTube et al know that Flash probably won't exist in a few years, so the race is on to see which replacement will dominate the market. --- The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. This position, in my opinion, is fantastically optimistic. If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback.

shmerl 13y ago
How will the open Web advance if EME is added to the standard? Using HTML with DRM modules in a "standard" way doesn't make the Web any more open, than when that DRM is outside outside the browser altogether. I.e. while content companies are crazy bent on DRM, let them use their custom applications all they want. What's the problem with that? In time they might gain sanity and drop this useless junk. But their mind sickness is not a reason to pollute the standard with it as well.
- jmillikin 13y ago
  HTML+DRM is closer to an open web than a locally installed proprietary application + DRM.
  - shmerl 13y ago
    Those who are interested in open Web aren't going to use any DRM, and they could just avoid those external applications. Now they have to worry about disabling EME in the browser, and if that's even possible, since it's a "standard". I clearly see EME to be a setback to the open Web. If content companies aren't interested in open Web, let them stay outside it, until they reconsider.
  - pppppowerbook 13y ago
    > HTML+DRM is closer to an open web than a locally installed proprietary application + DRM. HTML+DRM is closer to a fully locked-down proprietary-only DRM -web than a 3rd-party locally installed proprietary application + DRM.
  - azakai 13y ago
    > HTML+DRM is closer to an open web than a locally installed proprietary application + DRM. No, HTML+DRM still requires, in addition to the EME API implementation, the actual DRM module. The DRM module will be a locally installed proprietary application - not something standardized, not open, not cross-platform not cross-browser. There are currently 2 such DRM modules, one by Microsoft for IE and one by Google for Chrome. They are proprietary binary blobs, non-standard except for the small external API interface to EME, and are the result of private collaboration with content creation companies.
chimeracoder 13y ago
> The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. No, that's not the expectation of EME opponents. EME opponents understand that companies will continue to use restricted access, as they always have, but want them to do it off-spec and on their own dime. > If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback. That would be far less of a setback for the open web than the current state, which bakes the notion of restricted access into the open standards.
- jmillikin 13y ago
  "off-spec and on their own dime" could also be written "for only the top 2-3 most popular operating systems". If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine, then that's a significant reason for users to buy the completely proprietary systems. > That would be far less of a setback for the open web > than the current state, which bakes the notion of > restricted access into the open standards. If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized.
  - chimeracoder 13y ago
    > If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine The status quo is that Linux users are already locked out of Netflix. The only reason that Cyanogenmod users aren't is because they can run the standard Android apk, which, incidentally, is a separate proprietary blob that Netflix had to write and produce on their own dime. I'd rather vendors be forced to ship proprietary binaries that they have to produce themselves than for them to offload the work onto open-source browsers (or, worse, be able to pressure open-source browsers to cripple their own functionality in order to preserve DRM). > If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized. If widespread restrictions are going to exist, it's better for them to be less convenient for everyone involved (both consumers and distributors), not more.
azakai 13y ago
> If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback. First thing, Chrome is a proprietary browser platform. Only Chromium should be in the last sentence. I believe Chrome already ships with EME; I am not sure if that includes Google's DRM plugin for it as well, but if not then that is soon to come as well. Chrome already ships with various other proprietary code (Flash, SwiftShader, a PDF reader, etc.) so this would not be a new thing. Google and Microsoft have been developing proprietary DRM plugins, with Netflix and Hollywood, for their browsers. EME is just a generic API to those plugins. So your comparison of what will happen with vs. without EME appears flawed: in both cases, only proprietary browsers that include DRM plugins, which are the result of private collaboration with Netflix and Hollywood, will be able to access content. And yes, that would leave out open source browsers like Firefox and Chromium - with or without EME. I also disagree with the premise underlying > The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. This position, in my opinion, is fantastically optimistic. I agree to the conclusion - that it is highly optimistic to see Hollywood quickly move to unrestricted video. But you are assuming there is no other option. There are in fact several: 1. Watermarking as an alternative to DRM, that achieves similar results. 2. Non-proprietary DRM solutions, either standardized (which EME does nothing for, intentionally) or done in web content (HTML5). Those would not be as secure as proprietary binary blobs (what EME assumes), but could still prevent 99% of casual piracy - and professional piracy isn't stopped even by the blobs. 3. Eventual movement to unrestricted video, perhaps after a period of using 1 and/or 2. We saw this in music, it took a while, but sanity prevailed.
- jmillikin 13y ago
  > First thing, Chrome is a proprietary browser platform. > Only Chromium should be in the last sentence. I believe > Chrome already ships with EME; I am not sure if that > includes Google's DRM plugin for it as well, but if not > then that is soon to come as well. Chrome already ships > with various other proprietary code (Flash, SwiftShader, > a PDF reader, etc.) so this would not be a new thing. I want to distinguish between a browser platform, where the browser is considered an integral part of the underlying OS, and standalone web browsers. Chrome and Firefox are regular applications, they do not (yet?) feature the deep OS integration that would be necessary to implement functional digital restrictions. Google's DRM plugin is currently available for both Firefox and Chrome through the standard Netscape plugin API, but is not bundled with either browser. > in both cases, only proprietary browsers that include > DRM plugins, which are the result of private > collaboration with Netflix and Hollywood, will be able > to access content. And yes, that would leave out open > source browsers like Firefox and Chromium - with or > without EME. If I'm reading the EME spec correctly, then EME plugins can be installable by the end user in the same way that Netscape plugins are today. Assuming the browser chooses to implement the plugin system, both Firefox and Chromium ought to be able to use DRM plugins from the system. > 2. Non-proprietary DRM solutions, either standardized > (which EME does nothing for, intentionally) or done in > web content (HTML5). Those would not be as secure as > proprietary binary blobs (what EME assumes), but could > still prevent 99% of casual piracy - and professional > piracy isn't stopped even by the blobs. Any non-proprietary DRM solution would not be able to stop even casual piracy. The casual pirate will search for [download netflix movie], click the first link, install a browser extension, and get a one-step piracy button right in their browser. That's what content companies are terrified of, and any DRM system that can't stop this sort of pirate will not be accepted. > 3. Eventual movement to unrestricted video, perhaps > after a period of using 1 and/or 2. We saw this in > music, it took a while, but sanity prevailed. We have not seen a victory for free formats in music. The majority of music online is still distributed wrapped in layers of digital restrictions (e.g. Pandora, Spotify) or in patent-encumbered formats (e.g. iTunes, Google Play, Amazon).

shmerl 13y ago

How will the open Web advance if EME is added to the standard? Using HTML with DRM modules in a "standard" way doesn't make the Web any more open, than when that DRM is outside outside the browser altogether. I.e. while content companies are crazy bent on DRM, let them use their custom applications all they want. What's the problem with that? In time they might gain sanity and drop this useless junk. But their mind sickness is not a reason to pollute the standard with it as well.

jmillikin 13y ago
HTML+DRM is closer to an open web than a locally installed proprietary application + DRM.
- shmerl 13y ago
  Those who are interested in open Web aren't going to use any DRM, and they could just avoid those external applications. Now they have to worry about disabling EME in the browser, and if that's even possible, since it's a "standard". I clearly see EME to be a setback to the open Web. If content companies aren't interested in open Web, let them stay outside it, until they reconsider.
- pppppowerbook 13y ago
  > HTML+DRM is closer to an open web than a locally installed proprietary application + DRM. HTML+DRM is closer to a fully locked-down proprietary-only DRM -web than a 3rd-party locally installed proprietary application + DRM.
- azakai 13y ago
  > HTML+DRM is closer to an open web than a locally installed proprietary application + DRM. No, HTML+DRM still requires, in addition to the EME API implementation, the actual DRM module. The DRM module will be a locally installed proprietary application - not something standardized, not open, not cross-platform not cross-browser. There are currently 2 such DRM modules, one by Microsoft for IE and one by Google for Chrome. They are proprietary binary blobs, non-standard except for the small external API interface to EME, and are the result of private collaboration with content creation companies.

chimeracoder 13y ago

> The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. No, that's not the expectation of EME opponents. EME opponents understand that companies will continue to use restricted access, as they always have, but want them to do it off-spec and on their own dime. > If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback. That would be far less of a setback for the open web than the current state, which bakes the notion of restricted access into the open standards.

jmillikin 13y ago
"off-spec and on their own dime" could also be written "for only the top 2-3 most popular operating systems". If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine, then that's a significant reason for users to buy the completely proprietary systems. > That would be far less of a setback for the open web > than the current state, which bakes the notion of > restricted access into the open standards. If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized.
- chimeracoder 13y ago
  > If Ubuntu, FirefoxOS, and CyanogenMod are locked out of watching Netflix but iOS and Windows work fine The status quo is that Linux users are already locked out of Netflix. The only reason that Cyanogenmod users aren't is because they can run the standard Android apk, which, incidentally, is a separate proprietary blob that Netflix had to write and produce on their own dime. I'd rather vendors be forced to ship proprietary binaries that they have to produce themselves than for them to offload the work onto open-source browsers (or, worse, be able to pressure open-source browsers to cripple their own functionality in order to preserve DRM). > If widespread restrictions are going to exist anyway, then it's strictly better for the interface to be standardized. If widespread restrictions are going to exist, it's better for them to be less convenient for everyone involved (both consumers and distributors), not more.

azakai 13y ago

> If EME is blocked, then these companies will either start distributing their own customized locked-down applications ("You must install the Netflix Player to watch this movie"), or will work privately with the major proprietary browser platforms (IE, Safari, Android Chrome, ChromeOS) to implement what they demand. Firefox and Chrom{e,ium} will be left out in the cold, and the advancement of the open web will se a significant setback. First thing, Chrome is a proprietary browser platform. Only Chromium should be in the last sentence. I believe Chrome already ships with EME; I am not sure if that includes Google's DRM plugin for it as well, but if not then that is soon to come as well. Chrome already ships with various other proprietary code (Flash, SwiftShader, a PDF reader, etc.) so this would not be a new thing. Google and Microsoft have been developing proprietary DRM plugins, with Netflix and Hollywood, for their browsers. EME is just a generic API to those plugins. So your comparison of what will happen with vs. without EME appears flawed: in both cases, only proprietary browsers that include DRM plugins, which are the result of private collaboration with Netflix and Hollywood, will be able to access content. And yes, that would leave out open source browsers like Firefox and Chromium - with or without EME. I also disagree with the premise underlying > The basic position of EME opponents appears to be that if we refuse to allow DRM modules in browsers, then the companies pushing DRM will give up and let us watch unrestricted video. This position, in my opinion, is fantastically optimistic. I agree to the conclusion - that it is highly optimistic to see Hollywood quickly move to unrestricted video. But you are assuming there is no other option. There are in fact several: 1. Watermarking as an alternative to DRM, that achieves similar results. 2. Non-proprietary DRM solutions, either standardized (which EME does nothing for, intentionally) or done in web content (HTML5). Those would not be as secure as proprietary binary blobs (what EME assumes), but could still prevent 99% of casual piracy - and professional piracy isn't stopped even by the blobs. 3. Eventual movement to unrestricted video, perhaps after a period of using 1 and/or 2. We saw this in music, it took a while, but sanity prevailed.

jmillikin 13y ago
> First thing, Chrome is a proprietary browser platform. > Only Chromium should be in the last sentence. I believe > Chrome already ships with EME; I am not sure if that > includes Google's DRM plugin for it as well, but if not > then that is soon to come as well. Chrome already ships > with various other proprietary code (Flash, SwiftShader, > a PDF reader, etc.) so this would not be a new thing. I want to distinguish between a browser platform, where the browser is considered an integral part of the underlying OS, and standalone web browsers. Chrome and Firefox are regular applications, they do not (yet?) feature the deep OS integration that would be necessary to implement functional digital restrictions. Google's DRM plugin is currently available for both Firefox and Chrome through the standard Netscape plugin API, but is not bundled with either browser. > in both cases, only proprietary browsers that include > DRM plugins, which are the result of private > collaboration with Netflix and Hollywood, will be able > to access content. And yes, that would leave out open > source browsers like Firefox and Chromium - with or > without EME. If I'm reading the EME spec correctly, then EME plugins can be installable by the end user in the same way that Netscape plugins are today. Assuming the browser chooses to implement the plugin system, both Firefox and Chromium ought to be able to use DRM plugins from the system. > 2. Non-proprietary DRM solutions, either standardized > (which EME does nothing for, intentionally) or done in > web content (HTML5). Those would not be as secure as > proprietary binary blobs (what EME assumes), but could > still prevent 99% of casual piracy - and professional > piracy isn't stopped even by the blobs. Any non-proprietary DRM solution would not be able to stop even casual piracy. The casual pirate will search for [download netflix movie], click the first link, install a browser extension, and get a one-step piracy button right in their browser. That's what content companies are terrified of, and any DRM system that can't stop this sort of pirate will not be accepted. > 3. Eventual movement to unrestricted video, perhaps > after a period of using 1 and/or 2. We saw this in > music, it took a while, but sanity prevailed. We have not seen a victory for free formats in music. The majority of music online is still distributed wrapped in layers of digital restrictions (e.g. Pandora, Spotify) or in patent-encumbered formats (e.g. iTunes, Google Play, Amazon).