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

2013-02-28T21:23:09Z

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

← Older revision		Revision as of 21:23, 28 February 2013
Line 1:		Line 1:

			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.		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.
Line 5:		Line 7:

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

Fredandw: Create an initial place holder.

2013-02-28T11:24:57Z

Create an initial place holder.

New page

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.

Encrypted Media Extensions Impact - Revision history

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

Fredandw: Create an initial place holder.