[Bug 27093] New: Support for proprietary/system-specific formats in initData should be discouraged/deprecated

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 the QA Contact for the bug.

Received on Friday, 17 October 2014 18:09:35 UTC