WHATWG Wiki - User contributions [en]

Internet Encrypted Media Extensions

2014-01-27T05:15:18Z

Fredandw: /* Requirements */

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.

Internet Encrypted Media Extensions

2014-01-27T05:11:56Z

Fredandw: /* Requirements */

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 it needs to be tagged of distinctly identified 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.

Internet Encrypted Media Extensions

2014-01-27T04:59:28Z

Fredandw: /* Requirements */

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 proposal will define the http protocol between the client media player and the server, and thus 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. If it needs to be tagged of distinctly identified 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.

Internet Encrypted Media Extensions

2014-01-27T04:58:57Z

Fredandw: /* Requirements */

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 proposal will define the http protocol between the client media player and the server, and thus 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. If it needs to be tagged of distinctly identified 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.

Internet Encrypted Media Extensions

2014-01-27T04:53:56Z

Fredandw: Minor revision

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.

* 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.

Internet Encrypted Media Extensions

2014-01-27T02:23:43Z

Fredandw: A proposal to extend the EME to support operation over the Internet and to add browser support to redirect to IEME media players

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.

Encrypted Media Extensions Impact

2013-02-28T21:23:09Z

Fredandw: Note W3C Bug 21155: EME should be explicit about its relationship with Web Platform APIs that allow video frames and audio samples to be extracted from an HTMLMediaElement

Editor: Fred Andrews

This document hosts an analysis of the impact of the [https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions] W3C specification, and may well offer suggested changes to the EME specification that mitigate concerns raised. This is very much a work in progress, and currently just a place holder.

The editors of the EME refuse to accept analysis of EME that depends on the operation of the CDM plugins of the EME API and this significantly limits the ability to document the impact and to explore the security and privacy implications within the W3C forum. There has been a lot of discussion surrounding the EME and this document hosts positions and ideas being discussed beyond the limited scope the that the W3C EME specification editors are prepared to host.

While the goal of this document is to move towards consensus, it is expected to host conflicting positions in order to aid constructive discussion and respect of a range of views.

== APIs reading back decoded video or audio ==

[https://www.w3.org/Bugs/Public/show_bug.cgi?id=21155 Bug 21155] points out that the EME specification does not appear to restrict APIs that allow decoded video and audio to be extracted, and appears to request that EME does declare such restrictions.

Fred: I presume that on some proprietary stacks that the decoded output of some CDMs may not be available and thus such APIs could not in general be depended on. Standards reflect consensus among web browser implementers and thus have no standing or ability to impose restrictions that might protect the business interests of some content authors. The implications of an attempt to do so should be explored. Further, attempts to fingerprint the UA in order to restrict content delivery based on detected capabilities could restrict normal UA operations, such as UA spoofing, and the implications of attempts to so should be explored.

Encrypted Media Extensions Impact

2013-02-28T11:24:57Z

Fredandw: Create an initial place holder.

This document hosts an analysis of the impact of the [https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions] W3C specification, and may well offer suggested changes to the EME specification that mitigate concerns raised. This is very much a work in progress, and currently just a place holder.

The editors of the EME refuse to accept analysis of EME that depends on the operation of the CDM plugins of the EME API and this significantly limits the ability to document the impact and to explore the security and privacy implications within the W3C forum. There has been a lot of discussion surrounding the EME and this document hosts positions and ideas being discussed beyond the limited scope the that the W3C EME specification editors are prepared to host.

While the goal of this document is to move towards consensus, it is expected to host conflicting positions in order to aid constructive discussion and respect of a range of views.