Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Feb 27, 2012, at 2:35 AM, Henri Sivonen wrote:

> On Fri, Feb 24, 2012 at 9:56 PM, Mark Watson <watsonm@netflix.com> wrote:
>> I wanted to response to one comment you made in particular yesterday:
> 
> I'd also be very interested in a response to my question about why you
> aren't proposing content descrambling using a site-supplied JS program
> running in the general purpose interoperable JS execution environment
> that browsers provide (without putting any part of the browser
> implementation inside a Trusted Computing Base). That is, I'd be
> interested in learning where the requirement for a particular level of
> obfuscation comes from and what the required level of obfuscation is.

My understanding is that if the decrypted data were available in Javascript then this would not meet many content providers requirements.

Also, Javascript decryption would likely be too computationally expensive for most implementations of the web platform (counting by executables ;-), which are running on constrained devices like TVs, Set Top Boxes etc.

> 
> In general, it would make evaluating the proposal easier if the
> requirements the proposal seeks to address were clearly stated.

We can add some more material on this. At a high level, the requirement is to provide a standard framework for content protection in HTML that in particular enables application mediation of the protection-system-specific message exchanges. This is an architectural change, enabling authentication and authorization to be owned by the service and implemented in the normal protection-system-independent ways.

It is required to support multiple content protection systems that may provide different levels of protection.

It's not part of the proposed scope to define a particular system, other than clearkey, so the actual requirements of content providers in terms of robustness and 'level of obfuscation' aren't in scope.

> 
>> On Feb 24, 2012, at 12:17 AM, Henri Sivonen wrote:
>>> If users have to use a non-browser app to view DRM content, the DRM
>>> content may cause lock-in to operating system that the app runs on but
>>> not to a browser within the operating system. If Netflix worked in
>>> browser A but not browser B on an operating system that allows
>>> multiple browsers, this would unlevel the playing field for browser
>>> competition by making it more likely that users stick to browser A for
>>> all their browsing use due to Netflix working in browser A not in
>>> browser B. Thus, it's not clear that it's good for the health of the
>>> Web to have Netflix with DRM work on the Web platform augmented with a
>>> lock-in-inducing vendor-specific black box. (Netflix without browser
>>> lock-in on the Web platform would be totally awesome, of course.)
>> 
>> Netflix, with DRM, is supported today on Firefox and will continue to be.
> 
> As Boris pointed out, the concern isn't only about the case where B = Firefox.

Someone launching a new browser today would need to ensure that plugins like Flash and Silverlight were supported in order to support many existing commercial video services, including Netflix. That decision is not even in their hands, since Adobe and Microsoft respectively would need to take a decision to support the new browser.

With our proposal, the new browser would need instead to support one or more Content Decryption Modules. This is a much simpler task over which the new browser developer has greater control and more options. 

> 
> (As the B = Firefox case, I believe it's currently the case the
> Netflix doesn't work in Firefox as shipped by Mozilla without a
> third-party black box for which Mozilla can't ship a compatible
> substitute on its own initiative on platforms of its choice.

Right. They would have more options if all that's needed is a suitable CDM.

> I can't
> empirically verify this belief, because Netflix declines to provide
> service to people who reside in the territory where I reside.)

Apologies that we haven't yet reached you. The service is available in about 50 countries now, I believe, and we hope this will grow.

Supporting a new country is not just a question of removing geo-filters: we need to buy content for each new country, do localization work, ensure device availability etc. One of the reasons for this proposal is to make it easier to support the service on more devices, which would lower the cost of entering new countries and mean we could get to you sooner :-) (ok, I'll admit that the content costs are the big ones, but still we'd like HTML to be a route to a global platform for video services on devices like TVs, Set Top Boxes, Blu-Ray Players, Tablets, Phones etc.)

...Mark

> 
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>

Received on Monday, 27 February 2012 21:55:56 UTC