Re: [MEDIA_PIPELINE_TF] Common content security requirements

What if the browser provided APIs that would allow a DRM vendor to
override the functionality of the <video> element?

Today, if I put a URL pointing to a Smooth/PlayReady manifest into a
<video> element, the browser has no idea what to do.

If the right APIs were present, the browser could hand that off to the
appropriate plug-in (e.g. Silverlight) which would then handle the
decryption, etc. The <video> element would then just be a placeholder for
the rendering viewport that the plug-in would use.

This seems to be roughly what Apple does in Safari, by letting Quicktime
handle video playback for the <video> element. That's easy for Apple,
because they are both the OS and browser maker, and are basically
guaranteeing that baseline level of functionality. Other browser makers
like Mozilla and Chrome can't guarantee the availability of a suitable
playback or DRM engine and shouldn't have to, considering all the patent &
licensing issues that carries with it.

David Mays | sr. software architect | 15.217 | one comcast center |
philadelphia, pa. 19103 | 215.286.3395 w | 215.847.9631 m

On 9/1/11 10:06 AM, "Giuseppe Pascale" <> wrote:

>the pointed I tried to raise during the call is basically along the line
>of what Juhani wrote below.
>My question was indeed: do we really need to have a <video> element DRM
>aware? Or could be <video> be DRM agnostic in the same way as it is codec
>And more: if extensions are needed with the only purpose of communicating
>with a DRM agent running on the machine, can this be done simply with
>If a specific DRM require a specific <object> it will be up to another
>group (outside W3C) to either provide an implementation or a standard
>interface for such a plugin.
>On Wed, 31 Aug 2011 16:41:51 +0200, <> wrote:
>> Hi Bob,
>> You sent last week an e-mail on the Common content security
>>requirements to the HNTF. I assume that was targeted to MPTF reflector
>>instead, as the discussion points relate to the last week's MPTF telco.
>>There I was interested to give more comments on the Common content
>>security requirements as referred to in ISSUE [40] to ISSUE [43].
>>However, there was time to discuss shortly just on Req. 2.2.
>> My main points in the telco were that it would be beneficial to have
>>support for protected content with HTML5 but the most appropriate
>>solution requires careful thinking. I also commented that many of the
>>proposed Common content security requirements 2.x are seem to be
>>out-of-scope as requirements for W3C. More specific comments are in the
>>following (with [JHu]).
>> "This is a list of common content security technical requirements
>>derived from the related use-cases
>>   1.  General Web Delivery Requirements
>>      *   If Web users are to have access to a wide range of content,
>>the Web delivery platform must provide support for the property rights
>>of content owners."
>> [JHu]: The idea to have better support to protected content
>>availability through Web interface makes sense. Whether the requirement
>>1.1 is the exact formulation for this purpose should be discussed.
>>   1.  "User-agent Requirements
>>      *   The HTML5 user-agent needs to support one or more digital
>>rights management (DRM) systems[1]."
>> [JHu]: It is not in the W3C scope to define how many and which DRM
>>systems UA should support. UA may or may not support DRM systems.
>>      *   "If the user-agent doesn't have support for a DRM required by
>>the content it should be able to download an available module that
>>supports playback of content using that DRM."
>> [JHu]: Again this is out-of-scope for W3C (see the previous answer).
>>Ideally, and outside W3C scope, it would be nice to have downloadable or
>>swappable DRMs (when needed). However, the DRM SW module would need a
>>proper HW support in the device, where the DRM module would be
>>downloaded, to ensure the necessary security. In practice, there is no
>>working solution for a secure, downloadable DRM, that would apply
>>uniquely with several DRM systems (AFAIK).
>>      *   "The device platform may provide hardware-based root-of-trust
>>which should be available for use by the DRM module."
>> [JHu]: This is out-of-scope for W3C. In addition, this is not realistic
>>requirement because there is no generic HW-based root-of-trust (ROT).
>>The ROT is always DRM vendor or technology specific.
>>      *   "Web content and DRM modules should be able to determine the
>>level of trust of the device."
>> [JHu]: Requirements for DRM modules is out-of-scope for W3C. Besides
>>that the proposed requirement can't be guaranteed as that is DRM
>>technology specific.
>>             [JHu]: Overall, requirements 2.x are not in the scope of
>>W3C and should rather be removed. A suitable approach could be to have
>>DRM support in the form of 'plugin' in HTML5 something like according to
>>a proposal in
>> "HTML-intended DRM plugins should implement an interface that mimics
>>that of the video element. The scrambled media resource, located in an
>>embed element, should then be handled by the DRM plugin, which should
>>trigger an error event on the corresponding embed element if viewing of
>>the resource is not allowed."
>>   1.  "HTML5 Media Element Requirements
>>      *   Web content should use the video and audio element interfaces
>>to playback DRM protected content. All of the features that exist for
>>the video and audio element should be available when playing protected
>>content, e.g. have child track elements, be assignable to a media
>>controller object.
>>      *   The HTML media resource selection algorithm should include
>>resource selection based on user agent DRM support.
>>      *   Web content should be able to determine certain DRM-related
>>playback events and errors.
>>      *   Web content should be able to determine which DRMs are
>>supported by the user-agent.
>>      *   The DRM solution needs to work for content accessed directly
>>by a URL or via a URL to a media presentation description (a.k.a.
>>manifest file)."
>> [JHu]: My understanding is that this set of requirements target to
>>define the specific parameters to enable the protected content
>>consumption and control through the Web interface. The role and exact
>>formulation of these kind of requirements may require further discussion.
>> -Juhani
>Giuseppe Pascale
>TV & Connected Devices
>Opera Software - Sweden

Received on Thursday, 1 September 2011 14:38:43 UTC