This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Yes, a key should not "leak" from one key session or media element to another. Do you have a suggestion for replacement text?
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.
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.
(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."
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.
(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.