19785 2012-10-30 16:23:20 +0000 Clarification on key storage 2012-10-31 15:47:13 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED DUPLICATE 17750 P2 normal --- 1 steele adrianba ddorwin mike public-html-media public-html-bugzilla oldest_to_newest 77436 0 steele 2012-10-30 16:23:20 +0000 There is some discussion on this email thread (http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0066.html) about when keys are cleared. After re-reading the spec it does not appear clear that keys or licenses can be retained in a persistent cache by the CDM between sessions. I don't believe the intent of the spec is to prevent the CDM from retaining keys or licenses across sessions, but I think that needs to be spelled out in the spec a little more explicitly. Specifically I think this section (http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-close) needs to be clarified to say that only keys which are not intended to be retained across sessions should be cleared. It might be useful to add a definition of transient keys versus persistent keys and use that as a reference point where key caching is discussed in the spec as well. 77451 1 ddorwin 2012-10-30 18:06:50 +0000 Issue 17750 is open to define the close() and object destruction behavior. What do you mean by "sessions" when you say "across sessions"? Browser context sessions or key sessions? How "persistent" do you want to allow keys to be? The existing text about caching is non-normative and relates to key replacement if, for example, the CDMs key storing resources are exhausted. 77456 2 steele 2012-10-30 20:06:19 +0000 I mean across sessions created using createSession(). I also mean across browser instantiations -- e.g. if I close my browser I may not want to throw away all of my cached licenses. This has implications for when the browser is in privacy mode and when this type of data would be cleared, but all have pretty reasonable answers. Would you prefer moving this discussion to the other bug? I thought this was different enough that it warranted a new bug, but I had not read your last comment. 77521 3 steele 2012-10-31 15:47:13 +0000 *** This bug has been marked as a duplicate of bug 17750 ***