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: Mark Watson <watsonm@netflix.com>
Date: Fri, 25 Jan 2013 18:40:35 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: David Singer <singer@apple.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
Message-ID: <F1B27401-C8F4-43AA-A486-5726A6755E74@netflix.com>

On Jan 25, 2013, at 10:25 AM, Tab Atkins Jr. wrote:

> On Fri, Jan 25, 2013 at 10:00 AM, David Singer <singer@apple.com> wrote:
>> On Jan 25, 2013, at 18:57 , "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>> On Fri, Jan 25, 2013 at 6:25 AM, David Singer <singer@apple.com> wrote:
>>>> On Jan 25, 2013, at 14:38 , Andreas Kuckartz <A.Kuckartz@ping.de> wrote:
>>>>> Ian Fette (イアンフェッティ):
>>>>>> Also, why do people insist that drm is incompatible with foss? Yes, today's
>>>>>> implementations are largely security through obscurity but there is nothing
>>>>>> that fundamentally prevents an open source drm stack if one wished to make
>>>>>> the investment. Create a hardware tpm and publish the specs, build some
>>>>>> form of attestation on top of it, etc. Clearly nontrivial but not
>>>>>> fundamentally impossible.
>>>>> 
>>>>> I consider it impossible to do that while keeping the software open
>>>>> until the opposite is proven.
>>>> 
>>>> There are uses of encrypted media which are compatible with foss.  For example, various people have realized that there are cases where media needs some amount of protection in transit, but not much, if any, protection once it reaches the end system.  DRM systems are typically quite expensive for this, as they include tamper-proofing, and TLS is expensive as it's dynamically applied (it's cheaper to pre-compute the encryption).  My read of the media extensions is that they are quite suitable to this scenario.
>>> 
>>> I don't understand.
>> 
>> I'm sorry, I thought I explained that the case is for pre-computed protection in-transit (up to the moment of play, possibly).  Whether that's a minority reason to use this, I would not care to say.  Yes, you go on to discuss classic full DRM, which I don't.
> 
> "Up to the moment of play" is incompatible with FOSS, to the best of
> my knowledge.  If it needs to stay encrypted after hitting the
> destination computer, you're out of luck.

Tab,

It's certainly incompatible with the "Anti-Tivoization" clause of GPLv3, in which the software license requires that the end user of the software must be able to modify it and still have it work.

It's not incompatible with "Open Source" per se.

As I've said before, GPLv3 licensors are just as entitled to place these restrictions on how their hard work is used as video content licensors are to place restrictions on the uses made of their work. The fact that these two groups of people have made mutually incompatible license choices is just the way things are and the fact that they are free to make those choices is a good thing. It's not a reason to object to this work.

…Mark

> 
> ~TJ
> 
> 

Received on Friday, 25 January 2013 18:41:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 January 2013 18:41:04 GMT