W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Media Stack: closed source only Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Andreas Kuckartz <A.Kuckartz@ping.de>
Date: 28 Feb 2012 21:17:50 +0100
Message-ID: <4F4D366E.1090808@ping.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT