W3C home > Mailing lists > Public > public-html-media@w3.org > April 2013

Re: Chromebook DRM specification

From: Florian Bösch <pyalot@gmail.com>
Date: Tue, 16 Apr 2013 19:27:23 +0200
Message-ID: <CAOK8ODiQjJFtRhpPhR=bvaAaoMs5gT6gLCuU-3-+Zw5b9md0uA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, "Mays, David" <David_Mays@comcast.com>, David Dorwin <ddorwin@google.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>, "Philippe Le Hegaret (plh@w3.org)" <plh@w3.org>, "Michael(tm) Smith (mike@w3.org)" <mike@w3.org>
In other words, it is a standard drafted, steered and promoted by google,
implemented solely by google, for netflix, and nobody else. In the future
we are looking forward to repeat this sorry state of affairs with Microsoft
and Amazon, Apple and Hulu and so forth.

And somehow, magically, this is compatible to the HTML-WG charter, in

On Tue, Apr 16, 2013 at 7:22 PM, Mark Watson <watsonm@netflix.com> wrote:

> On Tue, Apr 16, 2013 at 10:10 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> On Tue, Apr 16, 2013 at 7:01 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> We don't have any requirement that all browsers/devices implement the
>>> same DRM. This isn't like video codecs. As long as they all support the
>>> same encryption format (for example ISO Common Encryption as described in
>>> the specification or WebM encryption) we can deliver the same files to all
>>> devices with the same interaction model (as defined by the specification).
>>> There's some per-DRM back end work, but this is manageable and a great
>>> improvement on what we have today.
>> Aquiring a license from every DRM vendor is not feasible for web authors.
>> Contacting Widevine alone is also not feasible to not being contactable.
>> Hence HTML-DRM excludes web authors.
> What you're saying is that using DRM for your content is difficult. But no
> authors are required to use DRM by this specification and I believe many
> people do not wish to do so. Those authors who wish to use DRM, but aren't
> in a position to pay for DRM licenses or implement back-end services with
> multiple DRM servers are indeed excluded, *by the existing DRM landscape*,
> not by anything we are proposing. As Glenn and I have repeatedly pointed
> out, the Encrypted Media Extensions are intended to support multiple DRMs
> and don't define a specific "HTML-DRM".
Received on Tuesday, 16 April 2013 17:27:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:35 UTC