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?
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
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 Linux has nothing, etc. This scenario is much worse than Flash.
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.
Well, one difference is that currently existing plug-in frameworks have well-defined APIs that are used to talk to the plug-in. This is why the same plug-in binary blob can be used in Firefox and Safari and Opera and Chrome, for example: they all implement NPAPI.
One issue with the current EME spec is that it doesn't actually define an API for the browser to interact with the CDM. It defines an API for in-page JS to ask the browser to interact with the CDM, which is the web-facing bit, but how browsers and CDMs interact is entirely undefined.
What that means in practice is that it would be perfectly spec-compliant for Google to ship a CDM that only works with Chrome, for Microsoft to ship one that only works with IE, and for Apple to ship one that only works with Safari. Should you then have the misfortune of not using one of those browsers, you wouldn't be able to view the video in question.
Oddly enough, Google, Apple, and Microsoft are all in favor of this part of the spec last I checked.
>>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?
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.
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.
To play to devils advocate - because that other unethical junk requires additional downloads and poses multiple security vulnerabilities. Right? Why wouldn't a sort of 'native plugin' be better in every sense of the word for the end user?
DRM by definition implies security and privacy risk. Focusing on minor issue (native plugin) while ignoring the major one (DRM) sounds strange. And in reality this whole EME thing won't even remove native DRM code. It just will hook it into JavaScript. The risk caused by DRM won't get any less than it is already.
>>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 just will hook it into JavaScript.
I'm not sure what you mean by 'in reality'. Thats it's entire purpose.
>>The risk caused by DRM won't get any less than it is already.
I know? Who is arguing the opposite?
>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.
Why do you think Google or Mozilla would be the ones to implement the black box in the DRM? Firefox is developed by a community. The process is public and anyone can identify or patch vulnerabilities -- that's why the security is good. You expect Mozilla to devise and implement some DRM scheme? The actual DRM would end up being created by someone like Adobe again and have all the same security vulnerabilities, because the wider developer community couldn't be allowed to be privy to how it does what it does or it wouldn't be DRM anymore.
One of the problems with DRM is that pretty much anyone who understands security will laugh at you for thinking you can implement effective DRM, so it ends up being built by snake oil salesmen who don't know what they're doing. I don't see how putting it into HTML would change any of that -- all it would do is pollute HTML and encourage the proliferation of more bad code.
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 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?
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.
Simple logic. DRM requires secret (from the user) code to run on user's machine. DRM doesn't trust the user (user is treated as potential criminal) for the sake of content owner interests. Such kind of predisposition makes it very reasonable for the user not to trust the content owner in return and to treat DRM by default as a privacy breaching malware and security risk (until proven otherwise - which isn't possible, since it's a black box). Trust is always mutual. How else can you view this?
because a drm plugin is a plugin,like flash or java applet. You'll have to download plugin DRM A,B or C to make it work.The only difference is that it will use the video tag.
