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
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 declare a source URL and a mime type or other attributes.

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 orthogonal to the content owners and distributors, allowing the user to choose a media player that suits their needs, and this market can address some of 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 protected content to alternative devices.

It 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 and 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 browser vendor can distribute their own web player application that closes the competing browser when finished 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.
  • It must be possible to implement a media player conforming to this standard as a non-web applications that does not implement Javascript, DOM APIs, or the EME API.
  • The protocol between the client media player and the server must be well defined.
  • Content published conforming to this standard should be playable in a reference player application.
  • The protected content must be linkable via a URL that can be forwarded to the media player.
  • 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.
  • The web browser support, for redirecting content, must clearly not be part of a DRM system. If the link needs to be tagged then it should not be tagged as protected content but rather as redirected content. 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, and that no modification of the redirecting web browser could compromise the content protection scheme.