Re: [EME] Key Release

On Tue, Jul 10, 2012 at 5:53 AM, David Dorwin <ddorwin@google.com> wrote:

> On Tue, Jun 26, 2012 at 6:36 AM, Yang Sun <sun.yang.nj@gmail.com> wrote:
>
>> So you mean that we can not generate key before we download some part of
>> the content?
>> I have thought that we must generate key before download the content.
>> correct me?
>>
>
> The current requirement (in v0.1) is that loading must have started,
> meaning the source must have been selected. This doesn't mean the content
> must have been downloaded yet. We're not depending on anything in the
> content.
>

Yes, I guess at this time, the initialization data is available to the UA,
but the meta data or the content itself are not downloaded to the UA,
right? And at this time after the needKey event is fired, the
generateKeyRequest can be called.


>
>> Can we force the media object to be created before we download the
>> content, so that we can call the method.
>>
>
> This would be a new requirement on implementations of the media element.
>

Ok, forget about it. I know now the initialization data is not a part of
the content, so when content is not downloaded, but selected, and initData
is downloaded to the UA, the media element is created by the UA, right?

>
>> Can we use a seperate object for encrypted media like media source, so we
>> can call generate key using encrypted media without create the media
>> element, which will keep media element clean.
>>
>
> That is one possibility and one of the advantages of a constructor-based
> design for the session object. See
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0134.html and
> the related proposal in
> http://lists.w3.org/Archives/Public/public-html-media/2012Jul/0002.html.
>

Seperate the generateKeyRequest with media element is good, but are you
sure that before media element is created, the initData is availbe for the
generateKeyRequest?


>
>>
>>
>>
>> On Sat, Jun 23, 2012 at 6:33 AM, 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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Yang
>> Huawei
>>
>>
>


-- 
Yang
Huawei