A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Internet Encrypted Media Extensions

From WHATWG Wiki
Revision as of 02:23, 27 January 2014 by Fredandw (talk | contribs) (A proposal to extend the EME to support operation over the Internet and to add browser support to redirect to IEME media players)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Editor: Fred Andrews

Abstract

This proposal extends the W3C Encrypted Media Extension (EME) to support the playing of protected content by Internet clients that are not required to implement a web client.

The W3C EME defines a web API to control playback of protected content but leaves it to the web application to link this API to the server. This proposal defines a standard to fill this gap.

This proposal will support web developers publishing protected content without the need to distribute a web application media player. It might only be necessary to publish a distinct URL or mime type.

It will make it possible to play the protected media content on a lighter weight native media player that does not implemented a general web client and without loss of features. Web developers would keep the web app in the web browser.

It will create a market for media players, allowing the user to choose a media player that suits their needs, and that support a market for media player developers to meet their needs. This in turn will allow the market to address the security and privacy needs of users.

Some users need the convenience of viewing protected content on their general purpose computer and are not too concerned about the security and privacy implications of their computer being controlled by publishers. Some users need security and privacy so need to view protected content on separate sand-boxed devices.

This proposal will allow web browsers built on FOSS stacks, that do not support the playing of protected content, to redirect the playing of such content to alternative devices.

This proposal will also allow web browser vendors to avoid implementing the EME API while still supporting users needs to view protected content, by redirecting to a separate application. This might be relatively seamless on a proprietary stack.

This standard will be implementable in a proprietary EME capable web browser, but the web developer will not have access to a general web client which will mitigating the anti-competitive impact of having to redirect to a competing web browser. The FOSS browser vendor can distribute their own web player application that closes the competing browser when finish viewing the protected content.

Given that this proposal will have wider reach than the EME API, it is expected that the EME API will be relegated to a proprietary standard and need not be part of the open web. The EME API can be deprecated in favor of separate media applications.

While this proposal promotes the use of DRM content, it is far better for the user than the EME API which is underspecified allowing distributors to lock-in users to use only the distributors media player web application, and the EME API taints the open web with DRM components.


Requirements

  • It must be possible to implement a media player conforming to this standard using the W3C EME API on a proprietary web browser. A

reference player application is expected to be written.

  • A media player conforming to this standard must be implementable by non-web applications that do not implement Javascript or the DOM APIs or the EME API.
  • The proposal will define the http protocol between the client media player and the server, and thus it might be linked by a http URL.
  • A user agent should be able to differentiate IEME media content from non-protected content early enough that it can redirect the playing of protected content to an alternative device or application as seamlessly as possible. This might be implemented by a distinct URL extension or mime type.
  • Content published conforming to this standard should be playable in a reference player application.
  • The web browser support, for redirecting content, must clearly not be part of a DRM system. It is only expected that general mechanisms for redirecting content will need to be implemented in the browser, and that the media player can stand alone and accept a URL.