Re: Campaign for position of chair and mandate to close this community group

On Thu, Jan 16, 2014 at 4:15 PM, Jeff Jaffe <jeff@w3.org> wrote:
> The precedent for having such (non-normative) dependencies is that we began
> to standardize HTML5 video at a time when the dominant codec (H.264) did not
> comply with our RF insistence for Web standards.  Our approach has been to
> standardize that which we can make RF to reduce the proprietary footprint
> and work over time to remove the proprietary pieces.

H.264 is indeed contrary to the W3C's RF insistence. Still, the CDM
situation is much worse than the H.264 situation.

 * <video> has utility with an unencumbered codec. EME has no utility
without an encumbered CDM.

 * What you need to do in order to decode H.264 is not a secret. The
operation of CDMs is.

 * An H.264 decoder doesn't need to be unmodifiable by the end users.
Such unmodifiability is the whole point of CDMs.

 * H.264 is one thing (well, a set of profiles and levels, but still).
There are multiple CDMs. As long as you manage to gain access to one
(multiprofile) H.264 decoder, you have achieved compatibility with
(non-DRM) H.264 content. If you manage to gain access to one CDM, your
browser is still incompatible with content targeted at other CDMs.

 * The entity collecting royalties for H.264 doesn't cares about money
but not about implementation. The entities managing the permissions to
interoperate with CDMs care a great deal about implementation details
that aren't black-box testable from the Web ("robustness").

 * If you are in a country where there's no legal need for you get
permission to interoperate with H.264, your implementation gets to
interoperate even if you don't arrange a permission. In the CDM case,
your unlicensed implementation will be cryptographically denied
interoperability by the root of trust refusing to certify your keys
and key servers refusing to talk to you if your keys don't chain to
the root of trust of the Key System.

 * There's a distinction between unauthorized interoperation being a
civil matter or a criminal matter.

 * Platform (operating system or hardware) decoders for H.264 are more
widely available than platform CDMs.

 * When a hardware H.264 decoder isn't available and the CPU is fast
enough, a software decoder gets to decode all (non-DRM) H.264 content.
When a hardware CDM is not available, a software CDM doesn't get to
act as a substitute in the general case even if the CPU was fast
enough.

 * When a platform decoder is unavailable, there are no architecture
is prohibited from receiving a fully-functional (subject to CPU speed)
H.264 as a software installation delivered by someone other than the
platform vendor assuming that the platform allows software
installation at all. When a platform CDM is unavailable, the platform
cannot receive a fully-working CDM as a software installation
delivered by someone other than the platform vender and the how far or
close to fully-working you are allowed to get depends on the
characteristics of the underlying platform.

 * The CDM problem includes the H.264 problem (because a CDM is
expected to play H.264 content) but the solution space is restricted
compared to the solution space for non-DRM H.264 decoding, because you
don't get to delegate to an H.264 component that doesn't live inside
the DRM realm.

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Thursday, 16 January 2014 15:13:53 UTC