25271 2014-04-05 01:24:03 +0000 Key Session description of key usage is ambiguous 2014-04-29 17:07:20 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified PC All RESOLVED LATER P2 normal --- 1 steele adrianba ddorwin mike public-html-media public-html-bugzilla oldest_to_newest 103445 0 steele 2014-04-05 01:24:03 +0000 In this section (https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-session) this text "Other MediaKeys objects, CDM instances, and media elements may not access the key session or use its key(s)." is ambiguous. You could interpret this to mean that two content streams that share the same key cannot be played at the same time. I believe what is meant here is that the each media element must have it's own key session, not sharing a common key session. I don't believe the intent is that the duplicate keys cannot be used in different key sessions. 103446 1 ddorwin 2014-04-05 01:34:54 +0000 Yes, a key should not "leak" from one key session or media element to another. Do you have a suggestion for replacement text? 103483 2 steele 2014-04-07 16:01:20 +0000 It seems that the goal here is to prevent a malicious site from detecting key usage by using a timing attack. If we make that goal explicit that also resolves the ambiguity. What about this text? "Other MediaKeys objects and media elements may not access the key session. An application in one origin should not be able to detect the existence of keys in another origin via timing." This will allow for things like device specific keys in hardware. 103487 3 ddorwin 2014-04-07 17:22:51 +0000 In addition to security/privacy, the goal is also to have consistent behavior. If some implementations leak keys and others don't, applications built for the former might not work with the latter. Is your concern keys in hardware or provisioned keys? If so, those keys don't belong to a key session, so this text would not apply. 103489 4 steele 2014-04-07 17:30:39 +0000 (In reply to David Dorwin from comment #3) > In addition to security/privacy, the goal is also to have consistent > behavior. If some implementations leak keys and others don't, applications > built for the former might not work with the latter. > > Is your concern keys in hardware or provisioned keys? If so, those keys > don't belong to a key session, so this text would not apply. I disagree that provisioned keys are part of a key session, as I mentioned in another thread. Putting that aside, if those key types should not be covered by this text, then the text should be be more specific about the types of keys it covers. For example: "An application in one origin should not be able to detect the existence of _content_ keys in another origin via timing." 104464 5 ddorwin 2014-04-25 19:51:25 +0000 This is related to the use case discussion. I don't think we can make any definitive text proposals at this time, so resolving LATER. 104691 6 steele 2014-04-29 17:07:20 +0000 (In reply to David Dorwin from comment #5) > This is related to the use case discussion. I don't think we can make any > definitive text proposals at this time, so resolving LATER. Agreed. On that note -- a first cut of the use cases is written here: https://www.w3.org/wiki/HTML/Media_Task_Force#Use_Cases Please review and modify as needed.