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

I object to publication as well.  I think Tab's email cover my objections 
pretty much completely.

On Tue, 22 Jan 2013, Tab Atkins Jr. 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
>
>

Received on Tuesday, 22 January 2013 20:33:52 UTC