Re: [EME] Key Release

On Jul 20, 2012, at 9:13 AM, David Dorwin wrote:

Now that we've chosen an object oriented session approach [1], we should revisit the idea of key releases. Presumably, MediaKeySession objects would be obtained from the MediaKeys object, which can be instantiated independent of a media element (solving the "dummy" HTMLMediaElement case).

However, there are some implementation and use issues to address before we decide on a specific API. For example, assuming key release is used to support business logic, it is probably important that the key releases be reported as soon as playback stops and/or the key is no longer in use. This might be less reliable in a native browser and/or computer environment than in existing systems. Potentially problematic scenarios include:

  *   User navigates away from the media page (i.e. from the address bar) while the media is playing.
  *   User closes a tab or browser window while the media is playing.
  *   User closes the lid on a laptop or otherwise suspend the system while the media is playing.

In the first two scenarios, the application would need to detect that the page is being unloaded, request a key release, receive it, and send it to the server (i.e. via XHR). Is this guaranteed to work by the HTML spec or in common implementations? I think this would at least require a method to synchronously request released session(s) whereas the rest of the API is asynchronous.

Yes, that is my understanding. We'll need a synchronous message to get the key releases.


In the third scenario, I assume the application won't even be notified.

And there can be other scenarios, such as loss of power in non-battery powered devices.

Generally, the CDM is expected to keep all the key release information in some persistent store and report all the unacknowledged ones next time the application asks.

So for these cases where it cannot be reported at the time playback actually stops, it will instead be available to be reported before playback next starts.

So for example the MediaKeys object may have a method to retrieve one or more 'old' sessions (which would be scoped by origin) and the MediaKeySession objects then support retrieval and acknowledgement of the key release message.

If we did not have the synchronous requirement, I would say the existing keymessage event and addKey method (which is still asking to be renamed, IMO, though I don't have a good suggestion), could be used. The key release message would be triggered by the close() method. If you retrieve an 'old' MediaKeySession it sends this right away. We could do that anyway, since it's consistent, and then also have the possibility for the close() method to return the message synchronously.

…Mark


[1] http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html

On Fri, Jun 22, 2012 at 3:33 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:
I corrected my last sentence below to:
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470, which is tracking when applications can call other methods, specifically generateKeyRequest().

On Fri, Jun 22, 2012 at 3:30 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:


On Tue, Jun 19, 2012 at 8:52 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jun 11, 2012, at 11:57 PM, David Dorwin wrote:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

The Key Release portion (http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-release) of the proposal hasn't received a lot of feedback, so I'd like to start a discussion about it.

Section 4.1 gives a good overview of the problem. Briefly, the goal is the provide the application with secure proof that a key is no longer present on the client ("released"). The application must also be able to ACK proofs. One particular thing to note is that proofs are not related to any particular media element. In addition, the current API proposal does not associate key release with HTMLMediaElement or any other object.

Some possible topics for discussion:
 * Multiple KeyReleaseManagers could be created, but they would all represent the same data. How might we make KeyReleaseManager global or a singleton?

I would like to better understand what is the "normal" way to do this ? Should this be window.mediakeyreleasemanager ? What are the issues with that ?

 * While not related to HTMLMediaElement from an API point of view, key release would need to be tightly integrated with the implementation underlying the rest of the proposal, which is related to HTMLMediaElement.
   - What is the impact on implementations?
   - How might we more closely associate key release with HTMLMediaElement and/or the rest of the EME implementation?

If it makes a significant difference for implementations then this could be dealt with using methods on HTMLMediaElement, with the consequence that you might need to create a "dummy" HTMLMediaElement to get access to the proof of key release messages.

I think this is worth investigating. One thing we will have to address is ensuring that the media element implementation can be sufficiently initialized in the "dummy" case. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470, which is tracking when applications can call other methods, specifically generateKeyRequest().

 * How might representing sessions as objects (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613) affect the design?

I think it makes it clearer, since the "proof of key release" messages are created (and stored in the CDM) exactly when a  "session" is destroyed. In fact they become "proof of session destruction" instead.

…Mark