W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2014

[Bug 27054] Accessibility Concerns

From: <bugzilla@jessica.w3.org>
Date: Mon, 27 Oct 2014 09:06:52 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-27054-3290-rPvotYufxv@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054

--- Comment #6 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(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.

(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.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 27 October 2014 09:06:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:44 UTC