W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 24 Feb 2012 10:17:44 +0200
Message-ID: <CAJQvAucKzMSze7E3BaVY=ELd=k0bfTH7s4qozDD4v43mR=tB2Q@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
On Fri, Feb 24, 2012 at 1:59 AM, Mark Watson <watsonm@netflix.com> wrote:
> 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.

It would be more appropriate to say "HD video from Hollywood" than
"commercial video". Hollywood already licenses SD movies for DRMless
broadcast via unscrambled DVB-T/C. E.g. Louis C.K. has been successful
at publishing commercial HD video without DRM.

> 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.

If users have to use a non-browser app to view DRM content, the DRM
content may cause lock-in to operating system that the app runs on but
not to a browser within the operating system. If Netflix worked in
browser A but not browser B on an operating system that allows
multiple browsers, this would unlevel the playing field for browser
competition by making it more likely that users stick to browser A for
all their browsing use due to Netflix working in browser A not in
browser B. Thus, it's not clear that it's good for the health of the
Web to have Netflix with DRM work on the Web platform augmented with a
lock-in-inducing vendor-specific black box. (Netflix without browser
lock-in on the Web platform would be totally awesome, of course.)

> The second sentence, no: we describe how to *communicate with* the
> protection system, but we do not describe a protection system.

Failing to describe the protection system means that your spec fails
to deliver the benefits of interoperability and level playing field
for competition that detailed Royalty-Free specs deliver when they
fully describe the system. That is to say that your proposal fails to
satisfy a major reason for being for W3C specs.

It seems to me that your proposal serves a different purpose of
standards: Lowering the R&D cost for proprietary systems that use an
off-the-shelf component as part of the system. (The off-the-shelf
component being a browser engine not including the DRM module.)

It's not clear to me that lowering the R&D cost of proprietary systems
without providing interoperability and a level playing field for
competition is good enough benefit for the W3C to spend time on stuff.

> DRM doesn't primarily derive the security it offers from being closed
> source:
...
> Of course it's not possible to make it impossible for protected content to
> be copied.

Why then are you proposing a system with a browser-side
vendor-dependent black box instead of proposing an API that allows a
site-supplied data block descrambling JavaScript function (arraybuffer
in, arraybuffer out) to hook in between the HTTP byte stream and the
media stack and implement whatever descrambling algorithm it likes as
a speedbump without the descrambling code being any more strongly
hidden from a user "adversary" than any other JS programs sent to
browsers?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 24 February 2012 08:18:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC