- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 08 Mar 2012 16:15:04 -0800
- To: robert@ocallahan.org
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Glenn Adams <glenn@skynav.com>, Philip Jägenstedt <philipj@opera.com>, public-html@w3.org
- Message-ID: <4F594B88.4@jumis.com>
TL;DR: The encrypted media proposal needs an implemented baseline, and an API mapping table save everyone a lot of grief. Recommendation: Use the websockets masking key method as the baseline for CDMs. Gather an API mapping table for popular CDMs. Document the masking key method as the baseline in the actual spec. The rest in thread. -Charles On 3/8/2012 3:08 PM, Robert O'Callahan wrote: > I agree with Tab and Philip. > > I don't know if anything could make me feel *good* about this > proposal, but I would definitely feel less bad about implementing it > if we knew more about what the CDMs are likely to be and how one would > deploy them and integrate them into an open-source browser (including > at least one CDM up to Hollywood-placebo-standard). What I'm hearing here is that an open source project should be able build a CDM client-server in open source, and support it; and it should work with this Encrypted Media Extensions API. Commercial CDM requires merchants purchase licenses or otherwise sign limiting contracts. Sections 1.2.4 and Sections 6 of the spec are incomplete. http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#simple-decryption-clear-key In my imaginary life, I would write a CDMs baseline using websockets masking key, and add it to that specification as the default keysystem. <http://tools.ietf.org/html/rfc6455> Vendors and authors have mature websockets masking code. http://tools.ietf.org/html/rfc6455#section-5.3 http://dev.w3.org/html5/websockets/ Content would be masked on the network (CDN?) all the way through to the media element (CDMs) stream processing. So the network sends the whole file websockets masked, it gets unmasked by the browser as the file is read. This would typically look like a blob:*: uri to debugging tools when running a url inspector. The spec could use a mapping supplemental. Imaginary statement: "If you want your CDM supported, tell us what method names to call, it can be put into a table." The Chromium baseline might, for instance, only support the baseline CDM. Meanwhile consumer releases of Chrome might support a variety of CDMs. At which point authors, such as weary Netflix coders, don't have to repeat that work through object tags. Here's an example from accessibility APIs: http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html Tap on "View as single table". It'd be really nice to get some answers from current implementers, such as Netflix, Adobe, and vendors like Google and Microsoft, as to what the current mappings are for some products out there. We've heard a few of the names thrown around about various products on the market. And that's what Netflix is really asking of vendors anyway, is to support existing products. That work should get done ahead of time at the W3C, so that developers from WebKit and Mozilla don't have to hunt down the information themselves.
Received on Friday, 9 March 2012 00:15:29 UTC