A few days ago, a new proposal was put forward in the HTML Working Group (HTML WG) by Microsoft, Netflix, and Google to implement DRM in HTML5. This triggered an uproar about the morality and ethics behind DRM and building it into the Web. There are good arguments about morality/ethics on both sides of the debate but ultimately, the HTML WG will decide whether or not to pursue the specification based on technical merit. I am a member of the HTML WG. I was also the founder of a start-up that focused on building a legal, peer-to-peer, content distribution network for music and movies. It employed DRM much like the current DRM in HTML5 proposal. During the course of 8 years of technical development, we had talks with many of the major record labels. I have first-hand knowledge of the problem, and building a technical solution to address the problem.
TL;DR: The Encrypted Media Extensions (DRM in HTML5) specification does not solve the problem the authors are attempting to solve, which is the protection of content from opportunistic or professional piracy. The HTML WG should not publish First Public Working Drafts that do not effectively address the primary goal of a specification.
The Problem
The fundamental problem that the Encrypted Media Extensions (EME) specification is attempting to solve is to find a way to reduce piracy (since eliminating piracy on the Web is an impossible problem to solve). This is a noble goal as there are many content creators and publishers that are directly impacted by piracy. These are not faceless corporations, they are people with families that depend on the income from their creations. It is with this thought in mind that I reviewed the specification on a technical basis to determine if it would lead to a reduction in piracy.
Review Notes for Encrypted Media Extensions (EME)
Introduction
The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.
A simple example of the problem is Silverlight by Microsoft. Take a look at the Plugin details for Silverlight, specifically, click on the ?System Requirements? tab. Silverlight is Microsoft?s creation. Microsoft is a HUGE corporation with very deep pockets. They can and have thrown a great deal of money at solving very hard problems. Even Microsoft does not support their flagship plugin on Internet Explorer 8 on older versions of their operating system and the latest version of Chrome on certain versions of Windows and Mac. If Microsoft can?t make their flagship Web plugin work across all major Operating Systems today, what chance does a much smaller DRM plugin company have?
The purpose of a standard is to increase inter-operability across all platforms. It has been demonstrated that plug-ins, on the whole, harm inter-operability in the long run. The one shining exception is Flash, but we should not mistake an exception for the rule. Also note that Flash is backed by Adobe, a gigantic multi-national corporation with very deep pockets.
1.1 Goals
The goals section does not state the actual purpose of the specification. It states meta-purposes like: ?Support a range of content security models, including software and hardware-based models? and ?Support a wide range of use cases.?. While those are goals, the primary goal isn?t stated once in the Goals section. The only rational primary goal is to reduce the amount of opportunistic piracy on the Web. Links to piracy data collected over the last decade could help make the case that this is worth doing.
1.2.1. Content Decryption Module (CDM)
When we were working on our DRM system, we took almost exactly the same approach that the EME specification does. We had a plug-in system that allowed different DRM modules to be plugged into the system. We assumed that each DRM scheme had a shelf-life of about 2-3 months before it was defeated, so our system would rotate the DRM modules every 3 months. We had plans to create genetic algorithms that would encrypt and watermark data into the file stream and mutate the encryption mechanism every couple of months to keep the pirates busy. It was a very complicated system to keep working because one slip up in the DRM module meant that people couldn?t view the content they had purchased. We did get the system working in the end, but it was a nightmare to make sure that the DRM modules to decrypt the information were rotated often enough to be effective while ensuring that they worked across all platforms.
Having first-hand knowledge of how such a system works, it?s a pretty terrible idea for the Web because it takes a great deal of competence and coordination to pull something like this off. I would expect the larger Content Protection companies to not have an issue with this. The smaller Content Protection companies, however, will inevitably have issues with ensuring that their DRM modules work across all platforms.
The bulk of the specification
The bulk of the specification is what you would expect from a system like this, so I won?t go into the gory details. There were two major technical concerns I had while reading through the implementation notes.
The first is that key retrieval is handled by JavaScript code, which means that anybody using a browser could copy the key data. This means that if a key is sent in the clear, the likelihood that the DRM system could be compromised goes up considerably because the person that is pirating the content knows the details necessary to store and decrypt the content.
If the goal is to reduce opportunistic piracy, all keys should be encrypted so that snooping by the browser doesn?t result in the system being compromised. Otherwise, all you would need to do is install a plugin that shares all clear-text keys with something like Mega. Pirates could use those keys to then decrypt byte-streams that do not mutate between downloads. To my knowledge, most DRM?ed media delivery does not encrypt content on a per-download basis. So, the spec needs to make it very clear that opaque keys MUST be used when delivering media keys.
One of the DRM systems we built, which became the primary way we did things, would actually re-encrypt the byte stream for every download. So even if a key was compromised, you couldn?t use the key to decrypt any other downloads. This was massively computationally expensive, but since we were running a peer-to-peer network, the processing was pushed out to the people downloading stuff in the network and not our servers. Sharing of keys was not possible in our DRM system, so we could send the decryption keys in the clear. I doubt many of the Content Protection Networks will take this approach as it would massively spike the cost of delivering content.
6. Simple Decryption
The ?org.w3.clearkey? Key System indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is required.
Wow, what a fantastically bad idea.
- This sends the decryption key in the clear. This key can be captured by any Web browser plugin. That plugin can then share the decryption key and the byte stream with the world.
- It duplicates the purpose of Transport Layer Security (TLS).
- It doesn?t protect anything while adding a very complex way of shipping an encrypted byte stream from a Web server to a Web browser.
So. Bad. Seriously, there is nothing secure about this mechanism. It should be removed from the specification.
9.1. Use Cases: ?user is not an adversary?
This is not a technical issue, but I thought it would be important to point it out. This ?user is not an adversary? text can be found in the first question about use cases. It insinuates that people that listen to radio and watch movies online are potential adversaries. As a business owner, I think that?s a terrible way to frame your customers.
Thinking of the people that are using the technology that you?re specifying as ?adversaries? is also largely wrong. 99.999% of people using DRM-based systems to view content are doing it legally. The folks that are pirating content are not sitting down and viewing the DRM stream, they have acquired a non-DRM stream from somewhere else, like Mega or The Pirate Bay, and are watching that. This language is unnecessary and should be removed from the specification.
Conclusion
There are some fairly large security issues with the text of the current specification. Those can be fixed.
The real goal of this specification is to create a framework that will reduce content piracy. The specification has not put forward any mechanism that demonstrates that it would achieve this goal.
Here?s the problem with EME ? it?s easy to defeat. In the very worst case, there exist piracy rigs that allow you to point an HD video camera at a HD television and record the video and audio without any sort of DRM. That?s the DRM-free copy that will end up on Mega or the Pirate Bay. In practice, no DRM system has survived for more than a couple of years.
Content creators, if your content is popular, EME will not protect your content against a content pirate. Content publishers, your popular intellectual property will be no safer wrapped in anything that this specification can provide.
The proposal does not achieve the goal of the specification, it is not ready for First Public Working Draft publication via the HTML Working Group.
Source: http://manu.sporny.org/2013/drm-in-html5/?utm_source=rss&utm_medium=rss&utm_campaign=drm-in-html5
arnold palmer augusta national blake griffin pau gasol marlins park marbury v. madison 2013 lincoln mkz
কোন মন্তব্য নেই:
একটি মন্তব্য পোস্ট করুন