6 ms·

If you're referring to Encrypted Media Extensions it's not a DRM mechanism that requires proprietary software. It's a specification for a communication channel

by pippy 12y ago

If you're referring to Encrypted Media Extensions it's not a DRM mechanism that requires proprietary software. It's a specification for a communication channel between a browser and Digital Rights Management agent software on the local machine. While it's not ideal, it's just some javascript functions that interact with the DRM on the computer. The DRM software itself is completely optional. It's much better than having plugins that do the same thing (if you use firefox you're used to Flash asking for trial Norton to be installed every time a security exploit is found in Flash). In the perfect world we wouldn't need it, but it leaves no excuse for media companies not to use HTML5.

derekp7 12y ago
Is the DRM module itself an open specification? Or will it be a separate proprietary program that content sites will still require you to install? I can see for example Real or Flash making such modules, and still bundling with random tool bars and popups. Or will it most likely be a specification that allows multiple (but NDA'd) implementations, such as the DRM component of dvd and bluray players? If that is the case, then it is still better than what we had before, as multiple vendors will need to compete (increasing the likelihood of a non-crappy implementation).
- lbenes 12y ago
  > Is the DRM module itself an open specification? Or will it be a separate proprietary program It's a closed source proprietary blob. You can read about it here. https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/ https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challen...
- hsivonen 12y ago
  There is no single "the DRM module". Microsoft has its own in IE. Google has its own in Chrome. Apple has its own in Safari. Adobe has its own (that Firefox will be able to use). None of these have open specs.
Buge 12y ago
A company could make it necessary to install their DRM to view their videos and bundle Norton with it. This would actually be worse than the current situation because the user would have to install a different DRM thing for each different site. Although I can see sites being reluctant to do that because it would be inconvenient for the users to have to install something specifically to watch the web videos on that site. One thing I can see happening would be one major DRM software that emerges and all websites that want DRM work together to use that.
abdias 12y ago
True, it was approved by W3C and Tim Berners-Lee a while back (http://www.infoworld.com/article/2612478/html5/berners-lee-and-w3c-approve-html5-video-drm-additions.html http://www.infoworld.com/article/2612478/html5/berners-lee-a...), and was criticized - understandably so. For instance: If someone do research for educational or critical purposes, they have the right to use copyrighted material under "Fair Use" (US, UK and other countries have similar rules). With DRM this would essentially block this right (if used on the material in question), which of course is not a good thing. But it's great to see that HTML5 is now the preferred choice on YT.
- ucaetano 12y ago
  "Right to use" != "right to have it provided to you in an easy-to-copy way".
  - deathanatos 12y ago
    > "Right to use" != "right to have it provided to you in an easy-to-copy way". One of the big problems with DRM is that this ends up being not "right to use" but "right to use in several very narrow ways that someone else deems fit". If your use is innovative or just different — such as using a more capable media player with more features than the one provided to play the media with —, you end up being not able to do it.
    - ucaetano 12y ago
      So if I write a poem in a rock in the middle of the desert I'm offending your right to have access to it? You can always film the screen and use that as fair use. I'm against DRM, but "You're offending my rights to copy with minimum effort" is not an argument against it. Nobody has to provide anything in an easy-to-copy way, which doesn't mean that you don't have the right to copy it.
schoen 12y ago
I agree that HTML5 is much better than Flash in every way, so in this sense I'd just like to encourage our community to continue applying pressure at all levels and in all channels to ensure that Encrypted Media Extensions doesn't continue to be a part of HTML5 standards, UAs, or websites.
- yohui 12y ago
  > I'd just like to encourage our community to continue applying pressure at all levels and in all channels to ensure that Encrypted Media Extensions doesn't continue to be a part of HTML5 standards Which just means content owners will continue to use proprietary plugins or push unstandardized extensions. Pressure should be applied to the root of the issue (copyright holders' desire for DRM), not the symptom.
  - patzerhacker 12y ago
    Pressure should be applied in both places.
  - JoshTriplett 12y ago
    > Which just means content owners will continue to use proprietary plugins or push unstandardized extensions. Which will provide a worse experience, making it easier for competing content owners to provide a better experience.
bzbarsky 12y ago
Sorry, but there's an important distinction between what you said and what EME is. EME is a spec for a communication channel between script in a web page and a browser, with the idea that the browser then talks to a DRM module. It's not a spec for a communication channel between the browser and a DRM module. This is important, because it means that you end up with DRM modules that are tied to a particular browser. The NPAPI plugin situation is unfortunate in all sorts of ways, but the one good thing it had going for it was that there _was_ an API that multiple browsers all implemented, such that a single plugin binary woudl work in all of them (modulo the usual bugs and incompatibilities you have when there are multiple implementors of an API). Unfortunately, 3 of the 4 main browser vendors also happen to be DRM vendors, and were rather united in their opposition to the W3C creating a specification for the communication channel between the browser and the DRM module.
- walterbell 12y ago
  Is there any current or proposed implementation that can support W3C SMIL in the browser? A decade ago, RealPlayer was able to seamlessly edit video excerpts (defined by start::stop intervals) into a single video stream. The excerpts could have originated from different servers. Will the new DRM formats support this use case? E.g. if I'm a paying Netflix subscriber, could I view a dynamically defined (XML or JSON) mashup of Buffy and Twilight, using only a list of start/stop edit points? The HTML5 viewer would need to pre-buffer each video clip, to make the viewed stream seamless.
  - bzbarsky 12y ago
    You could build something like that in Javascript on top of HTML <video> and MSE, probably. The EME (DRM) spec is not really related to this.
    - walterbell 12y ago
      Wouldn't the DRM spec have to explicitly permit MSE buffering? If Javascript could buffer the stream and send it to any destination other than a DRM-approved output device, that would defeat the DRM.
cabalamat 12y ago
> The DRM software itself is completely optional. Unless you want the web page to work. One could just as well describe having a web browser as "completely optional".

by pippy 12y ago

derekp7 12y ago

Is the DRM module itself an open specification? Or will it be a separate proprietary program that content sites will still require you to install? I can see for example Real or Flash making such modules, and still bundling with random tool bars and popups. Or will it most likely be a specification that allows multiple (but NDA'd) implementations, such as the DRM component of dvd and bluray players? If that is the case, then it is still better than what we had before, as multiple vendors will need to compete (increasing the likelihood of a non-crappy implementation).

lbenes 12y ago
> Is the DRM module itself an open specification? Or will it be a separate proprietary program It's a closed source proprietary blob. You can read about it here. https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/ https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challen...
hsivonen 12y ago
There is no single "the DRM module". Microsoft has its own in IE. Google has its own in Chrome. Apple has its own in Safari. Adobe has its own (that Firefox will be able to use). None of these have open specs.

Buge 12y ago

A company could make it necessary to install their DRM to view their videos and bundle Norton with it. This would actually be worse than the current situation because the user would have to install a different DRM thing for each different site. Although I can see sites being reluctant to do that because it would be inconvenient for the users to have to install something specifically to watch the web videos on that site. One thing I can see happening would be one major DRM software that emerges and all websites that want DRM work together to use that.

abdias 12y ago

True, it was approved by W3C and Tim Berners-Lee a while back (http://www.infoworld.com/article/2612478/html5/berners-lee-and-w3c-approve-html5-video-drm-additions.html http://www.infoworld.com/article/2612478/html5/berners-lee-a...), and was criticized - understandably so. For instance: If someone do research for educational or critical purposes, they have the right to use copyrighted material under "Fair Use" (US, UK and other countries have similar rules). With DRM this would essentially block this right (if used on the material in question), which of course is not a good thing. But it's great to see that HTML5 is now the preferred choice on YT.

ucaetano 12y ago
"Right to use" != "right to have it provided to you in an easy-to-copy way".
- deathanatos 12y ago
  > "Right to use" != "right to have it provided to you in an easy-to-copy way". One of the big problems with DRM is that this ends up being not "right to use" but "right to use in several very narrow ways that someone else deems fit". If your use is innovative or just different — such as using a more capable media player with more features than the one provided to play the media with —, you end up being not able to do it.
  - ucaetano 12y ago
    So if I write a poem in a rock in the middle of the desert I'm offending your right to have access to it? You can always film the screen and use that as fair use. I'm against DRM, but "You're offending my rights to copy with minimum effort" is not an argument against it. Nobody has to provide anything in an easy-to-copy way, which doesn't mean that you don't have the right to copy it.

schoen 12y ago

I agree that HTML5 is much better than Flash in every way, so in this sense I'd just like to encourage our community to continue applying pressure at all levels and in all channels to ensure that Encrypted Media Extensions doesn't continue to be a part of HTML5 standards, UAs, or websites.

yohui 12y ago
> I'd just like to encourage our community to continue applying pressure at all levels and in all channels to ensure that Encrypted Media Extensions doesn't continue to be a part of HTML5 standards Which just means content owners will continue to use proprietary plugins or push unstandardized extensions. Pressure should be applied to the root of the issue (copyright holders' desire for DRM), not the symptom.
- patzerhacker 12y ago
  Pressure should be applied in both places.
- JoshTriplett 12y ago
  > Which just means content owners will continue to use proprietary plugins or push unstandardized extensions. Which will provide a worse experience, making it easier for competing content owners to provide a better experience.

bzbarsky 12y ago

Sorry, but there's an important distinction between what you said and what EME is. EME is a spec for a communication channel between script in a web page and a browser, with the idea that the browser then talks to a DRM module. It's not a spec for a communication channel between the browser and a DRM module. This is important, because it means that you end up with DRM modules that are tied to a particular browser. The NPAPI plugin situation is unfortunate in all sorts of ways, but the one good thing it had going for it was that there _was_ an API that multiple browsers all implemented, such that a single plugin binary woudl work in all of them (modulo the usual bugs and incompatibilities you have when there are multiple implementors of an API). Unfortunately, 3 of the 4 main browser vendors also happen to be DRM vendors, and were rather united in their opposition to the W3C creating a specification for the communication channel between the browser and the DRM module.

walterbell 12y ago
Is there any current or proposed implementation that can support W3C SMIL in the browser? A decade ago, RealPlayer was able to seamlessly edit video excerpts (defined by start::stop intervals) into a single video stream. The excerpts could have originated from different servers. Will the new DRM formats support this use case? E.g. if I'm a paying Netflix subscriber, could I view a dynamically defined (XML or JSON) mashup of Buffy and Twilight, using only a list of start/stop edit points? The HTML5 viewer would need to pre-buffer each video clip, to make the viewed stream seamless.
- bzbarsky 12y ago
  You could build something like that in Javascript on top of HTML <video> and MSE, probably. The EME (DRM) spec is not really related to this.
  - walterbell 12y ago
    Wouldn't the DRM spec have to explicitly permit MSE buffering? If Javascript could buffer the stream and send it to any destination other than a DRM-approved output device, that would defeat the DRM.

cabalamat 12y ago

> The DRM software itself is completely optional. Unless you want the web page to work. One could just as well describe having a web browser as "completely optional".