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

Re: Oppose DRM ! Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 25 Jan 2013 15:06:21 -0800
Message-ID: <CAAWBYDDMYE3BXXSsA8NOWZe9B5BYt0Lr4o5sCwNoPGnj+=syCw@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: David Singer <singer@apple.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
On Fri, Jan 25, 2013 at 2:31 PM, Glenn Adams <glenn@skynav.com> wrote:
> On Fri, Jan 25, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>  It is very likely, given the explicitly admitted low
>> chance of interoperable DRM standards, that there will be extended
>> incompatibilities between browsers on non-free OSes as well for a long
>> time.
> Perhaps, but that is not relevant.

I fail to see how it is irrelevant.

> On the other hand, EME provides
> mechanisms that improve interoperability that can eventually reduce use of
> non-interoperable DRM components. You appear to oppose EME because it
> doesn't remove all such interoperability issues at one blow.

The existing most common DRM mechanism on the web (Flash) is already
at least as interoperable as any DRM module hooked up through the EME
spec mechanisms will ever be.  Furthermore, it works today.

Let's take all the media distributors in this thread at their word for
a moment.  Let's pretend that they have nothing but the average
person's best interests at heart, and it really is true that those
nasty ol' pirates will happily bankrupt them if they ever ship video
unencrypted.  Can someone please explain how the stuff in the EME spec
is better than the existing DRM solutions on the web?  More
importantly, if we assume that there is some technical benefit, can
someone please attempt to justify how that benefit is sufficiently
large to outweigh the technical cost to implementors of permanently
adding this new code to the web platform, and to authors and users who
will have to bear through an extended period of bad interop, assuming
we ever do achieve interop and don't just settle into a no-one-wins
stalemate like we have with audio/video codecs?

We have rejected *awesome* ideas that have literally zero downsides
for authors and users before, solely because we don't think they are
*sufficiently* good to justify burdening the future with the
additional code weight.  This is *clearly* not in that category - it
is unarguably a mixed bag, and so the good must be correspondingly
greater.  So far, the actual justifications for the technology have
been *nowhere near* sufficient to make this argument, as far as I can
tell.  Everyone recognizes that DRM doesn't actually work, and no
matter what you do, the media will be available DRM-free on
filesharing networks soon after release (or quite often, before
official release).  This is *at most* a picket fence that some people
honor out of a sense out of respect.

We've done this sort of thing before - one of the justifications for
the WOFF1 format was that it wasn't TrueType, so if people downloaded
it from a website they couldn't put it straight into their fonts
folder and expect it to work.  However, *that was not the sole
benefit*.  WOFF1 also compressed better than TTF, and font size is an
important issue, so that was a valuable benefit.

So far as I can tell, there is no such valuable benefit here.  There's
only a threat - the threat that, if one browser defects and implements
the EME stuff, a bunch of media distributors will choose to only ship
videos with that DRM module, so no other browser will be able to play
them and they'll lose market share.  This isn't a benefit to anyone
except potentially the media distributors.

So, why are we even arguing about this again?

Received on Friday, 25 January 2013 23:07:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:21 UTC