This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
While the algorithms probably cover this, it would be helpful to explicitly state how keys may be shared. We want to prevent different behavior that could lead to pages that make assumptions that are not true for all implementations. The current intent is that keys/licenses are shared for all streams (i.e. audio and video) in a single media element but are NOT shared between media elements (whether in a given page or different pages). CDMs should ensure that keys don't leak between elements. Bug 16615 proposes a specific scenario where sharing might be allowed.
(In reply to comment #0) > While the algorithms probably cover this, it would be helpful to explicitly > state how keys may be shared. We want to prevent different behavior that could > lead to pages that make assumptions that are not true for all implementations. > > The current intent is that keys/licenses are shared for all streams (i.e. audio > and video) in a single media element but are NOT shared between media elements > (whether in a given page or different pages). CDMs should ensure that keys > don't leak between elements. > > Bug 16615 proposes a specific scenario where sharing might be allowed. There are certainly scenarios where keys/licenses should be shared across elements slaved to a MediaController (as in 16615). For example two video elements showing different video tracks from the same src (main video and sign language, for example). I'm not sure if the use of MediaController is the right test to enable/disable sharing, though. Is it possible that two elements with the same src that are not slaved to the same MediaController might share keys/licenses ? It's common for all the resources associated with some presentation to share the same keys, since this avoids the need for multiple or compound key/license requests. I'm not sure we should rule this out for presentations where the component resources are not synced with a MediaController, although I can't think of any good examples of such presentations. What's the disadvantage if we allow keys/licenses to be shared by all elements on the page ?
Resolved to later (see also bug 16615).
Reopening to make sure the spec is explicit about ways keys may and may NOT be shared. As mentioned in the original description, the intent was that keys are not shared between HTMLMediaElements - now MediaKeys. I believe the spec has progressed in this direction. Some possible ways for an application to explicitly share keys within a frame are covered by their own bugs: MediaController (bug 16615) and sharing MediaKeys among HTMLMediaElements (bug 19009) However, there have been discussions of retrieving saved keys or reusing keys across tabs or browsing sessions. This may mostly apply to stored keys (see bug 21869), but it could also apply to in-memory keys. Domain keys and other key hierarchies are some of the examples given. Such sharing opens up the possibility of leaking information, especially across origins. There are also issues of potentially sharing between normal and Incognito/Private Browsing sessions, across profiles, and even across different OS user accounts. Addressing these issues in the spec and/or implementations would add a lot of complexity, and I think it would be best to avoid.
See also the discussion about origin in bug 20965.
(In reply to David Dorwin from comment #4) > See also the discussion about origin in bug 20965. I sent an email with a proposal for this. Please take a look.
(In reply to Joe Steele from comment #5) > (In reply to David Dorwin from comment #4) > > See also the discussion about origin in bug 20965. > > I sent an email with a proposal for this. Please take a look. I think this is resolved with this thread: http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0022.html
Discussed in TPAC 2013 F2F - David will make the orthogonal changes in comment 3 and resolve the bug.
https://dvcs.w3.org/hg/html-media/rev/151f30f76656 addresses comment 3.