Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

Tad,

To address your last point first: There is clearly a choice to be made as to whether the web platform should support commercial video services any time soon, or should wait for the DRM-free future you imagine below to arrive.

This will be a long wait. During this time many millions of $$ of engineering effort will be invested in providing commercial video services on other platforms: effort which could have gone towards making the web platform better in many different ways. These costs are also 'unnecessary costs on legitimate users', because investment is fragmented, duplicated, instead of targeting a single common platform. And the sums involved far exceed the sums involved in supporting DRM.

Some additional comments inline ...

On Feb 23, 2012, at 2:25 PM, Tab Atkins Jr. wrote:

On Tue, Feb 21, 2012 at 3:16 PM, Adrian Bateman <adrianba@microsoft.com<mailto:adrianba@microsoft.com>> wrote:
Hi all,

We have been collaborating on an API to enable encrypted media in HTML that we think
can be implemented in all browsers and support any container/codec and content
encryption solution without making major changes to the HTML Media element
specification. We think it solves most use cases without being overly large or
complex.

We'd like to get people's feedback on the proposal. It is posted here:
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Many content providers and application developers have said they can't use <audio>
and <video> because HTML lacks robust content protection. Without this functionality,
they cannot move their apps to the web platform. Many consumer electronics are taking
advantage of HTML for both video playback and user interfaces, yet their content
protection solutions are typically tied to the device. We believe that working
towards a common solution will reduce fragmentation between all HTML platforms.

This has been raised in the Web & TV Interest Group [1] and mentioned in their
feedback [2]. We believe this extension specification supports the counter proposal [3]
for ISSUE-179 [4]. It demonstrates how to provide additional functionality to the
HTML5 media element without requiring a generic mechanism like <param>.

Best regards,

David Dorwin, Google
Adrian Bateman, Microsoft
Mark Watson, Netflix

[1] http://www.w3.org/2011/webtv/wiki/MPTF#Content_Protection
[2] http://lists.w3.org/Archives/Public/public-html/2011Dec/0120.html
[2] http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change
[3] http://www.w3.org/html/wg/tracker/issues/179

Despite the abstract attempting to claim that this spec is not DRM,
it's sole purpose is to communicate with a browser's built-in DRM
scheme.  Essentially, this spec describes a DRM system but leaves the
encryption/decryption part unspecified.

The first sentence, yes, though there is a genuine reason for referring to 'protection system' and not 'DRM'. 'rights management' brings in a whole bunch of stuff related to rights expression and associated business logic, which we prefer to be dealt with by the service/application.

The second sentence, no: we describe how to *communicate with* the protection system, but we do not describe a protection system. The contents of the message and key fields are protection-system specific and may consist of signed/encrypted messages that only the protection system understands. We do not specify these.

Incidentally, specifying encryption/decryption should be uncontroversial as these are well-defined functions widely implemented in free open-source software.


This does not solve the problems brought up last time against adding
DRM to <video>.  In particular, a browser like Mozilla is *legally
prevented* from actually implementing DRM, because they have to reveal
all their code, including the decryption code that contains the
secrets you use to decrypt.  We should not be attempting to put
anything in HTML which won't be implemented by one of the major
browsers.

>From a specification point of view, the problem is solved because we don't specify protection systems (except clearkey, which should be uncontroversial).

You can certainly implement the communication with a protection system in open source, just as open source browsers access many and varied device and platform capabilities without shipping implementations of those capabilities.

DRM doesn't primarily derive the security it offers from being closed source: you could publish the code for most if not all DRM systems without making them easy to crack. I'm not saying that it's possible to have an open source DRM that can just be downloaded and installed on arbitrary platforms. Or that there are not IPR issues. But they are not based on security through obscurity.


This is ignoring the more general concerns with the concept of DRM,
namely that it's technically impossible and practically useless,

Of course it's not possible to make it impossible for protected content to be copied. Any more than a speed bump makes it impossible to break the speed limit. It merely makes it more difficult, uncomfortable, very obviously not endorsed by the owner (or the content, or the road).

DRM is probably more effective at it's objective than speed bumps are at theirs and noone would call speed bumps "technically impossible" or "practically useless".

imposing unnecessary costs on legitimate users while doing nothing
whatsoever to actually stop copyright infringement.  The entertainment
industries in general are moving away from DRM as an effective concept
- images have been DRM-free forever, the music industry is mostly
DRM-free now, and book sellers outside of Amazon and B&N (which have
an incentive to lock users to their devices) commonly use DRM-less
formats like ePub.  Movies became realistically sharable on the
internet more recently than those other media types, so the industry
is later to the realization that sharing is fine and doesn't actually
hurt them, but they'll come around to in the reasonably near future,
just like every other industry did..

Frankly, I'm disappointed that my company was willing to co-edit this spec.

~TJ