This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From v0.1: The current proposal does not support a mechanism to release keys. It is expected that the User Agent and CDM will release keys that are no longer needed as necessary to free resources. No use case for triggering this release from JavaScript has been identified.
Perhaps this is stating the obvious, but when secure proof of key release is supported there is a need for script control of key release. This could be explicit (a method to release the key or keys associated with a media element), or implicit when the media element is destroyed.
The draft says keys should be cleared (not available for future frames) on load [1], but it doesn't specifically say to destroy them. That seems like a good update. We should also document that they should be destroyed when the object is destroyed. load should be called when .src is changed, so setting .src="" is one way to force _all_ keys to be destroyed (with the update above) without destroying the element. However, this only applies to releasing keys when playback is interrupted/stopped. Q: Is there a need to release key(s) without changing the source or interrupting playback? [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#algorithms-load
This comment assumes the answer to the above question is "yes". == Releasing all keys in a session == Note: If we want to use allow per-session key release/destruction, CDMs must track the keys for each session ID. Currently, this might be an implementation detail. Assuming releasing keys during playback would only be necessary for different sessions (and thus different licenses), we could use cancelKeyRequest() if we slightly modified its purpose. cancelKeyRequest() is currently meant to be used after calling generateKeyRequest() and before a key is received (keyadded). If we removed step 3 from its algorithm, it could be used for explicitly releasing keys for a session. Use of cancelKeyRequest() for this purpose somewhat abuses the name. Destroying a session object (see bug 16613), could serve both purposes. This would require clearing all references and be subject to garbage collection, though. == Releasing individual keys within a session == Using cancelKeyRequest() or destruction of a session object would not allow release of specific keys within a session, though. Q: Does such a use case exists? If so, is there any reason it couldn't use different sessions? (It seems it shouldn't since keys you want to treat differently, probably require their own license and request.)
The object-oriented API (bug 16613) includes a close() method, which closes the session and destroys the keys. I think we can close this bug. If anyone believes close() should not do that or this does not solve a use case covered by this bug, please speak up. Otherwise, I'll close it.
Resolved fixed.