Is EFF aligned with community-based stakeholders? And which ones?
Except they are not including DRM in HTML…so none of these points make sense. They are including an API for discovery and interaction with third party systems.
The proposal was updated in May.
Well duh. Why would they discuss something that doesn’t apply to what they are doing?
These APIs can be used to implement discovery of DRM systems automatically, and facilitate interaction with the discovered system, they can not be used to implement DRM, nor do they include DRM. Claims to the contrary are FALSE. Jumping from those false claims to larger implications is just plain wrong.
I fear there is a huge misunderstand and disconnect from the above fear mongering claims and the reality of what is being done.
Traditionally, Netflix, Amazon and friends used code based on Flash or Silverlight to protect their content on web pages, and HTML contained the basic plumbing necessary to call out to Flash or Silverlight. This effort seems to be about making changes to HTML such that in this scenario Flash or Silverlight is no longer required, and Netflix and friends get to call the code directly from HTML that they used to call from Flash or Silverlight (or something like that code, anyway). That code is unlikely to go away anytime soon, but anything that makes Flash or Silverlight go away, insecure monstrosities that they are, is a net win in my book.
I fear there is a huge misunderstand and disconnect from the above fear mongering claims and the reality of what is being done.
I’d love to see Doctorow respond to this. I came here wondering why they don’t modify the charter, but now I’m thinking you’re right - it’s classic FUD.
I thought the claim was that there was an increased risk of punitive actions against the smaller security researchers under Section 1201 of the DMCA. Is that not right?
You may as well wish that Don Quixote would stop tilting at windmills to explain why it is that he thinks they are bad. On this topic, Doctorow has become a crank.
The claim that has been repeatedly made, is that they are including DRM in the html standard, which would be included in new browsers, preventing security researchers from doing any security research on browser implementations. And that this would also somehow prevent any new companies from making browsers or media players, etc. It has also been stated that it would have killed netflix and itunes before they even started, in reality it would have dramatically helped them.
That argument is a huge stretch even if was true that drm was being included in the html standard. If it were true, it would only apply to the circumvention of the DRM protection portion, BUT the linchpin of the argument isn’t even true at all, DRM isn’t being included in html, only a standardized api to discover and interact with third party DRM and Encrypted Content. So NO DRM is being included in the html standard, period. The EME is DRM free, it just facilitates the lookup and control and interaction of external DRM systems so that they are standardized and anything implementing the html standard can interact with these same services via the same api, opening the field for small players and new browsers. It is a good thing, and intentionally avoids even going into the area where the potential pitfalls may lie.
The standards aren’t even a distributed common code base, rather they are a documentation of a standard that is up to the specific vendors to implement. The FUD and misunderstanding runs deep in these capricious articles.
If there’s really no risk to the small fry then why not have the big players indemnify them? Easy peasy.
I personally agree they shouldn’t go after any researcher that is participating in responsible disclosure practices on principal.
#BUT…
To ask that to happen in something completely out of context of what is being implemented is just crazy.
Getting all the big players to agree on a common api to access their unique proprietary solutions is a challenge enough without trying to force a condition of them agreeing not to sue security researchers trying to break their solutions.
No researcher is put at ANY additional risk from the EME standardization, and such a discussion is inappropriate to that implementation, as the W3C said it is completely beyond the scope of what they are doing. They aren’t even involved in the DRM implementations. Adding such a condition would simply result in the standard not being implemented by DRM solutions and would solve nothing at all except kill the standard, which is the EFF’s goal.
of course it isn’t appropriate in the scope of what they are doing. the only reason that the EFF is proposing it is to try and kill the EME, when the EME is actually really a positive thing for standards, small players, and end users. Again the EME contains ZERO DRM, it is simply a discovery and interaction API for third party DRM and Encrypted Content systems to standardize the discovery and interaction with them, so that any solution can use them in a standardized way, preventing the need for custom implementations for each browser which locks the little guys out. Adding the charter would achieve nothing except killing the standard, it would protect zero security researchers because the standard would be dead in the water, and the losers would be the small developers, the end users, and a standardized inter-operable web. It is a very shady dishonest proposition.
If there’s really minimal risk then there should be no issue about the larger players indemnifying the smaller folks. It sounds like @doctorow and EFF are right that there’s risk.
No offense, but you really aren’t understanding are you?
no additional risk because this isn’t the DRM code at all, simply a discovery and interaction API standard ≠indemnification of breaking separate third party propitiatory code, which is what they are demanding.
one does not follow the other.
There is NO additional risk, because not only is a standard not code, there is zero DRM in the in EME standard, period. Claiming that there is, is an outright lie. What they are asking to be added doesn’t affect the standard at all and is designed only to kill it, it relates to the parts that have nothing to do with the W3C and is completely inappropriate to try and tack into this standard. it won’t result in any additional protections because it will only prevent the standard from becoming standardized, which is their deceitful goal.
They are using an outright LIE to try and tack in something that affects third parties, not the standard, in order to kill the standard, even though the standard will greatly benefit independent coders and end users.
This is addressed in the FAQ, which was linked in the OP:
Is EME DRM?
EME is intended as one component of a two-component system, the other being a Content Decryption Module (CDM). Some working group members argue that EME – that is, the part the W3C is specifying – is not DRM, and wouldn’t be covered under the DMCA and other statutes.
We’re skeptical of this claim. First, there are minor variations in implementations of the relevant statutes, and many of them have very thin litigation history, meaning that their exact contours are as yet to be determined. There’s a lot on the line here: liability for competitive new entrants and for those who make the web more secure for users. It’s worth taking measures to mitigate those risks.
There’s also the matter of EME’s intended purpose: the members who advocate for EME clearly intend it to be used in DRM. There is no useful role for EME without a DRM system, and no one would be working on EME if it wasn’t for its usefulness in DRM applications.
No one will be able to say for sure whether courts will view EME as DRM, but based on decades of history litigating DMCA cases, we think there’s a signficant chance they will.
EXACTLY, it isn’t the DRM portion, it is ONLY the discovery and interaction API and contains ZERO DRM as the W3C repeatedly clarifies over and over again, and hence would not be covered by DRM circumvention laws.
I get that. BUT, all the DRM code is in third party implementations still, exactly the same as it is today with plugins, so the browser implements ZERO DRM by adopting the standard and is not affected, this is exactly analogous to the current plugin system for DRM plugins, except it uses an API instead of proprietary plugin mechanisms. There is no legal implications to change from one to the other. Which of course is what the W3C keeps telling you guys, because it is true.
No not IN DRM, for the discovery and interaction WITH third party DRM, the distinction is crucial. It is useful for interacting with DRM and Encrypted Content systems in a standardized way, but it actually eliminates the liability of new entrants, which is one of its specific intended goals, the others being increasing user security and user privacy.
Yes, we actually can, because it doesn’t contain any digital rights management implementation code, it isn’t any more DRM then the browser itself or the computer itself. It is simply a way of interacting with DRM, which the browser and computer both are as well. It is the exact same separation that the current plugin system has, with the exception that it provides additional end user protection and security and privacy.
Those measures don’t affect the discovery API only the proprietary third party DRM solutions of the companies considering interacting with this standard, which is why this would kill the standard and affect zero additional protections. It reminds me of how congress people slip pork into bills they are trying to pass.
EME is already implemented in every single major browser, the W3C is just making it official in the standard. Wrong time and place to try and slip some heavy handed over reaching agreement, it doesn’t make any sense at all.
You’re a lawyer?
To further clarify
Currently DRM content is delivered via proprietary browser plugins. The discovery and interaction is via either the EMDED or OBJECT tags, and will let you know you don’t have the necessary plugin installed. So you have to track down and download and install the plugin and you can access the DRMed content. There isn’t any standardized way for the browser to interact with that plugin containered content, like pause, mute, play, etc.
What is being proposed doesn’t add any additional risk because it doesn’t change the breakout/separation at all, not one single bit.
The new standard would implement a standardized API that replaces the proprietary plugin system, so instead of one plugin per browser and the little guy locked out, anyone can use these new “plugins”. so the EME is the equivalent of the EMBED or OBJECT tags except that it can automatically find the correct Content Decryption Module and download and install it, and it can interact with it play, pause, mute, etc. The CDM which contains the DRM is still 100% third party separate from the browser, exactly like it is now.
There is no change in the separation of what is the browser and what handles the DRM content, the only change is standardizing the implementation and interaction so that anyone, event the small developers can use and interact with these systems in a much more intelligent manner. It is the standardization of plugins for handling media, that is all it is, it isn’t anything else, nor does it introduce any DRM to the browser or whatever is implementing the standard, this is a fact. These new CDM only affect media so they are much more secure then traditional plugins (see mozilla’s statement about this). These new CDM can be sandboxed so user privacy can be maintained, unlike traditional plugins which circumvent user security, see Flash Super Cookies etc. It is easy to see why these improvements don’t add any additional risk, and in fact greatly reduce end user risks and improve end user security, and improve accessibility for those with impairments, and improve the ability for new companies and small developers to interact with them.
[quote]
Does this mean Mozilla is adding DRM to Firefox?
No. Mozilla is providing a new integration point for third-party DRM that works with Firefox. Third-party DRM that works with Firefox is not new. Firefox (and every other browser) already provides another integration point for third parties to ship DRM: the Netscape Plugin API (NPAPI), which has been part of web browsers since 1995. What’s new is the ability of the third-party DRM to integrate with the HTML <video> element and its APIs when previously third-party DRM instead integrated with the <embed> and <object> elements. When integrating with <video>, the capabilities of the DRM component are more limited, and the browser has control over the style and accessibility of the playing video.[/quote]
No, i’m the technical side. You’re a lawyer? I’ve never heard a single coherent legal argument as to how this creates additional liabilities. the logic doesn’t follow on the technical side, and all the technical arguments clearly win out on it not having that effect. have you ever seen a single legal argument of how this would add additional risks? if so please post. cory hasn’t, nor has the eff, if they had i’d gladly examine such an argument to the best of my ability.
You do realize that as of 2016 every single major browser already implements EME, it is just being officially standardized? right?
Even Mozilla, who is the true champion of user rights, freedom of the internet, and privacy has implemented EME and made public statements about how it is incorrectly being misconstrued as the CDMs are the only propriety part and are third party.
You agree there’s concern about risk of liability since there’s not clear law, right?
No. No. No. I’ve repeatedly explained how there is ZERO additional risk. It doesn’t change the separation of DRM and browser that has historically existed, and in fact it is already implemented in every single major browser that exists today.
If you read my posts above, it is the exact same separation that the historical plugin system has. EXACTLY THE SAME. The only difference is improved user security, improved user privacy, and a standard that makes it easier for small developers and new entrants to interact the same way with these systems, and disabled users to use these systems. ALSO, again, it is already implemented by every major browser, it is just being formalized into the standard. Formalizing the standard doesn’t change a single thing with any of the browsers, they all already have EME.
[quote]
Does this mean Mozilla is adding DRM to Firefox?
No. Mozilla is providing a new integration point for third-party DRM that works with Firefox. third-party DRM that works with Firefox is not new. Firefox (and every other browser) already provides another integration point for third parties to ship DRM: the Netscape Plugin API (NPAPI), which has been part of web browsers since 1995. What’s new is the ability of the third-party DRM to integrate with the HTML <video> element and its APIs when previously third-party DRM instead integrated with the <embed> and <object> elements. When integrating with <video>, the capabilities of the DRM component are more limited, and the browser has control over the style and accessibility of the playing video.[/quote]
As of 2016 every single major browser already implements EME, it is just being officially standardized.
Trying to block this standard hurts everybody. It is a deceptive move that specifically hurts users security, user privacy, and accessibility for people with disabilities that are provided by this standard being implemented. Not having a standard blocks smaller third parties from every gaining traction or interacting with this content. The situation is pretty much the exact opposite of the FUD being claimed.
Slipping in an agreement pact doesn’t supersede any laws, all it does is block standardization.
I’ve supported the EFF in the past, but am really reconsidering because of their stance and dishonesty in regards to this issue.
How would finding flaws in the API which does not have any DRM in it fall into realm of the DMCA? The only way to violate DMCA is to reverse engineer somebodies DRM which means access to the vendors code that uses the API and that would fall outside of what the w3c is doing. Is the w3c going to start suing the white hat for finding security flaws for them?
The current environment is shit. Just look at Flash, Silverlight and other plugins that are currently used to distribute DRM content. We want to get rid of that. Pie in the sky ideals we want to ditch DRM but that is not happening anytime soon so why not tell the studios they can have DRM just it has to pipe all data through this API. We don’t care what kind of DRM just that it passes through the API and works for the end user on the other side. They are trying to make the best of a really really horrible situation as it currently exists.
Further you as an end user DO NOT HAVE TO USE THIS. Of course if you don’t then no Netflix, Hulu, AmazonPrime, Spotify, or whatever else.
ETA what @redesigned said… we have been over this with Cory before many many times, including people working for w3c. There will be no DRM in HTML5.
