Digital Rights Management
- 1 Encrypted Media Extensions
- 2 Call for Consensus to publish FPwD
- 3 Support
- 3.1 The web is competing with other platforms with DRM support
- 3.2 Rejecting DRM is unlikely to lead to content being distributed without restriction
- 3.3 Business need by some W3C stake-holders
- 3.4 similar to a GPU
- 3.5 Insisting on open standard is dictating
- 3.6 Web delivered video is becoming a primary entertainment platform and the transition from native to web is 'good web stewardship, consumer friendly'
- 4 Objections
- 4.1 Technically incomplete
- 4.2 Depends on licensing
- 4.3 DRM depends on servers with a finite life
- 4.4 EME does not reduce piracy
- 4.5 DRM is a failure
- 4.6 Against the spirit of the open web
- 4.7 DRM is against open source software
- 4.8 HTML engine can be implemented in a CDM and the result conflicts with many standards
- 4.9 Users lose control of security and privacy of their browser
- 4.10 Integrated into the browser trivializes the trading off of choice
- 4.11 Small thing to ask users to use a separate application
- 4.12 Same argument could be used to add DRM in other areas
- 4.13 Plugins give a bad user experience
- 4.14 Does not forbid or discourage UA or user specific DRM
- 4.15 Proponents require the solution be supported by legal sanctions
- 4.16 Proponents want to securely identify the device
- 4.17 Proponents want to be able to identify the context in which content appears
- 4.18 Proponents want to be able to control the operating system supported video paths to the screen
- 5 Businesses supporting the EME FPWD CfC
- 6 Resources
Encrypted Media Extensions
The Encrypted Media Extensions (EME) extends the HTMLMediaElement element to provide APIs to control playback of protected content. The specification does not define the DRM system, just an interface to it.
Call for Consensus to publish FPwD
A Call for Consensus (CfC) to publish EME as a FPWD was posted on the 22nd January 2013 and after some objections the Chairs declared that the call for consensus does not pass but was within scope and that ".. when we re-evaluate the request to publish an FPWD, we will consider only concrete and specific objections that have been filed in the form of bugs. The determination will be based on whether there is a good faith effort to resolve such bugs..."
The W3C Team have decided that the EME specification is within the scope of the HTML WG. The Proposed HTML WG Charter states: "Some examples of features that would be in scope for the updated HTML specification: additions to the HTMLMediaElement element interface, to support use cases such as live events or premium content; for example, additions for: facilitating adaptive streaming (Media Source Extensions), supporting playback of protected content ...".
The HTML WG Chairs interpret the W3C Team decision that EME is in scope to be a declaration that the EME and DRM are consistent with W3C's principles: "the Chairs take this to say that the W3C Team believes this work is in scope for the W3C itself, consistent with the W3C's principles, and appropriate for the WG to pursue." Note that Apple are a strong proponent of EME and Chair the HTML WG that made this interpretation.
The problem is that a media element with the protection required would be very attractive to all copyright holders, not just new release high definition video content copyright owners. The EME would allow a HTML engine to be implemented within the media element, similar to an iframe. The W3C management's analysis is faulty as it only tests a very narrow use of the EME against the charter. Many existing standards are required to give the user control over the web browser and a protected web browser conflicts with this and an analysis of the wider uses for the EME would have shown this conflict and rejected the EME as being out of scope.
"This answer an *extremely* narrow form of the objections in this vein, which I don't think anyone ever actually stated" ... "The objections from multiple people are that this kind of work is not in scope *for the W3C itself*. We produce specifications for the Open Web, with the goal of helping ensure interoperable implementations that make our technologies robust and easy to use for authors and users. The EME spec appears to violate this in spirit, and in specifics when you actually get the editors to nail those down (as they're extremely unspecific in the draft itself)." 
"I am now convinced that the W3C management is determined to ignore the fundamental objections to EME which were raised and that it likely will continue on that path in the future." 
"There is one clarification I would like to be made though is how this specification is in accordance with the W3C mission. Especially the Open Standard Principal and the parts about “Collective Empowerment” and 'Availability', which to my understanding, especially in the context of Web standards, would cover complete implementation with free software licenses."  The W3C Mission OpenStand principles
The issue was discussed on Slashdot.org.
The web is competing with other platforms with DRM support
Rejecting DRM is unlikely to lead to content being distributed without restriction
Business need by some W3C stake-holders
"there is a clear business need for *something* by more than one W3C stake-holder" 
similar to a GPU
"not completely unlike providing interfaces to pushing a 3D model into a GPU to display, IPC or even sockets" 
Insisting on open standard is dictating
"The gist of many of the objections to date have been based on political and philosophical differences around how the web should be used. If you truly ascribe to the notion that the Web Platform be open to all, irrespective of their philosophical position on *any* topic, then the objections around "incompatibility with FOSS" to date should be rejected out of hand. Insisting that it *only* be used in one way - *your way* - as many appear to be suggesting, isn't open, it's dictated." 
"As I previously noted, there is a significant number of W3C stakeholders who desire to use this open platform to interact with their constituents - people who, on both sides of the transaction, agree to enter into a contract. As part of that contract, there is a need for a means to secure the intellectual property that is being exchanged, so that the intellectual property remains marketable to those who initially invested in the creation of that content. To suggest that they not be entitled to that right is astoundingly naive and offensive to me." 
"... please don't try and dishonestly twist the concepts around. 'Tolerance' does not mean being tolerant to intolerance; doing so can easily reduce the net tolerance of a society, which defeats the purpose." 
"... having the 'choice' for a media distributor to require you to use an OS/browser that ships a particular DRM module (that perhaps limits you even further, such as refusing to install if it detects, say, a debugging tool on your computer), will likely result in less choice overall, as the user can't switch to a new browser that doesn't support that module, or a new OS that the DRM vendor doesn't support." 
"Please stop suggesting that this is about giving users freedom. It is not customers who are being given choices here, it is media distributors, and all of the choices this specification offers are either (a) already present, as you can ship DRMed video with Flash or similar existing plugins, or (b) strictly worse for consumers, as the introduction of new closed source plugins results in more interop failures, and the potential to bring in some *very* unfriendly concepts like Trusted Computing." 
"We do, in fact, limit what you are allowed to give away with contracts. In the US it is illegal to contract yourself into slavery, for example. It is sometimes possible to increase a person's de facto freedom by restricting their freedom in what they can give away, as it prevents such a loss from ever being a bargaining chip." 
"It is illegal to circumvent DRM in the US and many other countries. That is not a mere "philosophical" disagreement. There are many DRM-decoding programs in existence that are illegal but not prosecuted, as the relevant companies either don't care or realize that they profit from wider decodability." 
"So you're saying that you should be able to break a license agreement with impunity, and do what you like with material that is not yours? It's not even as if the latest recording of your favorite musician is a necessity of life, either. If *you* don't like the terms they set on your ability to listen to their music, don't buy it. Telling others that they cannot, and they cannot use your favorite medium, is ..." 
Web delivered video is becoming a primary entertainment platform and the transition from native to web is 'good web stewardship, consumer friendly'
"Web delivered video is becoming more than an alternative pipe for delivering broadcast television content, it is becoming a primary entertainment platform in its own right. Over time web and broadcast commercial media will become relatively indistinguishable to consumers. ... The ability to move from the native application model to an interoperable web "video receiver" model is precisely one of those transformative inflection points and will provide enormous value to web consumers. This is why the W3C developing the MSE and EME specifications is good web stewardship, consumer friendly and important to both the web and the broadcast industries." 
"The spec is technically incomplete, relying on other technologies which have no expectation of being openly and freely specified (and, in fact, *can't be*, if they are to maintain the security aspects they purport to have). " 
"deliberately underspecified, non-interoperable user-hostile CDMs" 
"whether it's appropriate for a W3C specification to rely exclusively on components that cannot be independently interoperably implemented when the specification is used for its intended purpose?" 
Depends on licensing
"Because the spec relies on technologies that will never be openly specified, it's guaranteed to be an interop failure. Licensing will be *required* at some point in the toolchain, which goes against the spirit of our royalty-free license on our specs." 
DRM depends on servers with a finite life
It will not be possible to view the content once the server is decommissioned. This might be against a value to allowing the web content to be viewed in future.
EME does not reduce piracy
"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." 
Reducing piracy is not the only goal of DRM, the goal is also to gain more control and to use this to extract more revenue.
DRM is a failure
DRM seems to be a failure and there seems to be a transition to other techniques such as watermarking.
Against the spirit of the open web
DRM is against open source software
"Also, why do people insist that drm is incompatible with foss? Yes, today's implementations are largely security through obscurity but there is nothing that fundamentally prevents an open source drm stack if one wished to make the investment." 
"I consider it impossible to do that while keeping the software open until the opposite is proven."
"I don't understand. The standard DRM scenario, which we know is the majority reason for pursuing this spec, is one where encryption is desired both during protection and at the end point, with the data decrypted only at the latest possible moment, in the most inaccessible-to-the-computer's-owner way possible.
Transferring data from Alice to Bob, when Bob's not allowed to know how to decrypt it, requires Bob's device to have a secret that Bob doesn't have access to. Short very exotic protocols that I'm sure exist somewhere, this means that DRM is incompatible with FOSS, as the secret must be kept, well, secret from the computer owner." 
"How does the DRM in this spec avoid proprietary plugins?" 
"I object, on the grounds that this is just an API for encouraging the use of proprietary plugins ('CDMs')." Ian Hickson 
"'Up to the moment of play' is incompatible with FOSS, to the best of my knowledge. If it needs to stay encrypted after hitting the destination computer, you're out of luck." 
"It's certainly incompatible with the 'Anti-Tivoization' clause of GPLv3, in which the software license requires that the end user of the software must be able to modify it and still have it work. It's not incompatible with 'Open Source' per se." 
"If you require the file to be encrypted from the user you are sending it to, then you require a secret that the user doesn't know. FOSS requires all the code to be knowable by the user, and a popular browser (FF) and a popular family of operating systems (Linux) are both FOSS. If we make the reasonable assumption that those are the only two places the DRM module might live, then in a reasonable situation (FF user on Linux) there is no way to do DRM." 
"To say DRM is incompatible with some Open Source software is different from saying that it's incompatible with Open Source per se. One could write a media player application that is fully open source, with the intention that some parts are run on a Trusted Execution Environment (which itself could be open source) and this combination could be shipped to users in devices that meet the requirements for playback of protected content. The user would not be able to install a modified version on that device and still have the protected content aspects work, so no GPLv3 could be included, but it is still open source." 
"Protected content is not available in Firefox on Linux today - for the reasons you give - and I don't claim this specification provides a solution to that problem." 
"Open-source software is a valuable part of the industry, but it's not part of the W3C's mandate or modus operandi. Indeed, there are many standards bodies that require reference implementations (reference software source code) for all standards. The W3C doesn't even require that, and doesn't offer a reference implementation of any of its recommendations, as far as I know." 
The existence of an open source licensed implementation of the specification is not the test to be applied here. The test is: can a competent person write an implementation of the standard and license it on their own terms?
The last test is very important because without a free market for implementations of the standard the user looses all control.
You might argue that the EME alone is just an interface to a controlled plugin, and that the interface alone can meet all the above, but the intention of EME is to support DRM that does not meet the above tests and it is clear that there is no path to meeting these tests.
"Indeed this is the case and as a result the specification passes all the above tests: Given a CDM, anyone can implement the specification." 
"I interpret the concern to be that (i) the APIs for the relevant existing CDMs are not public. And the availability of those CDMs on all platforms is not assured and (ii) an alternative, fully open source, CDM has not been proposed. Thus an implementor needs not only to be competent but also to be privy to the relevant information (for example by licensing it) and working on a supported platform." 
"We must see what we can do to relax these requirements, but I would not accept that the test should be that specification must fully define a DRM system, as you suggest. We do not do this for other HTML specifications: The video element does not define a codec, the geo-location API does not define a method of determining geographic location, WebGL can't be implemented (performantly) without hardware which is in practice proprietary (i.e. graphics cards)." 
"it is difficult to see how an open-source CDM would have any hope of staying secure for any length of time at all" 
HTML engine can be implemented in a CDM and the result conflicts with many standards
The problem is that a media element with the protection required would be very attractive to all copyright holders, not just new release high definition video content copyright owners. The EME would allow a HTML engine to be implemented within the media element, similar to an iframe. The W3C management's analysis of the scope of EME is faulty as it only tests a very narrow use of the EME against the charter. Many existing standards are required to give the user control over the web browser and a DRM web browser conflicts with this and an analysis of the wider uses for the EME would have shown this conflict and rejected the EME as being out of scope.
Users lose control of security and privacy of their browser
The EME proposal supports limiting user control over their own User Agent which leads to a loss of control of security and privacy.
Even the monitoring that can be used by DRM is privacy concern. I would imagine that even free content would be attracted to taking advantage of the DRM support to monitor usage and this could lead to a big loss of privacy on the web.
Integrated into the browser trivializes the trading off of choice
By integrating DRM into the User Agent platform the tradeoffs involved for users will be trivialized and users are quite likely to make uninformed decisions.
Small thing to ask users to use a separate application
Users could just as well use separate software and/or hardware and most users would accept an appeal to do so rather than tainting the User Agent platform for all users.
Same argument could be used to add DRM in other areas
If it is accepted that web standards should support DRM then it would also be logical add DRM to the entire UA as many web content authors would presumably like the same level or DRM.
Plugins give a bad user experience
Experience with plugins such as Flash shows that they give a bad user experience for users that do need to customize the presentation for accessibility reasons.
For example, some argue that Flash is being withdraw from Android tablets because it does not suit these devices.
"The DAISY Board does not in any way promote DRM. The Board believes that DRM limits the legitimate use of digital publications by persons who are blind and print disabled. Persons who use Assistive Technology commonly manipulate digital publications in ways that most people without disabilities do not understand." 
Does not forbid or discourage UA or user specific DRM
"The current EME draft makes no attempt to encourage interop at the CDM level. For example, the current EME draft does not forbid or even discourage a UA vendor from promulgating a CDM that no other user-agent can support, and encouraging the creation of content for that CDM consumable only by that user-agent. Such an outcome would be antithetical to the mission of the W3C, and the W3C should not bless, appear to bless, or enable such scenarios." 
Further to the above, note that the EME draft does not forbid or even discourage a user specific CDM.
Proponents require the solution be supported by legal sanctions
"However, the BBC is unlikely to be able to use any such mechanism unless we feel that it is sufficiently secure that there would be the possibility of legal action in the event of bypassing it." 
Proponents want to securely identify the device
"We require the ability to securely identify a type of device, and enable or disable video playback based upon the answer." 
Proponents want to be able to identify the context in which content appears
"Identification of the context in which the content appears." 
Proponents want to be able to control the operating system supported video paths to the screen
"While we are not actively enforcing this requirement at present, the BBC notes that increasingly OS level features enable the passing of online video streaming over a network to third-party devices, in many cases with no encryption or device authentication. This would completely defeat the point of any content protection, and therefore a Content Decryption Module should be able to identify if the operating system supports such features and either flag to the operating system that it should seek a flag and enable/disable the feature as appropriate, or refuse to play the video. We feel that it would be helpful if the specification was able to specifically identify errors relating to this usage case." 
Businesses supporting the EME FPWD CfC
DRM in HTML5 by @manusporny
Workshop on Digital Rights Management for the Web World Wide Web Consortium, 22-23 January 2001.
OpenIPMP Open source DRM for MPEG-4 and MPEG-2.