Re: [MEDIA_PIPELINE_TF] Common content security requirements

On Sep 1, 2011, at 4:01 PM, Mo McRoberts wrote:

> 
> On 1 Sep 2011, at 23:03, Mark Watson wrote:
> 
>> Whilst I understand you can design applications where the script has access to detailed content metadata such as codecs, profiles etc. there are also use-cases where the page has just a URL, perhaps for an adaptive streaming manifest describing multiple alternative encodings and in this case the page is not aware of all the various permutations of encoding parameters in the presentation.
> 
> Would you really generate a single adaptive streaming manifest containing both multiple bitrates *and* multiple formats and DRM wrappers? That seems, not to put too fine a point on it, crazy. And, if memory serves, the source list on <video> is ordered (though that might not be specified)?

Whether the codec and other choices are provided in HTML markup or in an adaptive streaming manifest is not a major difference, so I am not sure how one could be "crazy" and the other not ? Could you elaborate ?

At least with MPEG DASH, the idea has been that the adaptive streaming part might find application in multiple environments, not just HTML, so then functionality which is common to all such environments (such as codec choices) is handled within the manifest. This simplifies things for the UI (script) layer, which, after all, should not really care about technical details like codecs etc.

> 
> But, in any case, if "let the application pick and choose from amongst the available resources [some of which are within a manifest] according to some custom heuristic” is a requirement, then DRM is just a sideshow: such a mechanism — were it to exist — should be a generic resource-selection hook, not a “pick a DRM scheme” hook.

The definitive information about what is in the file (codecs, protection schemes etc.) is in the file itself. The definitive information about platform capabilities is known by the platform - so it makes sense to calculate the intersection of these in the platform. What remains is to apply user and service preferences to that intersection, which does require script interaction. For codecs it's sufficient to provide a priority order (supported in both HTML and DASH manifests) and maybe that is sufficient for protection schemes too.

Changes would be required to support that in the HTML markup case. In the adaptive streaming case, it's possible that a protection scheme is supported by both the file and the platform, but not by the service (script), so a different interaction is required in that case.

A lesser point is that the reasons people do not and probably will not soon support switching from one codec to another during playback are primarily implementation reasons: there's no reason to embed that implementation restriction into the architecture.

> 
> However, I would wonder whether it'd be a damned sight easier to make the applications smarter with respect to resource availability rather than waiting for new APIs to trickle down :)

New APIs are required in any case. Regarding canPlayType, I am not sure that polling every possible combination of container/codec/protection scheme is a good design. Plus there are ambiguities: if canPlayType returns true for "video/mp4; codecs='mvc1'" then do I know the player supports MVC ? or just that it supports the mp4 container ?

And it is not clear at all that the script layer should have to be bothered with metadata regarding encoding formats, codecs, containers etc.

> 
>>> It's difficult to say conclusively, because there's a distinct lack of concrete descriptions of scenarios, however it does seem that the only point at which it MIGHT become worthwhile exposing DRM scheme detail to the Javascript API in a more granular fashion is if you wanted the script itself to take an active role in obtaining and relaying authorisation keys… 
>> 
>> Yes, that's exactly the way forward I'm advocating: move responsibility for authentication and authorization to the application, where it belongs.
> 
> That's a pretty strong statement, and suggests an expectation of DRM schemes being developed which suffer from leaky abstractions… though that's not a foregone conclusion.

I don't understand why you think my statement suggests this, or even what you mean by "leaky abstractions". Can you explain ?

> 
> There are two kinds of scenarios, I guess:
> 
> Sony decides they're going to support Ultraviolet DRM in the browser of their Internet-connected Blu-Ray players. In their browser, they add support for a media type which gets handed off to the Ultraviolet runtime to deal with. If necessary, the UV implementation can present a login UI tailored to TV screens. Additional application-level control would almost certainly provide an inferior experience to the user.
> 
> Google enters into a partnership with Adobe to support Flash DRM in Chrome within <video>. For whatever reason, this requires an authentication key to be supplied and the site author has decided not to include it in the RTMPE video source URLs. When this happens the Flash DRM implementation fires a specific event on the video object which can be listened for if needed. The site author knows that event will be fired (because they know the specifics of Flash DRM - what with having decided to use it) and what to do when it is.
> 
> What needs to sit in the middle? Well, nothing, really. Whether it's through a plugin mechanism or rolled into the browser, a DRM handler can — in principle — do whatever the hell it likes in Javascript-land. It's an area where the web developer will necessarily HAVE to know about nuances of the particular codec because they chose to use it in the first place, and so there's a Chinese Wall between the application and the DRM runtime. Attempting to standardise and abstract that (as opposed to just properly documenting what the runtime does and requires) likely wouldn't achieve very much for anybody, really.

The scenario I outlined at the Berlin workshop was very different from either of the above. In summary, if a platform supports some protection scheme and is asked to play a file which can be played with that scheme then we can assume that the protection scheme component on the platform needs to communicate with a counterpart that will provide the key, using the protection scheme's key exchange protocol.

My suggestion is that this key exchange should be transported via the application. That does not imply that the script needs to understand the protection scheme's key exchange, or that it knows anything more about the protection scheme than that the service supports it. The script is responsible for service-specific authentication and authorization and if these steps are successful then opaque key exchange messages can be exchanged between the protection scheme's client component and its service-side counterpart though this secure channel. (This does imply availability of suitable JS crypto/identity APIs, which is being discussed in the W3C identity-in-the-browser workshops.)

This avoids the need for services to stand up multiple front-end servers for different protection schemes, each supporting their own authn/authz, with duplication of service-specific business logic in each. Architecturally it moves responsibility for well understood non-IPR-laden functions (authn, authz) to the service - where they belong - out of the protection scheme 'black box'.

Transport, containers, authentication, authorization, encryption, codecs should all be protection-scheme independent.

> 
> M.
> 
> PS. With apologies to Sony and Google.
> 
>

Received on Saturday, 3 September 2011 03:02:24 UTC