Different, how? It's different in several ways. For one it's not a plugin framework, it's a DRM plugin framework; meaning it's designed specifically with 1 use case in mind. Secondly its expressed intent is to take away functionality; I'm not aware of any other instance where a web API is created to disable features of a user's computer. I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here.
>> 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? The ability to download audio/video? Again, playing the devil's advocate, I would imagine a vast majority of the content that would be streamed using the DRM encodes would not be streamed using the video element currently - it would be streamed over flash/silverlight, etc (think netflix, hulu). If that is the case, what is it we are losing?
>> I'm not aware of any other instance where a web API is created to disable features of a user's computer
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.
>>I'm sure we can rattle off more ways that it is different, but I'm not sure what you're looking for here.
I am looking for logical reasons to say why adding EME hurts the open web so when I get into arguments I have better reasons other than 'I hate 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.
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.
"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. They are going to get a gun.
3. They bought the house with a new gun rack, and don't object enough to guns to remove it immediately.
Now, as was stated earlier, DRM (like a lot of guns) was invented with only one purpose. If I see the governing body of an open web standard starting to stick in frameworks for DRM, I think 3 very similar thoughts to those above.
In short, not being able to find an argument against something, doesn't mean it won't leave you wondering what the actual use case of this will be, and start thinking if it really needs an argument against it. I personally think it needs a whole bunch of better arguments for the proposal than those that have been raised til now.
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.
> 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 is a red herring; EME only exists to facilitate DRM. EME was designed specifically with DRM in mind. There is no other use case. 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.
>>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
