- From: Andreas Kuckartz <A.Kuckartz@ping.de>
- Date: 28 Feb 2012 21:17:50 +0100
- To: "Adrian Bateman" <adrianba@microsoft.com>
- Cc: "Maciej Stachowiak" <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, "David Dorwin" <ddorwin@google.com>, "Mark Watson" <watsonm@netflix.com>
I have had a closer look at the proposal. The component labeled "Media Stack" has access to the decrypted frames. If I understand it correctly then to "protect" the content from users implies that this component can not be Open Source without defeating the stated purpose. Correct? These sentences in the proposal are also interesting in this context: "Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support." So the plan with the Encrypted Media proposal is to create the foundation for "specific user agent solutions" which "open source browsers" can not "natively support." Correct? Or do I misunderstand anything? This question and answer could not be clearer: "Can a user agent protect the rendering path or protect the uncompressed content after decoding? Yes, a user agent could use platform-specific capabilities to protect the rendering path." I would like to see an example of a content provider who cares about "content protection" so much that he demands using a "Content Decryption Module" but does not demand such "platform-specific capabilities to protect the rendering path". Cheers, Andreas
Received on Tuesday, 28 February 2012 20:18:15 UTC