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: Mat Marquis <mat@matmarquis.com>
Date: Fri, 25 Jan 2013 17:18:05 -0500
Cc: "public-html-admin@w3.org" <public-html-admin@w3.org>
Message-Id: <118735FB-511F-47A2-8BC3-CE6EF1C16388@matmarquis.com>
To: David Singer <singer@apple.com>

On Jan 25, at 4:59 PM, David Singer wrote:

> 
> On Jan 25, 2013, at 19:52 , "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
>> On Fri, Jan 25, 2013 at 10:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>>> On Jan 25, 2013, at 10:25 AM, Tab Atkins Jr. wrote:
>>>> "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.
>>> 
>>> 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.
>> 
>> I disagree with you on moral grounds, but that's neither here nor
>> there.  I'm talking *technically* incompatible.  If you require the
>> file to be encrypted from the user you are sending it to, then you
>> require a secret that the user doesn't know.  
> 
> That's your assumption; presumably based on the assumption that everyone's like you. Not everyone is willing to modify the software they run, especially when they know that doing violates an agreement that they have made. It's not technically incompatible if, as I say, your primary goal is to ensure that the content is protected in transit and only transiently, and incompletely, in the clear.
> 
> This level of protection is, in analogy, like a fence around your garden.  No, it does not keep out the determined -- but those who cross it have to take some trouble, and they know full well that they have crossed it.  And maybe the person they agreed with will find out that the agreement has been broken, too.

That being the case: it seems to me that this would mean saddling the web platform with additional technical overhead, potential interoperability issues, and the possibility of “Trusted Computing” situations while doing very little to prevent the circulation of copyrighted material. I don’t assume the average non-technical user will be attempting to hop the “garden fence” themselves—they’ll just go to a website where more experienced fence-hoppers have done so for them, then download whatever they were looking to download in the first place. Causing the distributors of copyrighted material a slight inconvenience hardly seems worth the potential costs outlined elsewhere in this thread.

I oppose this extension specification going to FPWD.
Received on Friday, 25 January 2013 22:18:29 GMT

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