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

On Feb 21, 2012, at 4:21 PM, Chris Pearce wrote:

> On 22/02/2012 12:16 p.m., Adrian Bateman wrote:
>> Many content providers and application developers have said they can't use<audio>
>> and<video>  because HTML lacks robust content protection.
> 
> We hear the same feedback. Can you highlight how robust content protection can be implemented in an open source webrowser? Specifically, since the decoded video frames are stored in memory (as are audio samples) so that they can participate in the HTML rendering pipeline, how do you guard against an open source web browser simply being patched to write the frames/samples to disk to enable (presumably illegal) redistribution of the protected content? Or is it not required to guard against that case?
> 

Hi Chris,

Firstly, requirements around decoded frames sometimes differ from those around encoded frames which differ again from those around decryption keys. That is to say that there remains some utility in mechanisms which offer strong protection for the keys and decrypted, encoded, content, but lesser protection for the decoded frames.

Secondly, there exist many devices with content protection mechanisms of various sorts baked into their firmware/hardware. Open source software could make use of such capabilities in just the same way as it makes use of other hardware capabilities, such a graphics capabilities exposed through OpenGL. The proposal explains how software with access to such capabilities can expose that with an API in HTML. If my understanding is correct, it's not unknown for open source products to make use of or even ship with closed source components, such as drivers, for access to platform or device capabilities. There is of course much work to do to standardize the platform APIs that might be used to access such capabilities.

Thirdly, in the case of content where it is necessary to strongly protect the decoded frames, then obviously these frames cannot participate in open source software compositing in main memory. One can easily imagine, though, how such compositing could be done within the protected media pipelines of devices that support such content. I do expect, though, that there will exist interim solutions where frames routed through a protected media pipeline are simply rendered above, or below, the remainder of the HTML content.

...Mark

> 
> Thanks,
> Chris Pearce.
> 
> 
> 
>> Without this functionality,
>> they cannot move their apps to the web platform. Many consumer electronics are taking
>> advantage of HTML for both video playback and user interfaces, yet their content
>> protection solutions are typically tied to the device. We believe that working
>> towards a common solution will reduce fragmentation between all HTML platforms.
>> 
>> This has been raised in the Web&  TV Interest Group [1] and mentioned in their
>> feedback [2]. We believe this extension specification supports the counter proposal [3]
>> for ISSUE-179 [4]. It demonstrates how to provide additional functionality to the
>> HTML5 media element without requiring a generic mechanism like<param>.
>> 
>> Best regards,
>> 
>> David Dorwin, Google
>> Adrian Bateman, Microsoft
>> Mark Watson, Netflix
>> 
>> [1] http://www.w3.org/2011/webtv/wiki/MPTF#Content_Protection
>> [2] http://lists.w3.org/Archives/Public/public-html/2011Dec/0120.html
>> [2] http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change
>> [3] http://www.w3.org/html/wg/tracker/issues/179
>> 
>> On Wednesday, January 11, 2012 11:40 PM, Maciej Stachowiak wrote:
>>> '{audio,video} require param child (or equivalent)'
>>> The current status for this issue:
>>> 
>>> http://www.w3.org/html/wg/tracker/issues/179
>>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-179
>>> 
>>> So far, we two one Change Proposals submitted:
>>> 
>>> http://www.w3.org/html/wg/wiki/ChangeProposals/av_param
>>> http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change
>>> 
>>> At this time the Chairs would also like to solicit additional Change
>>> Proposals, in case anyone would like to advocate the status quo or a
>>> different change than the specific ones in the existing Change Proposals.
>>> 
>>> If no counter-proposals or alternate proposals are received by February 11th,
>>> 2012, we proceed to evaluate the change proposals that we have received to
>>> date.
>>> 
>>> Regards,
>>> Maciej
>>> 
>> 
>> 
>> 
> 
>

Received on Wednesday, 22 February 2012 00:50:02 UTC