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

I'll state up front that I share some of Tab's distaste for DRM. I do think
that it is a technology whose lifespan is hopefully limited; as we saw with
audio I hope we will one day see video being most commonly distributed
without DRM. However, if and when this change comes about, it will come on
its own schedule and not because of this group, and I do not think it is
wise for us to leave the web crippled (compared to native platforms) in the
meanwhile. The web, especially on mobile (and tablets, and ARM laptops)
does not necessarily have the "flash fallback" that tab describes, and so
this is a problem worth us solving.

Multiple vendors are implementing and have expressed interest in having
that standardization work take place here. Google are implementing and as
an organization have invested a great deal here, Microsoft have expressed
their support, there's clear demand from customers of the web (in the sense
of content providers wishing to reach their customers, as well as end users
wishing to obtain the content the providers are trying to make accessible
given the contractual constraints under which they operate). I don't think
we're going to have a problem getting the required multiple independent
implementations.

Is this going to encourage what Hixie calls "proprietary plugins"? I could
be petty and debate semantics, but ultimately I think that it's close
enough to say "yes, one will not be able to download the source of one of
these modules, tweak it, compile it, and have it work in the most likely
ecosystem to emerge from this effort." While unfortunate, that's hardly a
first (see the <object> and <applet> tags of days past). I can only hope
that while it will still leave us with what Hixie calls "proprietary
plugins", they will be smaller in nature, and let us leverage more of the
work we've done in HTML and in browsers as opposed to shelling out the
entire end-to-end stack to a plugin. If we are not to be rid of
"proprietary plugins" let us at least have smaller, more focused
proprietary plugins with a smaller surface area.

We can either sit in our admittedly morally-comfortable sandbox as we watch
our relevance fade (either because the web loses to a more capable native
platform, or because this work and implementation proceed outside of W3C),
or we can hold our noses a bit and try to ensure that if this is something
we have to do, we at least do it in the best way possible. We can ensure
that as much as possible is interoperable. We can ensure that users of the
mobile web and of different architectures have a better chance of accessing
the full amount of content available on the web. I do not believe this is
"antithetical to (W3C's) core tenets".

I personally support advancing this to FPWD, and believe that we need to
not let our hopes for a perfect world prevent us from making any progress
and finding ourselves in a worse place with even less influence over the
direction.

-Ian

On Tue, Jan 22, 2013 at 12:25 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Jan 22, 2013 at 10:03 AM, Paul Cotton <Paul.Cotton@microsoft.com>
> wrote:
> > This is a Call for Consensus (CfC) to publish as a First Public Working
> Draft (FPWD) the following Encrypted Media Extensions document:
> >
> >
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
> >
> > Silence will be taken to mean there is no objection, but positive
> responses are encouraged. If there are no objections by Wednesday January
> 30, this resolution will carry.
> >
> > Considerations to note:
> >
> > - As a First Public Working Draft, this publication will trigger patent
> policy review.
> >
> > - As a Working Draft publication, the document does not need not be
> complete, to meet all technical requirements, or to have consensus on the
> contents.
>
> I object to the publication of this draft, for reasons stated clearly
> in previous threads about this spec.
>
> 1. The spec is technically incomplete, relying on other technologies
> which have no expectation of being openly and freely specified (and,
> in fact, *can't be*, if they are to maintain the security aspects they
> purport to have).  While it is true that we have a few similar things
> already in the web platform, such as <video> and the codec problem,
> it's widely and correctly considered a failure of the standardization
> process that we couldn't specify an openly-specified and
> freely-available codec as required support.  We should not seek to
> emulate this failure scenario.
>
> 2.  Because the spec relies on technologies that will never be openly
> specified, it's guaranteed to be an interop failure.  Licensing will
> be *required* at some point in the toolchain, which goes against the
> spirit of our royalty-free license on our specs.  A user running a
> free browser such as FF on a free OS such as Linux will be SOL without
> illegal unlicensed decryption engines.
>
> 3. We know from over a decade of experience that license servers have
> a very finite lifetime.  Corporations die all the time, and even when
> they continue, license servers are usually only maintained until they
> become insufficiently profitable.  Given that this specification
> relies on licensing servers for all the encryption schemes that we
> realistically expect to be used, it is de facto blessing the creation
> of time-limited content that will be unusable in the relatively near
> future.  This counters the philosophy of open specifications, which is
> meant to ensure that content produced today will be consumable in the
> future.  (As an example, I'm right now playing a new copy of a recent
> and moderately successful video game which has already had its license
> servers shut off, which means I am forever locked out of some content
> that was put behind DRM as a way of punishing used-game sales.)
>
> 4.  We know from over a decade of experience and basic mathematical
> and security-based reasoning that this kind of encryption (DRM) is
> *fundamentally unsound*.  There has never been a secure form of DRM;
> the DRM currently in use has either simply not been broken *yet*, or
> is broken but is considered still worthwhile due to the unpolished
> nature of the removal tools making them uncommon among the average
> consumer.  The only form of secure DRM possible involves the licensing
> agent actively owning the user's computer and preventing certain types
> of computations from occurring, which is contrary to the philosophies
> behind the open web.
>
> This is an incomplete spec, specifying a fundamentally broken
> technology, which is intended to be used in ways that are bad for the
> open web and the philosophies underlying it.  Many in the W3C regard
> this as "inevitable" and so do not fight it, but that does not make it
> good.  This organization should be ashamed for sponsoring and
> supporting a specification so antithetical to its core tenets.
>
> ~TJ
>
>