> From: [email protected]
> Date: Mon, 27 Jan 2014 18:18:45 -0800
> CC: [email protected]
> To: [email protected]
> Subject: Re: Proposal: Internet Encrypted Media Extensions
>
> I am fairly sure I don’t understand what you are proposing, alas. Can you
> say more about what you’re proposing? The Wiki talks about its advantages
> more than what it is.
The core idea is that the media player does not require a web browser, compared
with the EME which does require a capable web browser.
The proposal would be designed from the ground up to allow easy separation of
the DRM device from the users general purpose computer, giving the user the
option to keep such devices separate. It does not prevent a web browser
implementing an integrated player on a proprietary stack.
One of the design goals of the EME appears to be to restrict the DRM component
as much as possible, but the CDM is not defined to play content on its own and
requires a capable web browser. This proposal defines a minimal media player
that can player content on it's own, and one that can be implemented by a web
app on an EME capable web browser.
> The biggest clue I got was "by redirecting to a separate application”. I
> don’t see how this is any advantage.
The advantages are discussed in the wiki. Which advantage do you dispute?
> That application obeys DRM robustness requirements, just like something
> linked to EME. The disadvantage is that it’s doing everything native — UI,
> the lot.
It does not need to implement a web browser. Native is orthogonal to the
proposal - it could be implemented in a EME capable web browser and this web
browser would not be exposed to the wider web rather just the user chosen media
player web app. I do not see a disadvantage here, and there are many
advantages. A device that obeys publishers robustness requirements is a
threat to the user and making it easier for users to keep such devices separate
from their general purpose computing reduces the threat, and the less need for
such devices the better. The device supplier already has an interest in it
being robust (to protect the content) and the more limited its functionality
then the easier it would be to harden.
Could you please expand on the 'disadvantages' you see, and the disputed
advantages?
cheers
Fred