Re: I strongly urge all supporters to reconsider the EME proposal. It is not in your best interests!

Sent from my iPhone

On May 19, 2013, at 11:16 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

On Sun, May 19, 2013 at 8:32 PM, Mark Watson <watsonm@netflix.com> wrote:

>
> In practice, DRM is often implemented by the platform. On mobile phones
> and increasingly on TVs there are Trusted Execution Environments running a
> separate OS which provide decryption, decoding and rendering. In these
> cases, EME just exposes to the web platform what the (main) OS already
> exposes to apps. If you want the Web Platform
> to be a competitive OS, you need parity with the competition.
>

Isn't the above also basically implying that devices/systems that currently
don't bake DRM deep into the system need to start doing so in order to be
competitive with "smart" TVs?


If they want to have access to the same content at the same quality as
Smart TVs, yes.


Currently, Windows 8 includes PlayReady as a system component, but it's
available to Windows Store apps and it's unclear whether it will be
available with EME-suitable API surface for Metro-style enabled desktop
browsers or plain desktop browsers. Older versions of Windows don't have
that. XP doesn't even have the Protected Media Path and there are still a
lot of users of XP. Desktop Linux doesn't have DRM as a system component.
OS X clearly has something that enables HD rentals in iTunes to the
studios' satisfaction, but it's not suitably exposed to non-Apple
developers. From ICS onwards, Android has a framework for pluggable DRM
back ends, but there are a couple problems. First, the framework isn't
designed to enable EME, so the API surface offered by the framework itself
is not suitable for exposing EME. The DRM plug-ins themselves could expose
whatever additional API surface, but it appears that the providers of the
DRM plug-ins aren't in the habit of publicly documenting the API surface
they expose. Second, the repertoire of DRM plug-ins varies from device to
device and it appears that there's only one DRM plug-in on whose presence a
developer might reasonably be able to rely: Widevine DRM plug-in.
Apparently this isn't good enough in practice, since there seems to be a
market for downloadable DRM solutions that app developers can license for
inclusion into their app bundles.

So the distance between the status quo and a situation where downloadable
browsers provided independently of the OS vendor could rely on system DRM
for EME back end is pretty large.


Yes, I agree it's a mess right now. We're working on it.

Its been suggested that EME bug 20944 could be at least partially solved if
platform APIs used by one browser to implement EME were open to be used by
other browsers.

...Mark


(The situation where a browser provided by the OS vendor can rely on system
DRM for EME back end is, of course, already reality on Chrome OS and
presumably within reach for IE on Windows 8.)

-- 
Henri Sivonen
hsivonen@hsivonen.fi