13 ms·

W3C takes advantage of the ambiguity of what the EME spec and "standard" DRM is. People unfamiliar with the spec may think it's the end of plug-ins and a spec f

by pornel 9y ago

W3C takes advantage of the ambiguity of what the EME spec and "standard" DRM is. People unfamiliar with the spec may think it's the end of plug-ins and a spec for a DRM that is somehow open, implementable and cross-browser. It's nothing like it. It's a small JS API that launches the same old, fully closed, proprietary DRM solutions. The NPAPI has been replaced with DMCA-protected interface, and previously separate DRM plug-ins are now called "modules" and shipped with the browser. It's as if Chrome, which ships with Flash bundled-in, created a "HTML Multimedia Extensions" spec with just `navigator.launch("com.adobe.flash")` for launching "Multimedia Modules" (details of which are out of scope of the spec), and hailed it as the end of the non-standard Flash and plug-ins.

izacus 9y ago
Note that part of standard DRM schemes is also "Computer verification" - e.g. that they refuse to work if your PC doesn't have the correct kernel, drivers or software installed. If you need special drivers to fix compatibility, want to customize your Android or do anything but leave your system full untouched and bloated, might be that you'll be prevented from watching online videos.
- jopsen 9y ago
  To some extend perhaps... One of the key arguments when Mozilla decided to implement EME was that the crappy-proprietary-code could be sandboxed by firefox to ensure that it doesn't infect a system with malware, spy on users, etc. From a security perspective it's light years better than flash and other crappy plugins.
  - syshum 9y ago
    And when they did that, the Content providers responded by saying "Ok then we will only allow you access to low quality content" i.e you can only stream upto 1280x720 resolution on firefox, no 1080 content, and no 4K content.. Today that has low impact, in a few years that situation will be untenable for FF and they will be "forced" to cave once again in order to appease users that do not care about privacy or security
    - jopsen 9y ago
      But we life to fight another day. Don't forget that vendors like Netflix aren't proponents of DRM, it complicates their streaming architecture and costs a lot of money. In a future where Netflix and other streaming services makes up a large part of the profit for content owners, we might see DRM disappearing. Look at how Apple was able to sell DRM free music because their volume was high.
  - chris_wot 9y ago
    I wrote a bug asking Mozilla not to implement HTML5 DRM. It was closed as RESOLVED WONTFIX. https://bugzilla.mozilla.org/show_bug.cgi?id=923590 https://bugzilla.mozilla.org/show_bug.cgi?id=923590
metajack 9y ago
Before DRM plugins could access anything. Now they live in a sandbox which was not possible when they were NPAPI plugins. So the security story is actually much better as far as I know. It still sucks to infect the web with this nonsense, but at least it can't do as much evil crap.
- kevin_b_er 9y ago
  Now the DRM plugin can only access the DRM subsystem installed on your machine that has root enough access to verify your files, OS version, and graphics drivers, as well as a callchain allowing them to make draw calls to your GPU driver.
om2 9y ago
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.) This has some important advantages: * Web content authors can build video players using the same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video. No need to learn a whole different plugin environment for this case. * Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface. * The browser's built-in playback is generally much more power-efficient, meaning more video viewing time on battery for your Netflix/Amazon/Hulu/etc video content. * Even if the DRM scheme is some form of plugin, it needs far fewer capabilities than a plugin that has full video playback, live streaming, a scripting environment, etc. So it's less of a security risk * Flash and Silverlight especially were common sources of critical security vulnerabilities and they'll be out of the picture. * With approaches like MPEG Common Encryption[1], a single encrypted media resource can be used with multiple DRM schemes. This helps content hosts save on storage, and it makes it materially easier for new browsers to enter the market, since they don't have to ask content providers to host a whole separate copy of the video. The continuing existence of DRM is admittedly not ideal. But supporting it in the browser instead of solely in the separate world of plugins has major user and developer benefits, as described above. [1] https://en.wikipedia.org/wiki/MPEG_Common_Encryption https://en.wikipedia.org/wiki/MPEG_Common_Encryption
- chii 9y ago
  > same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version). If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.

by pornel 9y ago

izacus 9y ago

Note that part of standard DRM schemes is also "Computer verification" - e.g. that they refuse to work if your PC doesn't have the correct kernel, drivers or software installed. If you need special drivers to fix compatibility, want to customize your Android or do anything but leave your system full untouched and bloated, might be that you'll be prevented from watching online videos.

jopsen 9y ago
To some extend perhaps... One of the key arguments when Mozilla decided to implement EME was that the crappy-proprietary-code could be sandboxed by firefox to ensure that it doesn't infect a system with malware, spy on users, etc. From a security perspective it's light years better than flash and other crappy plugins.
- syshum 9y ago
  And when they did that, the Content providers responded by saying "Ok then we will only allow you access to low quality content" i.e you can only stream upto 1280x720 resolution on firefox, no 1080 content, and no 4K content.. Today that has low impact, in a few years that situation will be untenable for FF and they will be "forced" to cave once again in order to appease users that do not care about privacy or security
  - jopsen 9y ago
    But we life to fight another day. Don't forget that vendors like Netflix aren't proponents of DRM, it complicates their streaming architecture and costs a lot of money. In a future where Netflix and other streaming services makes up a large part of the profit for content owners, we might see DRM disappearing. Look at how Apple was able to sell DRM free music because their volume was high.
- chris_wot 9y ago
  I wrote a bug asking Mozilla not to implement HTML5 DRM. It was closed as RESOLVED WONTFIX. https://bugzilla.mozilla.org/show_bug.cgi?id=923590 https://bugzilla.mozilla.org/show_bug.cgi?id=923590

metajack 9y ago

Before DRM plugins could access anything. Now they live in a sandbox which was not possible when they were NPAPI plugins. So the security story is actually much better as far as I know. It still sucks to infect the web with this nonsense, but at least it can't do as much evil crap.

kevin_b_er 9y ago
Now the DRM plugin can only access the DRM subsystem installed on your machine that has root enough access to verify your files, OS version, and graphics drivers, as well as a callchain allowing them to make draw calls to your GPU driver.

om2 9y ago

I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.) This has some important advantages: * Web content authors can build video players using the same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video. No need to learn a whole different plugin environment for this case. * Video playback only has one code path, instead of totally separate browser and plugin video pipelines. Video codecs are complex, so this means less security attack surface. * The browser's built-in playback is generally much more power-efficient, meaning more video viewing time on battery for your Netflix/Amazon/Hulu/etc video content. * Even if the DRM scheme is some form of plugin, it needs far fewer capabilities than a plugin that has full video playback, live streaming, a scripting environment, etc. So it's less of a security risk * Flash and Silverlight especially were common sources of critical security vulnerabilities and they'll be out of the picture. * With approaches like MPEG Common Encryption[1], a single encrypted media resource can be used with multiple DRM schemes. This helps content hosts save on storage, and it makes it materially easier for new browsers to enter the market, since they don't have to ask content providers to host a whole separate copy of the video. The continuing existence of DRM is admittedly not ideal. But supporting it in the browser instead of solely in the separate world of plugins has major user and developer benefits, as described above. [1] https://en.wikipedia.org/wiki/MPEG_Common_Encryption https://en.wikipedia.org/wiki/MPEG_Common_Encryption

chii 9y ago
> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version). If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.