A few days ago, a proposal was put forward in the HTML Working Group (HTML WG) by Microsoft, Netflix, and Google to take DRM in HTML5 to the next stage of standardization at W3C. This triggered another 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 (@manusporny) 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 seems to be 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 and often create many security vulnerabilities. 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 sub-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.
I don’t have a comment on your main point (the tl;dr). Sounds sensible to me, I guess. But I do have comments on some other parts.
Plugins.
“A simple example of the problem is Silverlight by Microsoft…”
A nitpick: There are many who would say that Silverlight working best on currently-sold Microsoft products rather than All Platforms Evar is purely a business decision, not some *lack* of money and/or technical know-how, or even anything to do with it being a plugin. I watched Flash Player not working on my chosen operating system for a long time, and it was certainly not due to a lack of developers around the world willing volunteer lots of time and money to make it work on these systems. It’s probably a lot more about control than the fact that plugins suck for the web.
I certainly agree with your main point, that plugins in and of themselves are difficult and probably are a nasty headache-y way to implement DRM on the web.
What Larger Content Protection companies can do:
“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…”
In general, and not limited to this unwieldy plugin-system, I would expect larger Content Protection companies to remain as (either) obstinate or incompetent as they’ve demonstrated so far with protection schemes in general. So long as discs I still buy (or rent at the video store! yes, I do) still don’t always play in one of our laptops and give us some garbled message about piracy (after all, users *are* adversaries), I couldn’t assume that somehow magically things will be done so much better by similar companies when it comes to the web simply because they are large. What they will maybe do better than smaller companies, is the legal stuff.
The Simple Decryption part was good for a laugh. Or a fear. o_O
Lastly. Should the spec mention users as adversaries? Yes.
“It insinuates that people that listen to radio and watch movies online are potential adversaries.”
Of course. User *are* adversaries, in the industry’s view. We could pirate things before anyone bothered making them available for purchase online, because the large media industries did not want to sell anything online. And now that they have been forced to start moving in that direction, they still hang on to obscurely-reasoned delivery methods such as having versions of things only available in some countries (instead of Taking My Money, I either can’t have it, or I pirate it… either way I am obviously considered an adversary), or staggered geographical release dates (my friends in the States can legally pay to watch this movie now, but I must wait three months before joining them in that experience… the reason why eludes me). This is maybe because they still don’t understand the web, and it has inspired the “Shut Up And Take My Money” meme. And we still have the frustration that we need to remove DRM from our *purchases* so that
- the stuff we believe we are buying (and companies believe we are, I dunno, renting? licensing?) works across all devices, forever… So that when our family buys a book for the Kindle, that the same book can be read on an e-reader that is also accessible to the blind and visually-impaired members (which today would be… all other major commercial e-readers. Shame, Amazon, shame).
- the stuff we believe we own, since we paid for it, can be shared with friends/family. We loan or give to friends paper books, but we are criminals for doing it with e-books.
- the stuff we believe we own, we believe we should be able to enjoy anywhere: on our computers, at our home entertainment centers, in our cars, and in our pockets.
- the stuff we have paid for does not get deleted when a company (for example, Amazon) decides they liked your money but don’t want you to have the stuff you paid for anymore.
This all points to “users are adversaries” in my book. Actually, “customers are adversaries” would be better, but of course the web is wider than customer-company relationships.
If the spec is going to have a section about users, it should be honest and state how users are treated and considered in use cases. I would only change the current wording to the more honest “all users are potential adversaries”.
Great analysis, Stomme.
Re: Plugins – yes, you’re right. My underlying point is that at some point, there are a set of operating systems and browser combinations that are left in the dust. This is more rare when features are placed into the browser directly.
I think that the rest of your analysis is spot-on. I would like to see a “DRM” system that is fair to both content creators and viewers/listeners. Something that protects content, but for only for a period of time where monetization of the content is happening, and then the access controls open when the work stops being monetized. Clearly, a difficult system to build, but one where the copyright law, the public domain, and content creators are given equal footing.
Leaving aside issues of the effectiveness of DRM on piracy, there is one important point that we should consider. I realize that this point does not, in any way, address the technical concerns so ably elucidated in this post.
The current state of proprietary implementations by players such as Netflix makes it quite difficult for disabled people to access content via the web. The plugins, no matter how they’re designed, make for a poor user experience. If there is to be any benefit derived by this effort, it must be that browser implementations provide a consistently accessible and usable interface. Of course, since users are the enemy, this may not be the first thing that content providers and aggregaters are concerned about.
Pratik, That is also a very good point that I missed in my blog post. I’ll add it in when I get around to editing it again, crediting you with the insight.
The “adversary” term is standard for cryptography, which DRM is. The adversary is the party you are attempting to hide information from. In standard DRM systems, that is indeed the user, who shouldn’t ever get access to the unencrypted data themselves (only programs on the user’s computer that you trust to keep the user in the dark).
I see your point.
I’d argue that DRM is much more than just cryptography. “Effective” DRM uses cryptography and I understand that some of that language might creep into the EME specification. However, that word only appears in the specification once, and it’s in the FAQ section. I also agree with you that the specification does view the people that have paid for and that view the content as adversaries.
The point I was trying to make is that the spec doesn’t do itself any favors by using the word adversary, it should just remove the use of it.
To be honest, as a blind user who’s constantly struggled with DRM in one form or another, I don’t think there’s any merit in it.
Piracy is a social problem–it must be solved with social solutions. DRM is just a sure way to piss people off and estrange them from your business. I completely understand that people must be compensated for their work, but I really think the answer is watermarking and do-not-distribute warning signs at best and not content restrictions.
Even with the best DRM scheme I can imagine, where copying files between your own devices is completely transparent, you’ve got a litany of problems, from privacy (the mothership must know who you are, what you’ve got, and what devices you’ve got), to interoperability (devices must support your special formats or streams for all time in spite of a near-constant attack against the protection system), to use cases (allowing for the re-use, lending and loaning, or excerpting of content for any number of legal or noble purposes). I don’t think it’s worth that. And I especially don’t think it’s worth changing the honest expectations of honest people who buy content to do anything but “Own” it, in the most obvious and familiar sense of the word. The need to recognise the infallibility of any technical solution in solving a perceived problem for content creators without any regard for alternative forms of redress, by first seeing the evident truth that such a solution must necessarily violate the basic principle of trust and fairness that has worked so far for other forms of media by the content industry is, sadly, staggeringly apparent.
Right. Now I feel much better.
See also the DAISy Consortium’s position on DRM:
http://data.daisy.org/publications/docs/positionpapers/position_paper_protecting_content.html?q=publications/docs/positionpapers/position_paper_protecting_content.html
Cheers,
Sabahattin
All good points, Sabahattin. Thanks for the link to the DAISY Consortium’s position on DRM, it was a very enlightening read. I hope that the W3C will eventually adopt that position.
I think your analysis that Encrypted Media Extensions will lead to proliferation of proprietary plug-ins is the correct observation. However, I think the word “plug-in” may imply that the end-user could install these things. I think it’s not safe to assume that. Chances are that they will be CDMs that are tightly coupled with a particular SoC. See http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0136.html from an NBCUniversal representative about dual computing domains. The CDM in the computing domain that runs the browser can be a driver that enables you to push initialization data and encrypted video data into the second computing domain on your device that is tamper-proof against the user and has firmware for decrypting the video and sending frames to the GPU in such a way that the GPU ensures that the primary computing domain cannot read back the data.
So I think you are correct that EME implies a bunch of proprietary components, but you shouldn’t assume that those components have the availability and installability dynamics of current plug-ins.
I think comparing the problem space of EME to the problem space you have previously try to address using DRM is slightly off the mark. When you are in the business of selling consumers DRM-obfuscated files, there is the problem of making sure that those files still play in the future—potentially offline. EME targets online streaming, so the content needs to be playable for the duration of a movie and the network can be expected to be available for communication with the DRM mothership for the duration of the playback. Therefore, DRM designs for the EME case could be simpler than solutions designed for off-line DRM for files “sold” to the end user.
I think you are mistaken about key security and JavaScript as far as actual expected deployments go. You are correct about the clear key Key System leaking keys to JS, though. Since the actual purpose of EME is to be a bootstrapping mechanism for proprietary DRM systems, clear key is just a toy Key System that makes it possible to get EME through the W3C Process without having to show interoperability between the kind of key systems that Members actually seem to want to deploy. Actual DRM deployments would use a proprietary Key System where the initialization data that passes through JavaScript is encrypted such that only the CDM can decrypt the initialization data.
Tab already addressed the use of the word “adversary”. It’s a crypto term of the art, and treating the end user as the adversary is what DRM is all about.
Henri, thank you! This is really helpful.
re: plugins – You’re correct, my assumption was that different CDM mechanisms might be either directly built into the browser, or they’d be install-able via the browser’s plugin mechanism. The text of the EME spec states:
“Part of” certainly refers to what you are asserting. It was the “add-on to the user agent” part that I was concerned about. Here’s a dialog that I wouldn’t want to see in any browser – “To play video on this page, you need to install the Wizbango! CDM, click OK to continue.” As you know, things like that increase the attack surface for malware. If the only CDMs supported are the ones shipped by browsers, that makes me feel a bit better about the security threat. The spec should clearly state that CDMs are included by the User Agent and cannot be installed by end-users.
re: online streaming – point taken. It is true that EME doesn’t need to be as complicated as other DRM schemes. I still expect that there will be many versions of CDMs out there that need to be managed. I question any DRM scheme that assumes that it will be around for more than a year or two. I fear that once the DRM scheme is broken (which is inevitable) that shipping the next DRM scheme won’t remove the old broken one (because there will still be sites using it). So, over time, you get all sorts of DRM cruft built up in the browser because you are shipping a technology that will inevitably be broken and replaced. Now multiply this issue by the number of trusted computing chipsets out there and the minor differences in how the drivers operate differently on each platform. I think managing that is going to be non-trivial, all in the hope that the content is protected from point A to point B, when inevitably, someone will have a screen recording setup that will rip the movie and upload it to Mega or TPB. It’s this “managing the complexity” vs. “reduction in piracy” ratio that I’m concerned about. I’m not claiming to know what the ratio is, just stating that EME leads to an explosion in complexity and it would be terrible if it didn’t actually reduce piracy in the end.
re: key security. Yes, I realized that there is the possibility of an opaque key and that’s how “effective DRM” systems would be implemented. I was primarily pointing out the clear key mechanism and how awful it is. My original point was from a technical angle: Why build something into the spec that is clearly broken? You outlined the reason, which is to bypass the W3C interoperability requirements.
My concern is that, if this feature is required to be implemented by UAs, somebody is going to use that mechanism thinking that it protects their content when it does no such thing. It’s extra cruft that a browser vendor would have to implement that doesn’t add any useful functionality to the UA. So, the feature should either be removed, or it should very clearly explain that UAs shouldn’t ship the feature and that it’s only there for interoperability testing purposes.
Again, thanks for the response Henri. It’s the most helpful someone has been at actually discussing the technical aspects of the spec so far.
Thanks for posting this, Manu. I get the feeling you’re a pretty reasonable person, and you’re technically cognizant of what DRM really is — that much is evident by your anecdote about having to change systems every few months. Having said that, I still have to take exception to both your writing, and Digital Bazaar’s software.
First of all, let’s not play fast and lose with the word “piracy.” Accepting that it’s a slang term for copyright infringement, it’s still worth pointing out that legitimate users need to circumvent DRM. In fact, as you yourself point out, the end-user pirates have no need to concern themselves with DRM, while another commenter — someone with disabilities — points out that DRM circumvention is necessary to enjoy lawfully purchased content. So let’s be clear that DRM is something that principally inconveniences legal users.
Which gets into the lack of a stated goal. I do not think the *primary* goal of DRM is a reduction in piracy, but rather control. Without DRM, I could buy an ebook and listen to it as an audiobook as text-to-speech technology improves. Without DRM, you could buy a copy of Lord of the Rings and watch it on your Linux computer from a home media server. But with DRM, you’ll likely buy both the ebook, and the audiobook; you’ll buy both the DVD and the Amazon VOD copy. Big Content has figured out that if they control the channels of viewing, they can force a lot of redundant transactions, and that’s DRM’s real goal, as far as I can tell.
Finally, as a software developer myself, in all intellectual honesty I cannot use any word other than malware to describe any DRM system, yours included. Now before you write me off entirely as using overly charged language, pull up a definition:
Merrian-Webster: “software designed to interfere with a computer’s normal functioning”
Dictionary.com: “software intended to damage a computer, mobile device, computer system, or computer network, or to take partial control over its operation”
Arguably the most basic operation any computer performs is copying bits. Almost every speed improvement in computer engineering involves increasingly the pace of that bit copying: solid state hard drives read and write faster, caches make copies faster, increasing a CPU’s clock rate lets it copy bits faster. Any software that interferes with copying data, by definition, is designed to interfere with the basest function of a general purpose computer.
More importantly, I look to dictionary.com’s definition: “software intended … to take partial control over [a computer's] operation” — for example, by downloading the latest DRM scheme, removing 1984 from a user’s Kindle library, or by disabling playback on videos deemed unauthenticated.
I realize that given your line of work, you’re unlikely to take way of thinking, but I thought I would let you know that your opinion on DRM isn’t agreed upon by many users, and I do believe that you are taking advantage of your users ignorance when your company distributes DRM-encumbered software.
Just to clarify, we have written systems that employ DRM (past tense). I am happy to say that the work that we currently do: http://payswarm.com/ and https://dev.payswarm.com/ does not employ any sort of DRM.
The reason that our past project used DRM was because the content companies required it. No DRM, no content. No content, no business. The DRM we created had two stages – heavy encryption from peer-to-peer, and watermarking (digital receipt of sale embedded in the file) when the file was written to disk. The files were plain old MP3 files and could be moved from device to device after purchase. We felt it was a fair balance. Indie recording artists agreed. The major record labels seemed to think it was okay, but never gave us a final thumbs up, so we’ll never really know.
Regarding my use of the word “piracy”, yes – point taken. I agree with your definitions more than you may think I do.
In any case – we don’t use DRM with our current product line. I didn’t mean to imply that someone with disabilities is committing “piracy” when they want to view content that they have legally purchased. Your point about content channel “control” is a good one. We can argue DRM vs. malware all day long – there are good arguments on either side, I take no position on whether DRM is malware or not because I remain undecided. Thanks for the deep thinking and comments, much appreciated.
Thanks for your reply, Manu. I misunderstood you about PaySwarm and DRM; it’s good to hear that you’ve gone a DRM-free route and looking right now at PaySwarm, I rather like it. Micro-payments are something everyone really needs, and I’ve often wished for something like PaySwarm.
I think watermarking is actually a pretty reasonable thing to do. It’s like a digital serial number for media. It interferes with nothing, but at the same time, it at least gives you a way to detect what customers are leaking your content out into the open internet. To me that’s a lot like the serial number on a dollar bill; if you make a million copies of a $20, that serial number can be used to track down the counterfeiter.
Anyway, good to hear about PaySwarm and thanks again for bringing attention to the W3C proposal. I’ll add your blog to my RSS reader.
-Ken
Small clarification on PaySwarm. It isn’t just about Micropayments, it’s about regular payments as well. We want it to be super simple to send or receive money on the Web, we want to make sure the solution isn’t proprietary, we want to make sure it’s incredibly secure, and we want to make sure it’s built into all of the Web browsers.
Here are my views on DRM purely as a consumer/customer. All of the DRM schemes that I have encountered so far are a pain in the posterior. For me to accept any DRM scheme it must be completely transparent to me. That means that I can install and play the game I bought (legally), on a computer with no internet connection. It means that I can read the ebook or watch the movie that I legally purchased on any device without having to first remove or defeat the DRM. It means that my devices can read my ebooks to me if they have text-to speech capability.
To put it bluntly, I (and many other consumers) are tired of being treated like the arch-villian of the century by the content sellers! We are tired of others telling us which devices we may and which devices we may not use to read/listen to/watch our legally purchased content. We are tired of being told what we can and cannot do with our computers and other devices. It is indeed (as another poster pointed out) a control issue…they want to control as much as possible so as to gouge as much money from consumers as possible!
Making a REASONABLE profit is one thing, price gouging is another. And price gouging is what we are seeing from the content sellers these days.
All are excellent points, Martin.
How do you feel about watermarking as a DRM mechanism? Would you be okay with completely unencrypted files that are watermarked instead?
Umm, how is watermarking a DRM mechanism? It does not prevent anyone from pirating the content.
By watermarking, do you mean a signature embedded in the file that is unique to the user? So that if an user shares his files, he can be identified? This would not be acceptable to me because if my system is compromised/lost, someone can upload the content I bought legally and did not intend to share, resulting in huge penalty for me.
Watermarking is often lumped in with DRM mechanisms, even though it’s not entirely a DRM mechanism in its own right:
http://en.wikipedia.org/wiki/Digital_rights_management#Watermarks
The burden of proof for tying a watermark to a particular person is much higher than what you lay out above. Typically, the prosecutor would have to prove that 1) your watermark is on the files, 2) it was uploaded from you computer, and 3) you had control of your computer when the upload happened. Even then, it’s not a simple open and shut case.
Flash is not a good example of an interoperable plugin. It works terribly bad on Linux and in fact it’s been discontinued on both Linux and Android. That’s how the deep-pocketed Adobe takes care of interoperability.
And if Flash is the best plugin we can have, I don’t even want to think what it’s going to look like with DRM plugins.
Flash works pretty well, and has worked pretty well for me on Linux. That said, I do remember the days where it was awful, and there have been a number of times that the software regressed on me and I had to go to the Web to figure out some horrible hack that needed to be performed to get it working again.
So yes, good point. It also dove-tails into the point that there are going to be a certain subset of the population that are left behind w/ DRM. While some argue that doing so is a choice that the market is making, I think we can do much better. For example, HTML5 video doesn’t leave that many people behind and up until a few years ago, people thought that the IP surrounding video codecs on the Web was an intractable problem.
“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.”
Is there no room for moral or ethical arguments within the HTML WG? If a standard does exactly what it means to do, should its social effects (concerning openness, content availability, fair use, etc.) be ignored?
There is certainly room for that sort of discussion at W3C, there are long debates over the moral/ethical implications of the technology that W3C produces. However, with morally/ethically charged topics that have good arguments on both sides of the debates, it is easier to come to an agreement if technical issues are focused upon. It tends to disarm the situation so that some progress can be made.
So, a specification that allows governments to censor their citizens on the Web probably wouldn’t fly because the moral/ethical argument is fairly clear in most industrialized nations today. However, a specification like EME has strong opposition and support from multiple sides, so it’s harder to stick purely to a moral/ethical argument. You need to use other, more convincing arguments. Those arguments are almost always technical.
Does W3C consider the trends in technology (i.e. future direction of technology and the Web in particular)? As I pointed below, DRM is a dying trend and standardizing it goes against the future of the Web. It’s akin to making Flash a Web standard now, just because it’s still in use, while general trend it to substitute Flash with HTML. One can assume, that standard is intended to last for long, and serve a good purpose and define some direction, otherwise what’s the point to make it a standard. It doesn’t fit well with the direction where DRM is heading (even besides the unethical aspect of it). Or such trends aren’t taken in consideration when developing standards in W3C?
It does, and yes DRM is a dying trend. Yes, trends are certainly taken into consideration when developing standards in W3C.
W3C is a very diverse place – there are large companies involved, researchers, the general public. In many ways, that is fantastic because you have many parts of society at the table to provide feedback on these standards. Most all of the work is done in the open.
In this case, several large companies got together and worked on EME. Some researchers and some folks from the general public are rallying against the specification. Trying to find compromise and consensus is the thing that W3C excels at. It takes time, and it takes discussions like this, but in almost every case, W3C strikes a fairly good balance.
The best way to sway the decision is to join and contribute your thoughts to the debate: http://www.w3.org/html/wg/#join
I think ethical argument should be the most important one. Pushing unethical preemptive policing methods on the Web as “standards” is completely unacceptable. DRM is a dying out monstrosity, but it dies out slowly. Content industry can’t come to grips with reality fast enough. Music DRM was in use but died out. The same will happen with DRM on video, books, games and etc. with time. Building such backwards and unethical approach into the Web standard which helps proliferation and prolonging of DRM usage in general is and extremely bad idea and goes against the whole movement of the Open Web. Shame on Google for participating in this.
While I agree with your sentiment, you aren’t considering content authors who are not okay with people enjoying the stuff that they create for free. If they can’t make a living doing what they’re passionate about, then that’s a net negative on society. I’m not saying DRM is the solution, but this problem needs to be addressed. There are compromises that can be made, like:
1) Create a DRM system that is open source. It’s breakable, but it takes a non-trivial amount of effort to break it. The upside is that you don’t have to worry about black-box plugins in browsers, privacy implications, and security issues.
2) Accept black-box, independently verified watermarking mechanisms. There is no DRM in this case, but files can be tracked back to who bought/shared them to push people to not do that with content that they’ve purchased. It doesn’t prevent professional piracy rings, but it’s an acceptable level of protection for many content creators.
The problem with your approach is that the general public is not savvy enough to reject DRM. Many folks want to watch something they enjoy, and as long as the DRM isn’t in their face, then they find it okay.
For example, I have a Netflix account, I know it’s DRM’ed, but I don’t care as I am just renting a video, there is a large selection, the price is right, and I don’t care about storing the video forever. That is, DRM is fine (for me) in this case because the price is so low that I don’t expect to “own” anything, the selection is pretty great, and I don’t even know the DRM is there.
*>If they can’t make a living doing what they’re passionate about, then that’s a net negative on society. I’m not saying DRM is the solution, but this problem needs to be addressed.*
Content industry needs to realize a few key things – “piracy” exists and will exist, as well as paying customers exist and will exist. It’s basically all about increasing incentives for one or the other. Content creators (or distributors) have basically two paths to address it:
Path1: Improve delivery channels – i.e. make the content easily and comfortably available to those who buy it. This implies the absence of any DRM – i.e. simply deliver files, streams and etc. which can be easily accessible on any platform, on any device, can be transferred wherever the user wants to for their personal use. Piracy will still be possible here, but implicit part of this path – paying users are treated with respect, users have incentive to pay in order to compensate the work of the authors and get a comfort of using the content the way they want to. This path is still a minority, but slowly starts to get traction because it’s a logical and ethical path.
Path2: Police delivery channels – i.e. create all kind of DRM and roadblocks on the way of the paying users presumably in order to prevent illegal redistribution. Piracy will still be possible, since someone will just devise ways to break DRM and the moment it’s broken – the content will be pirated in the wild, but implicit part of this path – paying users are treated with disrespect (as potential thieves), they are are forced to use the content only in a certain way, which limits platforms, devices and severely degrades the usability and value of the content for the end user. In result it increases the incentive to pirate content, since users feeling such disrespect feel the same in return – i.e. it doesn’t create an incentive to pay someone who treats you as a thief when you buy something. All in all it’s an unethical path.
To summarize – piracy will be present in both paths. But DRM free path is based on mutual respect and making the content easily available, DRM path is based on insulting the end user and creating artificial barriers for content consumption. So what path do you think will bring more paying customers to any content creator? And to answer your concern – no, DRM is not needed at all for content creators to earn their living and this problem doesn’t need to be addressed especially in context of W3C. What needs to be addressed – is educating content creators that DRM damages them even more than they think it benefits them.
In general this aspect is the reason why I personally don’t use Netflix or other DRMed services (unless that DRM is trivially removable) – I don’t want to deal with those who don’t treat their customers with respect, and DRM implies such attitude by default.
So, the life of plugin authors is awful. They invest heavily in the browser using stuff like BHO, NSAPI and PPAPI yet all user-agents will advise against plugins in general, even IE, and some of them will actively block some of them.
So this spec (30 pages, 67 mentions to ‘CDM’) just suggest to move the binary blob deeper in the browser stack in a non-defined, non portable, user-agent dependant way and provides a webidl to connect this black box to a MediaStream that can be rendered in a video tag. It is a sneaky way to make W3C endorse plugins.
If W3C is going to endorse plugins, then I’m sorry for all past contributors to the W3C specification body.
Yeah, here’s hoping that a better way forward is found. I like this suggestion: http://www.brucelawson.co.uk/2013/more-on-drm-in-html5/#comment-1314315
I think we all just need to read the “Criticism” section in any wiki regarding “W3C” to understand that “NO to DRM in HTML5″ is the safe way. You’re going to piss off the Internet with this (Microsoft-driven) DRM stuff yet again.
Another thing this specification totally misses is the use-case where the operating system is the adversary.
If I want to send something to my user, and the client’s operating system is my adversary, this specification does me no good.
The hardware built by Hollywood can support my use-case though the W3C specification disregards it.
i think the whole point of EME is to provide the much asked for DRM to the content industry.
the guys in suits don’t care for the specs, they simply want DRM. and by DRM they mean encryption.
who cares, if it is easy to circumvent? it all is.
main thing: now i can license content and sell it protected with DRM. hooray.
that’s what netflix wants.
clear keys for the win.
I didn’t follow work on EME that closely lately, but where are we now—and has your stance changed in any way?
(I was late expressing my objections back in 2013 – http://meiert.com/en/blog/20131122/drm-and-html/ – and, unfortunately, am also now.)
I’m a bit torn about EME. I know that the reason it exists is because the content industry doesn’t want to back down from DRM for “high value” content. I was hoping that the WebCrypto stuff would’ve arrived faster than it did and could have been used as a not-as-good-but-good-enough replacement for DRM (with streams encrypted to a viewer’s rotating private key).
That hasn’t happened and the current EME spec provides a mechanism that is /very/ complicated with very questionable upsides/economics. I just don’t think this is something that belongs at the core of the *Open* Web Platform.