- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Oct 2014 18:37:33 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054 --- Comment #7 from David Dorwin <ddorwin@google.com> --- (In reply to Henri Sivonen from comment #6) > (In reply to John Foliot from comment #3) > > While I will ask an engineer more involved with the technical aspects of > > CDMs to weigh in if I am incorrect, it is our understanding that the > > encryption is done at the media-wrapper layer, and once the wrapper is > > "unlocked" all of the piece-parts (including any in-band support content) > > would be exposed to the existing APIs in exactly the same fashion as > > unencrypted content. > > This is not a correct assumption in general. EME has been designed to allow > arrangements where the DRM subsystem performs more steps than merely > decryption in order to hide things from the browser engine. > > Note that I'm not claiming that anyone is actually planning to a) let > caption tracks [that are actually separate tracks as opposed to being U.S. > TV captioning-compatible data inside an MPEG-2 video track] be encrypted and > b) not let the decrypted caption track flow into the browser engine. Would either of you like to propose text to address these concerns? Maybe we should file a separate sub-bug specifically for text track issues. > (In reply to David Dorwin from comment #5) > > EME assumes encryption is on blocks within the media container. > > While this may be the assumption and what every implements in practice, is > there actually something in the spec that prohibits the encryption being a > wrapper around the media container? (Not that it's relevant for this > bug--just pointing out how many things EME doesn't actually specify, AFAICT.) Good point. What restrictions do we need to place on the media? Maybe open a separate bug for this since it's not specifically an accessibility issue. Also, if you find other underspecification issues, please file bugs for those too. A number of assumptions were not clearly documented, and we've been trying to address those. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 30 October 2014 18:37:35 UTC