Hi Mark, Something similar to the Presentation API might work, but it should be possible to specify something simpler, perhaps declarative. The particular mechanism(s) are not a core area of dispute and I expect that many options could advance without too much dispute.
The case of a 'separate player application on the same computer' is just one implementation option (for a proprietary OS). A proprietary web browser on a propretary OS could even integrate the media player. The proposal needs to support users who want to view content on separate devices and these users should not be second class web citizens so this should not be exposed to the web developer. The OS vendor may well be able to take advantage of the separation to improve security, and if the user has security and privacy concerns then they have the option to use a separate device. Computer suppliers could innovate in their support for secure media players, offering separate modules that can be sand-boxed in a verifiable manner. If the user is really concerned then they have the option to use a physically separate device that they can firewall on their network - the communication might be encrypted but the user can monitor the meta information. Regarding the use case of supporting service provides innovating around the player for their service, I think this might be a key use case for the EME that has not yet been articulated? A lot of innovation can still be supported with a separate media player. The media player is intended to be simple in terms of presentation, and not to support customization by the service provider. The web browser component is still exposed to the service provider to be customized. What 'innovations' are not supported? An open market for the media player is much better for the user. The service provider can still promote their own media player and if it has benefits for the user then users can choose to use it. Is the key use case of the EME API is to allow service providers to lock users into using only their media player? That would be consistent with leaving the protocol between the EME API and the server undefined and customizable by the service provider, but this is not consistent with the principles of the open web. The key issue is that DRM has specific security issues and the demands of DRM are not consistent with an open web. The user needs to have the option to keep it separate to control their security. The DRM media player needs to be as well defined as possible to minimize the security issues and this dictates that it must support minimal customization, and that any customization should be transparent to the user and be optional. If the service providers are not here to agree on a interoperable standard then they have no business here. An interoperable standard may well be in the best interests of the MPAA. It would lower the barrier for distributors and might create more competition in this market. It would not be necessary to define a complete DRM system, just develop a reference web application for playing media using the existing CDM DRM systems and to create a compliance process. cheers Fred Date: Wed, 5 Feb 2014 07:40:53 -0800 From: [email protected] To: [email protected] CC: [email protected]; [email protected] Subject: 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 <[email protected]> wrote: > Subject: Re: Proposal: Internet Encrypted Media Extensions > From: [email protected] > Date: Mon, 3 Feb 2014 16:30:07 -0800 > CC: [email protected]; [email protected] > To: [email protected] > > 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
