Re: Some comments on the draft TAG EME paper

On Fri, Feb 28, 2014 at 2:25 AM, Mark Watson <watsonm@netflix.com> wrote:
> - This may not be material here, but it is not proposed to include EME in
> HTML proper. It's a separate, optional, extension specification.

That indeed doesn't seem material.

> "If a user is authorised to access a piece of content, they must be able to
> do so on a platform [browser, operating system, hardware] of their choice."
>
> We have a situation - like it or not - where the licensing terms for some
> content constrain the platforms on which it may be viewed. So a user cannot
> even become "authorised to access a piece of content" unless their "platform
> of choice" is within that specific set.

In other words, DRM involves a cryptographically attested form of UA
sniffing in order to cater for intentional incompatibility and it's
likely illegal for the victim to take countermeasures by faking its
identity. (As seen in
http://blogs.msdn.com/b/ieinternals/archive/2014/02/19/internet-explorer-and-everybody-else-version-lies-for-compatibility.aspx
, countermeasures are often necessary and often taken when allowed.)

> "Creating content that can only be used on a particular platform limits the
> lifetime of that content. Content with a limited lifetime is contrary to the
> best interests of consumers of that content.
> "
> There is an assumption here that the content is naturally persistent in some
> way.

It seems to me that many opinions related to EME are based on
assumptions that don't hold for the primary use case of EME (i.e.
streaming in general and on Netflix in particular). That is, opinions
tend to often assume a model where there's a single file per title (as
opposed to multiple fragments of content assembled by a JS program
using MSE) and even that the file is sold to the user to hold onto (as
opposed to the data existing on the client device only ephemerally
when playback is invoked on a streaming site where access is sold on a
time window basis).

> It has always been clear that the main purpose of EME is to provide a common
> API for DRM systems.

Indeed.

> In fact the encryption technologies specified by EME *are* platform
> independent and even DRM-independent. The Common Encryption specification
> for ISO files specifies exactly how the content is encrypted and there is
> nothing proprietary about that.

For completeness:

1) Since the W3C doesn't generally reference media format normatively,
the EME references to CENC and WebM crypto are not normative. However,
it's fair to expect that most EME deployments will likely use CENC, as
that's already seen as shipped and deployed. Still, EME leaves
available the option to have DRM-dependent encryption formats. Such
formats aren't just theoretical, since, AFAICT, iTunes movie rentals
use non-CENC DRM packaging in the MP4 container.

2) Even though the actual media data in CENC files is DRM-independent
(and the possibility to define something like Clear Key theoretically
makes whether a file is DRMed at all not a property of the file
itself[1]), CENC headers are DRM-dependent. That is CENC packaging
involves Protection System Specific Header (PSSH) boxes. So the file
is DRM-independent except for its headers. However,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027 has potential to
yield a general-purpose PSSH format, so, in theory, CENC files could
become truly DRM-independent in the future if CDM vendors decide to
support the upcoming Clear Key PSSH format for their proprietary DRM
Key Systems.

> As it stands, the statement is like insisting that <object> be
> platform independent - i.e. that <object> ensure all plugins are platform
> independent.

Indeed.

> It is straightforward to imagine, for example, that WebCrypto might provide
> the primitives necessary to implement a DRM key exchange protocol in
> Javascript. For such a thing to meet robustness requirements, the
> implementation of the cryptographic primitives would need to be within some
> kind of Trusted Execution Environment.

(Other readers of www-tag may want to read
http://www.openvirtualization.org/open-source-arm-trustzone.html as an
intro on the TEE topic.)

> To ensure platform independence, this
> TEE and its robustness requirements would need to be standardized and
> present on all platforms, but this is likely not possible in Free Software,
> for example. Furthermore, some mechanism would be needed for this TEE to
> attest to its properties, meaning inclusion of secret keys from some
> authority that vets the TEE implementations / deployments. Essentially, this
> idea exports several of the properties / requirements of DRMs into the
> WebCrypto implementation.

Indeed. To avoid that, the JavaScript program should refrain from
using Web Crypto and should instead implement the necessary algorithms
itself in an obfuscated form.

> We have advocated support for this kind of thing
> in WebCrypto,

The use cases stated in the KeyWrap proposal indeed seem to duplicate
use cases that one would expect an EME Key System to address, as noted
in http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Oct/0013.html

> but it seems only relevant to certain kinds of embedded
> platform, not the web generally.

Indeed. So why advocate it then? Is the purpose of the KeyWrap
proposal to enable Netflix to have DRM without a device
vendor-provided EME CDM on systems that are Tivoized so that it's
possible to reason about the characteristics of the software running
on the device from a device identity attestation coupled with prior
knowledge about promises made about the nature of the software and
future software updates by the device vendor? Why wouldn't vendors who
are willing to Tivoize their devices, provide identity attestation
keys and make promises about the nature of future software updates not
include a CDM while at it?

> One could further imagine that WebCrypto support a mode in which the output
> of decryption operations is some handle to the data, not the data itself and
> that there are media APIs which can accept such handles as a source of data
> for playback. The same TEE that contains the WebCrypto primitive
> implementations would provide the underlying support for these media APIs
> and decode and render the media. This begins to look less like exporting DRM
> properties into WebCrypto and more like simply bringing WebCrypto into the
> DRM "black box".

And, more to the point, as noted, it would not be just Web Crypto but
also parts of the media stack. Going this route instead of the route
that has a clear User Agent / CDM split could easily lead to a
situation where the simplest solution is to let the whole browser fall
into the DRM box instead of trying to maintain a separation between
the parts of the browser that are in the DRM box and the parts that
aren't. As long as the TAG can concerns about browsers becoming
subject to anti-circumvention, the TAG should not advocate paths that
could easily lead to the entire browser (engine) falling inside the
DRM box.

> there do exist open source DRMs.

...but the ones cited so far seem to have relied on Tivoization for
robustness and, therefore, wouldn't work e.g. on the existing desktop
systems.

[1] Schrödinger's CENC file has both PlayReady and Clear Key PSSH
boxes, so the file is DRMed and not DRMed at the same time. In other
words, the DRMness depends not on the file but on the conditions under
which the key is provided.
-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Friday, 28 February 2014 11:44:27 UTC