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

On Tue, Feb 21, 2012 at 3:16 PM, Adrian Bateman <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.

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.

This is ignoring the more general concerns with the concept of DRM,
namely that it's technically impossible and 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

Received on Thursday, 23 February 2012 22:26:12 UTC