Re: DRM nonsense

On Feb 12, 2013, at 8:48 AM, Florian Bösch wrote:

DRM does not belong into HTML, nor into any kind of W3C standard for the following reasons:


1) The core premise of using encryption with only one trusted party is flawed. As such it gives rise to a variety of obfuscation schemes.

The party performing the decryption (the CDM) is trusted.


2) A user-agent must be able to obtain the raw bytes of the media in order to work with them (display, composit, output etc.).

The content key, decrypted encoded content, decoded content and analog rendered images are different things and in practice protected to different extents.


3) The standard (intended to define things) would have to omit the essential bits of how something works (in order to obfuscate them)

It's not intended to standardize any specific DRM.


3) Open Source browsers are discriminated against in the consumption of such media because they cannot include an implementation.

4) An already fractured media landscape on the web, gets more fractured by requiring proprietary runtimes to be present, responsible for the decoding of encrypted media.

5) The distributors of the proprietary runtimes would have to refuse running for programs they did not approve of (such as wget, curl, firefox, webkit etc). As such they become the gatekeepers on which party can make browsers that work, leading to a chilling effect on browser competition.

6) The distributors of the proprietary runtimes would also discriminate against marginal operating systems (such as linux etc.) because they would not port their runtimes to these systems, thus leading to a chilling effect on the operating system competition.

7) Previous standards that omitted how something actually works (such as <audio> and <video>) are a prime example how the standard failed to make things interoperable. People wishing to deploy <audio> and <video> are still facing substantial hurdles to do so because there is no set of common codecs/containers supported by every browser. DRM as a standard would further this effect.

8) Accessibility will suffer from the inclusion of DRM in a variety of ways (screenreaders, subtitles, etc.).

9) A range of useful technologies (such as WebGL, Web Audio Data API, CSS Shaders etc.) will not be able to work with media in these formats.

On the 7 points immediately above, this is the case already. The proprietary runtimes are plugins such as Flash or Silverlight. If they want access to content, users are required to install these large and complex pieces of software and give them access to their machine without the usual protections of the browser. I understand that for this reason browsers would prefer to reduce support for plugins.

Our proposal does not fundamentally change this situation, but moves from using large, general-purpose, arbitrary plugin components to small browser-vetted single-purpose CDMs. It is not a proposal to encourage the use of DRM, but rather a proposal to encourage the use of HTML5.


10) A DRMed media stream cannot trust a user-agent. It can also not trust the operating system, the video driver or the audio driver. That leaves no trustworthy party to actually implement the standard.

See above.


11) DRM schemes as a means of copy-restriction have been repeatedly been shown to be defeated. The same would happen to any DRM scheme supported by browsers. As such, they cannot make things copy-restricted for so inclined users. They can however worsen the experience for everybody else.

12) DRM schemes are therefore mainly a means of the "media" industry to limit competition, control a market, raise new barriers of entry, break interoperability and fracture the media landscape. It cannot be the purpose of a standard to help the "industry" achieve these goals.

The judgement on what requirements to place on the use of a creative work lies with the author of that work. The above arguments should be addressed to those authors, not to this standards activity.


13) DRM methods are among the most patented technologies in existence. Any standards body which dabbles in them and any browser vendor implementing them would draw inevitable lawsuits from patent trolls (non practicing entities) and real companies alike.

This is one reason why we don't propose standardizing a specific DRM scheme.


14) Since only proprietary runtimes can implement the DRM scheme, it would be nothing more than a new plugin API.

I think it's unlikely that browsers would expose an open plugin API for this, allowing arbitrary user-downloadable CDM plugins (for exactly the reasons that people decry a "new plugin API"). Whilst there may be a plugin-like API internally, I would expect it to be open only to explicitly browser-vetted and explicitly integrated CDMs.


15) The intent of DRM schemes is to introduce incompatibility intentionally. As such, it would only be missused to exclude other vendors, users and competitors from certain platforms. For instance Netflixes DRM plugin for Chrome would discriminate against firefox, it would also discriminate against linux and it would discriminate against Amazons DRM plugin, unless Amazon can get as many users to install their plugin or vice versa.

This is not the intent of DRM schemes. I don't expect there to be a "Netflix DRM plugin" or "Amazon DRM plugin". In fact our system is independent of any particular DRM. i.e. we can work with many different DRMs, exactly so as to make the service as widely available as possible.


Closing note: DRM is often touted by the media "industry" as a technology. Its relationship to actual technology is about the same as the one of faith-healing to the discipline of actual medicine. It cannot work, it cannot be defined, yet it can hinder interoperability, ease of use and competition.

Attempts at the corruption of standards bodies by the media "industry" (or any other industry) have to be vehemently resisted. As a leading example of this one needs to look no further than Microsofts subversion of ISO/ANSI on document standards that set back adoption of common word processor standards to this day.