Re: Proposal: Internet Encrypted Media Extensions

Hi Fred,

I think I understand the proposal a little better now.

As I mentioned, the Presentation API offers the possibility for a web page
to direct playback of content to another device. Does that API meet your
requirements for the "separate device" case ?

For the case of a separate player application on the same computer as the
web browser, I would like to understand better the advantages you see in
this ? Is it because the player is running in a separate process ? What is
the advantage of this isolation within a separate application that is
different from the isolation of DRM capabilities into a CDM in the EME
proposal ?

Regarding the idea of a set of media players conforming to a common
standard and protocols that would all be able to play all protected
content, I think this is unrealistic. Service providers will want to
maintain their ability to innovate around the player for their service. It
would be a bit like asking Google+ and Facebook to agree to use a common
set of social networking protocols for client <-> server interaction.

...Mark


On Wed, Feb 5, 2014 at 6:18 AM, Fred Andrews <fredandw@live.com> wrote:

>
>
> > Subject: Re: Proposal: Internet Encrypted Media Extensions
> > From: singer@apple.com
> > Date: Mon, 3 Feb 2014 16:30:07 -0800
> > CC: watsonm@netflix.com; public-restrictedmedia@w3.org
> > To: fredandw@live.com
>
> >
> > I still don't understand what you are proposing.
> >
> > Is it (a) that the DRM and media decoding be done in a separate
> application?
>
> Yes. Or if the user chooses, a separate device.
>
>
> > (b) that the entire UI and exchange with the server be done in a
> separate application?
>
> The media player UI is a matter for the media player vendor and is chosen
> by the user.
>
> The media player UI is not exposed to the web developer.
>
> The media player's entire exchange with the server is done in a separate
> application or device.
>
> The web interface runs in the separate web browser.
>
>
> > (c) that something is built that looks like a 'restricted browser' but
> that has all the functionalities of a regular one?
>
> Certainly not.  A web browser is not exposed to the web developer via the
> media player, only via the separate web browser.
>
> The media player may well be implemented in a web browser, but the web app
> would be chosen by the user, and there would be a reference app that
> conforming content must play in.  The web developer would not have access
> this web browser, apart from the media stream.
>
>
> > I think you may be unaware of the W3C's initiative to try to level the
> playing field, where appropriate, with native apps. They are eroding the
> open, interlinked web, in some people's eyes. By asking for a separate
> native app, you are asking to go the other way. It feels as though you are
> trying to build a silo, where others are trying to take it down.
>
> Keeping DRM out of the open web, and out of peoples general purpose
> computers, has many advantages for users, including security.
>
>
> > The advantages of using the browser as the UI engine for watching media
> are legion. Not least,
>
> > (a) linkability to to the media and its support resources etc.
>
> The IEME proposal could use a URL to link to the content.
>
>
> > (b) accessibility using the web platform
>
> The IEME proposal would add a general mechanism to redirect content to the
> separate media player making it very accessible from the web platform.
>
>
> > (c) client-side configurability (e.g. user style sheets). I am sure
> there are more.
>
> The IEME proposal has much better support for user choice over the media
> player.  The user can use their chosen player to view all content, and do
> not need to use separate client side configurations for each web developers
> player.  There is nothing preventing the media player controls using HTML,
> but this is not exposed to the web developer.
>
> cheers
> Fred
>
>