Live data from Hacker News

The W3C's plan for DRM in HTML5 is a betrayal for all web users

freeculture.org

151–158 of 158 posts

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#151
post #123

Earlier quoted context omitted.

>> For one it's not a plugin framework, it's a DRM plugin framework; A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it. >> Secondly its expressed intent is to take away functionality Take away what functionality?…

A DRM API in HTML5 harms users by legitimizing and enabling restrictive technology under the banner of the free and open web, with all the practical harm (lack of control, reduced bargaining power, security issues) that loss of freedom entails. If the framework is no different from existing frameworks, why do we need it?

>>A DRM API in HTML5 harms users by legitimizing and enabling restrictive technology under the banner of the free and open web, with all the practical harm (lack of control, reduced bargaining power, security issues) that loss of freedom entails.

In whose eyes does it legitimize it? Are you saying someone will be convinced that DRM is ok because it is in a web browser?

>>If the framework is no different from existing frameworks, why do we need it?

Because it is different. Native solutions are more likely to be faster and more secure than external plugins.

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#152

Earlier quoted context omitted.

>> For one it's not a plugin framework, it's a DRM plugin framework; A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it. >> Secondly its expressed intent is to take away functionality Take away what functionality?…

> Take away what functionality? The ability to download audio/video? The ability to download audio/video already exists in computers. DRM prevents you from doing what you want with the bits that are sent to you; hence it restricts native computer functionality. > To be fair, this isn't. EME is just a way for people to create addons that leverage native encryption. The same is true of the current plugin system. This i…

>>The ability to download audio/video already exists in computers.

Thank you for clarifying. I wasn't sure what you meant.

>> It's a convenient way for EME supporters to ignore the real issues, but it's valid to talk about a technology's real world uses when discussing its validity.

To be clear, I am not a supporter. I don't want it in the browser either. However, I don't understand how it is a red herring. Everything that is being proposed in EME is already possible in Flash and Silverlight, and those features only exist in those plugins for the same reason. Neither of them need file encryption in order to work as a platform - it is a feature so that people that want to have encrypted/licensed material on the internet can do so. You can write applications without them. But yet no one seems to care about it. I am wondering why that is

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#153

Earlier quoted context omitted.

>> For one it's not a plugin framework, it's a DRM plugin framework; A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it, and I don't see how this is a good one. If you could further your point, I would love to hear it. >> Secondly its expressed intent is to take away functionality Take away what functionality?…

"A DRM plugin framework is by definition a plugin framework. I relly don't want DRM in html either, but I have a hard time finding logical arguments against it" I'm Australian so this probably won't translate, but if I go into someone's house, and they have a brand new gun rack on the wall, with no gun in it, a few thoughts go through my head: 1. They have a gun but have secreted it somewhere while I'm around. 2. The…

The gun rack that is EME is absolutely falling under category 2. There is no native encryption, but there will be soon. The W3C doesn't want to create an encryption scheme, but it wants to allow other people to supply it.

In my mind, having a way to stream hulu/netflix (sorry, I'm not sure if there is an aussie version of either service...) that doesn't require a plugin that gives the computer access to my harddrive is a pretty good thing. Not as good as plain old mp4/ogvs, but better than a plugin player.

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#154
post #10

Earlier quoted context omitted.

Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?

It isn't, that's why plugins are being killed off too.

>>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#155
post #92

Earlier quoted context omitted.

>>Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange. I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulnerabilities, and I trust Google/Mozilla with web encryption WAY more than I do Adobe. Can you explain why you consider it to be such a minor issue? >>And in reality this whole EME thing won't even remove native DRM code. It jus…

It's a minor issue comparing to the issue of DRM. You say - let's worry about plugins, while users will agree to use DRM anyway. I say - if user agrees to use DRM, user can as well use native plugins - such user doesn't care about security or privacy already and there is no point to drag that issue into HTML at all. I don't think it is a minor issue at all. My biggest complaint with flash has been the security vulner…

Their code won't have all of the power of flash and silverlight (ie my full user account on the computer). The worst case scenario is their algo's suck and I can decrypt their videos easier.

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#156
post #13

Earlier quoted context omitted.

Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?

In theory perhaps it's no different. But I think EME would work out very poorly in practice. Some browsers either allow no plugins or only a few grandfathered plugins. What EME systems will they support? Imagine a future where Mobile Safari only supports FairPlay, IE only supports WMDRM, Chrome OS only supports Widevine, Android gets fragmented into a half-dozen different DRM schemes depending on vendor, desktop Linu…

Once someone supports EME, they would support anything written for EME. I don't believe there will be a way to 'grandfather' any old systems. That would require either a complete rewrite of the plugin in the browser, or a rewrite in an EME compatible code, in which case it will run anywhere EME exists.

secondly, isn't the situation you describe exactly the situation we have now with flash/silverlight? I can't play WMAs on my Mac, Flash on my Droid, or any other number of combinations.

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#157
post #10

Earlier quoted context omitted.

It isn't, that's why plugins are being killed off too.

>>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?

I don't think I phrased that quite right.

Modern web standards are attempting to render plugins like java, flash, and silverlight obsolete, because they're fragile, not universally available, single-sourced, proprietary, insecure and generally inconsistent with how the rest of the web works. There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed.

You're right that EME is meaningless one way or another so long as plugins exist--That's why EME exists at all, it's essentially a new plugin architecture that solves none of the problems of the previous ones. It's a bad idea for the same reason plugins are.

Re: The W3C's plan for DRM in HTML5 is a betrayal for all web users

#158

Earlier quoted context omitted.

>>It isn't, that's why plugins are being killed off too. Could you explain? Also, what is the 'too' referring to? What is the original thing being killed off?

I don't think I phrased that quite right. Modern web standards are attempting to render plugins like java, flash, and silverlight obsolete, because they're fragile, not universally available, single-sourced, proprietary, insecure and generally inconsistent with how the rest of the web works. There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist,…

I still don't really understand what you are trying to say

>> There is an effort from various direction to kill off content viewer plugins like them, and the APIs that allow them to exist, and it appears it's going to succeed.

While I agree that there are people trying to kill off the need for plugins, I don't think anyone is killing off the APIs that allow for plugins - can you provide any example of this happening? (Outside of phones)

>>You're right that EME is meaningless one way or another so long as plugins exist

I never said that. Nor do I think that. My point is that EME is doing the same thing as other - long ago implemented - plugins, but with a lot less of a surface area of attack and more likely to be made up of better code.

>> it's essentially a new plugin architecture

agreed.

>>that solves none of the problems of the previous ones.

I don't believe that most people would list DRM-ablility as an issue with previous plugins. Could you elaborate what issues you are referring to?

>>It's a bad idea for the same reason plugins are.

I think that those plugins are bad because it gives flash/silverlight/java/anythingElse access to a lot of native APIs that most users are completely oblivious to. If anything, it removes most of the security issues shown in those plugin systems.

Post reply on HN