21155 2013-02-28 12:49:42 +0000 EME should be explicit about its relationship with Web Platform APIs that allow video frames and audio samples to be extracted from an HTMLMediaElement 2013-05-28 15:09:51 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED FIXED P2 normal --- 1 hsivonen watsonm adrianba ddorwin fredandw mike pal public-html-media watsonm public-html-bugzilla oldest_to_newest 83827 0 hsivonen 2013-02-28 12:49:42 +0000 The purpose of EME suggests limiting the availability of video frames or audio samples to JavaScript programs. If it is the intent of EME to limit the availability, the specification should define how HTMLMediaElements with non-null keys property interact with other Web Platform APIs that normally allow video frames or audio samples to be extracted from an HTMLMediaElements. If the intent is not to to make a non-null keys property to have an effect on how HTMLMediaElements interact with APIs that allow video frames or audio samples to be extracted from an HTMLMediaElement, there should be an informative note stating this explicitly, because the absence of requirements would be surprising given the purpose of EME. 83839 1 fredandw 2013-02-28 21:26:37 +0000 Standards reflect consensus among some web browser implementers and thus have no standing or ability to impose restrictions that might advantage the business interests of some content authors. The EME task force has already declared that the implications of the operation of the CDM are out of scope as is the level of protection that the CDM provides. Some expected use cases for the EME do suggest that on some proprietary stacks that the decoded output of some CDMs may not be available and thus such APIs could not in general be depended on. I would not that the diagram in the EME specifications notes that decoded frames may, or may not, be returned to the UA. Standards reflect consensus among web browser implementers, which may include users, and thus have no standing or ability to impose restrictions that might protect the business interests of some content authors. The implications of an attempt to do so should be explored. Further, attempts to fingerprint the UA in order to restrict content delivery based on detected capabilities could restrict normal UA operations, such as UA spoofing, and the implications of attempts to so should be explored. The EME Impact document hosted at the WHATWG Wiki is happy to host such analysis, and a note has been added about your concern, see: http://wiki.whatwg.org/wiki/Encrypted_Media_Extensions_Impact 86712 2 ddorwin 2013-04-24 20:22:54 +0000 This was discussed during the March 26th telecon [1]. I believe bug 21569 was filed as a result. Does that bug now cover the intent of this one? An action [2] was also created to propose some text. Mark, which bug is that related to? [1] http://www.w3.org/2013/03/26-html-media-minutes.html#item05 [2] https://www.w3.org/html/wg/media/track/actions/11 86713 3 watsonm 2013-04-24 20:30:58 +0000 Bug 21569 is broader and I guess could be considered to subsume this one, but it might be simpler to leave them as separate. This bug specifically addresses the availability of the decoded media frames to the JS application. Bug 21569 asks about other HTML/CSS capabilities that might not operate or may not operate differently with protected media (for example CSS transforms). Action 11 is related to this bug. 86715 4 ddorwin 2013-04-24 20:43:24 +0000 Since the frames would only be available via other HTML/CSS capabilities, it probably makes sense to address all capabilities at once (preferably in the same way). We could explicitly call out that case in this bug in the other bug. Assigning to Mark since he owns Action 11. 88279 5 watsonm 2013-05-28 15:09:51 +0000 https://dvcs.w3.org/hg/html-media/rev/fc9e628b538f