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

On Feb 2, 2013, at 6:33 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
________________________________________
From: Boris Zbarsky [bzbarsky@MIT.EDU<mailto:bzbarsky@MIT.EDU>]
Sent: Saturday, February 02, 2013 4:44 PM
To: public-html-admin@w3.org<mailto: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.

Mark,

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
Linux.

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.

[steele] You are correct Mark. Flash on Linux (and more importantly Access on Linux) covers a number of different Linux-based platforms: open desktops, Android phones/tablets, set top boxes, televisions, etc. The better we are able to validate a particular platform, the more likely higher value content is to be allowed to playback on those platforms by content providers.


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.

-Boris