[Bug 17750] Define the behavior MediaKeySession close() and clearing the keys attribute

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

--- Comment #9 from David Dorwin <ddorwin@google.com> ---
I think the CLOSED state makes sense, and there are other use cases for it
(e.g. the platform forcefully closed the session for some reason).

I don't object to close(), but I'd like to make sure we understand the use
cases we're targeting and that it really solves them.

(In reply to Adrian Bateman [MSFT] from comment #5)
> We discussed this bug on the last telcon.
> 
> I think there are two parts to this bug. One is how close() might relate to
> secure key release. I believe that this should be handled as part of bug
> 17199, which should be used to solve the problems for and define secure key
> release.
> 
> Here I think the question is what effect should close() have on a session.
> For that I think we have to consider what scenarios close would be used in.
> close() is only necessary if we think there is a situation where the
> JavaScript application will have a better idea of the desired key lifetime
> than the CDM. It would use close() to signal some extra hint that would be
> used to release the resources associated with keys. It is not clear that
> this situation exists and if we don't have evidence for it then it would be
> better to leave close() out until we understand what scenarios it needs to
> solve.

What changed between comment #5 and comment #8? What scenarios/concrete
examples are we trying to address? (Also, see the reply to comment #7 below.)

> With our proposal for the MediaKeySession state model, two different
> MediaKeySessions could be responsible for acquiring the same key. This means
> that calling close() on one session doesn't offer any guarantee that a
> particular key is released. In addition, the way many CDMs are likely to be
> implemented, keys will be passed to the media engine and their lifetime
> managed there.

We need to address the behavior around such "shared" sessions if we choose to
move forward with the proposal in comment #8. If close() is just a hint (see
below), is it up to the CDM to decide what to do? Whenever "shared" sessions
are closed by the CDM, both should probably receive the CLOSED event.

> I propose that we remove the close() method from the MediaKeySession in v1
> unless we have a concrete example from on implementer of how they will use
> it. In that case, the language of the spec should make close only a hint to
> the CDM that may be ignored.

Should we be more explicit about close() being a hint in the proposal in
comment #8?


(In reply to Joe Steele from comment #7)
> In case it was not clear from my comment - the concrete example I am
> thinking of is switching from one app to another, both using EME. I would
> like to not retain the keys any longer than required and my feeling is than
> an explicit close() message will be faster than waiting for the JS engine to
> garbage collect the closed tab. It will also allow for apps that detect when
> they are not in the foreground and release resources they don't need any
> longer (e.g. keys).

Does "switching from one app to another" mean navigating away from the page? I
don't think there's any guarantee that you'll be able to call close() or that
it will take effect when navigating away or closing the tab.

Maybe we need the browser to "stop" the session and/or MediaKeys (CDM instance)
in these cases. (This would be similar to how ActiveDOMObjects in WebKit/Blink
are stop()'d, but I don't know if there is a way to specify such behavior.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 14 October 2013 20:29:34 UTC