Re: [EME] Key Release

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.

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

[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> 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> wrote:
>
>>
>>
>> On Tue, Jun 19, 2012 at 8:52 AM, Mark Watson <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
>>>
>>>
>>
>