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

Re: DRM in HTML5 A Betrayal of Public Trust

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 13 Jun 2013 17:37:35 -0700
Message-ID: <CAEnTvdBux2BH385XPKUEdA_xDDgaqz6NmDAdbTnoQspKcFHMpQ@mail.gmail.com>
To: Kornel Lesiński <kornel@geekhood.net>
Cc: public-html@w3.org
On Thu, Jun 13, 2013 at 4:58 PM, Kornel Lesiński <kornel@geekhood.net>wrote:

> >>
> >> EME will still require users to have a proprietary plugin (CDM) to
> access your service.
> >
> > CDMs are not plugins. I'm not sure how many times we have to repeat
> > that before people will stop propagating this myth.
> My interpretation of the EME spec is that CDMs are going to be third party
> code plugged into the browser somehow.
> If it's not the intention to let CDMs be "browser add-on" then perhaps
> section 1.2.1 should be removed or changed to say so normatively without
> "may or may not" loophole.

We can't control browser implementation choices. But the intended direction
is certainly that there are a limited number of CDMs, that they are not
user-installable and that browsers make the choice to integrate carefully
with knowledge of what they are integrating with.

> > Yes, they share some features with plugins (notably some if not all
> > will be proprietary code), but there are many differences, not least
> > that no browsers have any plans to make them user-installable, users
> > will have a choice - through their choice of browser
> In that aspect Flash on ChromeOS isn't any different than Netflix CDM on
> ChromeOS. Nothing to install, baked into the browser, not replaceable.
> If browser vendors made a deal with Adobe and/or Microsoft to link
> Flash/Silverlight binary into browsers and make them available by default
> and remove ability to replace them or install other plugins - would you say
> Flash and Silverlight are not plugins any more?

Many people would. The term "plugin" is very much associated with the idea
of a separate download and install. This is at least what causes a major
drop-off in interest - when the user gets to the "download" dialog.

> I would still call them plugins, because it doesn't remove the key
> characteristic: browser vendors having to ship somebody else's black box
> they cannot replace. CDMs have exactly that problem.

So, then, the issue is that when you use the term "plugin" it means
something different to many people from what it means to you.

> > - and browsers will have some control over what the CDMs can do.
> I'm concerned that DMCA and lack of open spec for CDM API gives CDM
> vendors very strong leverage over browser vendors that NPAPI plugins didn't
> have. Do you plan to address that problem somehow?

The idea is that services will work with multiple different CDMs. So the
browser implementor has a choice of CDMs - they do not need to integrate
with many in order to gave good coverage in terms of services. This choice
will reduce the CDM vendor leverage. But, as always, additional ideas are


> --
> regards, Kornel
Received on Friday, 14 June 2013 00:38:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:33 UTC