W3C home > Mailing lists > Public > public-html-admin@w3.org > February 2013

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

From: Mark Watson <watsonm@netflix.com>
Date: Sun, 3 Feb 2013 02:33:03 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-html-admin@w3.org" <public-html-admin@w3.org>
Message-ID: <438CCE43DFE22A4CBDBD3FDF65D8B20F059F514F@exmb106.corp.netflix.com>

From: Boris Zbarsky [bzbarsky@MIT.EDU]
Sent: Saturday, February 02, 2013 4:44 PM
To: public-html-admin@w3.org
Subject: Re: CfC: to publish Encrypted Media Extensions specification as a    First Public Working Draft (FPWD)

On 2/2/13 6:54 PM, Mark Watson wrote:
> MW> Regarding "licensors preventing deployment on desktop Linux operating systems", as I've argued before, one could view the "licensors" in this statement as being *either* of the content licensors *or* the Open Source software licensors. There is no technical reason why desktop Linux distros couldn't ship with a user-unmodifiable CDM component - it's the choice of the software licensors that prevents this.


As Henri pointed out, there is in fact a user-unmodifiable Flash on
Linux.  And yet "licensors" who are fine with their content being shown
via Flash on Windows or Mac are not OK with it being shown via Flash on

MW> I'm not that familiar with Flash specifically, but Flash-on-Linux may be different - in ways content providers care about - from Flash-on-Windows/Mac. Since DRM is all about the tools, time and expertise needed to obtain the keys, encoded or decoded content, then it's an analysis of the whole stack that is needed to determine whether a given set of protection requirements are met, or not.

MW> What I am talking about above is the "anti-tivoization" clause in some FOSS licenses which explicitly forbids non-user-modifiable components.

MW> What is much more realistic than a completely FOSS DRM implementation is the availability of APIs to access DRM components which are already part of a platform. No system is completely "free open source". Unless you have you own chip designs and fabs there is proprietary technology involved somewhere. The question is exposing capabilities on the boundary between the open and closed parts of the system in a way that is independent of the proprietary technologies used below-the-line.

MW> The problem of DRM-unavailability-on-Linux can't be solved by W3C. This FPWD doesn't make things worse there. IMO, creating a uniform high-level API that can be reflected down into lower layers of the system moves things forward, not backward.

I'm having a hard time reconciling your theoretical argument (which on
its own is plausible) with that experimental data point.  I welcome any
input that would help with said reconciliation.

Received on Sunday, 3 February 2013 02:33:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:32 UTC