- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Mon, 20 May 2013 09:16:14 +0300
- To: Mark Watson <watsonm@netflix.com>
- Cc: "piranna@gmail.com" <piranna@gmail.com>, Jeff Jaffe <jeff@w3.org>, "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>, Emmanuel Revah <stsil@manurevah.com>
- Message-ID: <CANXqsRLNJxmpsF2esa4P3Qyzu_Luf1Y7JBjpG2Fb3ekfi=dbBA@mail.gmail.com>
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? 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. (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
Received on Monday, 20 May 2013 06:16:46 UTC