- From: <bugzilla@jessica.w3.org>
- Date: Fri, 17 Oct 2014 18:09:34 +0000
- To: public-html-media@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093 Bug ID: 27093 Summary: Support for proprietary/system-specific formats in initData should be discouraged/deprecated Product: HTML WG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Encrypted Media Extensions Assignee: ddorwin@google.com Reporter: ddorwin@google.com QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-media@w3.org Blocks: 20944, 26838, 27053 (This bug focuses on CENC PSSH boxes because that is the only currently defined initialization data type that supports proprietary or key system-specific formats, but the arguments would apply to any such initialization data type.) Proprietary PSSH Data formats have been and continue to be a source of interoperability and security problems. Their (publicly) undefined and inconsistent feature sets (because the ISO CENC spec allows them to contain anything) makes discussing and defining interoperable normative behavior difficult, if not impossible. As was noted in bug 17673 and bug 20944, they are an avenue for vendor lock-in and a threat to the interoperability goals of this spec. Content packaged with only proprietary PSSH boxes has the effect of segmenting the platform (bug 27053). Also, per-key system PSSH boxes does not scale, is a hassle for content providers and packagers, and locks out new key systems. There are also technical issues with proprietary PSSH boxes: * Some formats are encrypted, which likely prevents the user agent from validating the input before passing it to the CDM (bug 26838). * User agents, especially open source ones, may not be able to validate or sanitize unpublished formats (bug 26838). * Proprietary PSSH boxes could contain code (bug 22901). * Validating proprietary PSSH boxes in the user agent requires additional code (and libraries, such as XML support). This is especially relevant should a user agent implementation wish to support multiple key systems. * Proprietary formats can be used to abuse the initData parameter (i.e. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082#c10). In the interest of interoperability, openness, a consistent platform, and security, support for proprietary/key system-specific formats formats should be discouraged and deprecated. While implementations will likely support proprietary PSSH formats until content (and devices) are updated to use standard format(s), the spec and standardization process should not be burdened by proprietary formats and use cases. (Even existing content need not be a limitation since PSSH boxes can be obtained from other sources.) I expect that CDMs will continue to support their proprietary format along with the standard one(s) and that content packagers will include some proprietary formats along with the standard ones. We currently have a simple extensible format defined [1] that should support most use cases. If we are missing support for some use cases, we should discuss them and potentially add support for them both to the main spec and the CENC registry entry. We can also consider adding common formats standardized elsewhere to this section. Advantages: * Encourage use of and support for standardized formats as more content is generated and more content providers switch to HTML5. * Eventual broad support for standard formats will: - Enable user agents to thoroughly validate the initData before sending it to the CDM. - Enable content providers, applications, and packagers to support multiple (and new) key systems without adding a PSSH box for each (new) key system. See also bug 27053. * For content providers (and packagers), especially small ones, it will be simpler to support multiple clients. * For the spec: - Deprecating proprietary formats allows us to focus on documented formats and models and make more of the initData validation text normative. - Use cases not supported by the existing standard format can be surfaced so they can be discussed and solved in an interoperable way if necessary. The main disadvantage is that some implementations supporting proprietary PSSH boxes may not be fully spec compliant. For example, more normative validation may not be possible. I think the advantages definitely outweigh this disadvantage. Such PSSH boxes cannot be tested for compliance anyway. [1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-format.html#common-system -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 17 October 2014 18:09:35 UTC