On Feb 3, 2013 3:24 PM, "Glenn Adams" <glenn@skynav.com> wrote: > For example, an alternative proposal might be to reframe EME as an extension to TLS that would allow a pluggable key and encryption method in TLS as well as a JS API that interacts with TLS that serves the same functions as being proposed with EME. EME tries to address cases where the browser engine is not trusted with the decrypted but still compressed H.264 bitstream. Supporting that "same function" while pushing stuff to TSL would make the integration point between the user-replaceable part of the browser codebase and the Hollywood domain even trickier than with EME. So I think pushing things to TLS just to pretend to use an existing extension point would be an improvement as long as the assumption is that the browser engine won't be trusted with the decrypted codec bitstream in some Hollywood content scenarios. If you have information that says the decrypted codec bitstream can be given to user-replaceable browser engines (the way TLS normally terminates) in all relevant scenarios, it would be helpful to bring that information forward.
Received on Sunday, 3 February 2013 15:09:48 UTC