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

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

Received on Tuesday, 22 January 2013 20:26:11 UTC