Some comments on the draft TAG EME paper

All,

I reviewed the paper at https://github.com/w3ctag/eme/blob/master/README.md

Introduction:
- It might be worth noting that restricted access to content on the web
might be preferable for some to no access to that content, or to access
being available only though non-web / legacy technologies. Otherwise
there's an implicit comparison between restricted and unrestricted access
even for content where the latter is not an option.
- This may not be material here, but it is not proposed to include EME in
HTML proper. It's a separate, optional, extension specification.

Examples of restricting content:
- Whilst authentication is clearly an example of restricting access to
content, it's odd to characterize it as "breaking the web". Each user sees
the universe of content they are authorized to see (because they have paid
for access, for example, or work for a specific company to whom that
information is confidential). The web is not "broken" within that universe.
I may not be able to use the sharing features of the web to share company
confidential information with you, or to give you access to paid content
without you paying, but nothing is "broken" with that.

Platform independence:

"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. So, yes, this principle
can obtain in a tautological sense for protected content, but I don't think
this is what you mean. You may mean that licensors should not be allowed to
specify licensing terms that restrict the platform used to access the
content. Or, you may mean that all platforms must adapt to meet the
requirements of those licensing terms. Or that the licensing terms must
change so that all platforms meet the requirements. Or something else. The
first is surely a legal / social / political question, not one of technical
architecture. The second is challenging, if not impossible: it is hard to
*force* all platforms to meet certain requirements, especially when some
people who build platforms are opposed to those requirements on principle.
The third is again a legal / business question. Please clarify which you
mean or if you mean something else.

"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. Our business is based on very transient content - streams - which
are made available to a user for viewing at the time they are requested.
They may legitimately not be available at some later time because the user
is no longer a subscriber or because our license for the content expired.
Platform limitations apply only in the moment and have no implications for
the future. The "lifetime" of the stream is the time spent viewing it
online. That this lifetime is limited is not against consumers best
interests as this is one aspect which allows our business to offer the
price point that it does, which may consumers find attractive.

Applying the principles to EME

The focus on encryption (as Henri Sivonen pointed out) is misplaced. It has
always been clear that the main purpose of EME is to provide a common API
for DRM systems. (Perhaps we should have chosen a different name for the
specification, but even with the existing name noone can claim to ever have
been in any doubt).

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.

What is proprietary is two things: the mechanism by which a key is
delivered to the "black box" and the mechanism by which the key, and
decrypted content, are prevented from leaving the "black box" except in
certain forms (decoded frames in some cases, through direct interaction
with rendering hardware in others). This second is usually termed
"robustness".

"The EME specification must ensure platform independence, for example by
specifying the use of open standard encryption algorithms."

I interpret this as suggesting the EME specification ensure platform
independence of the whole DRM solution, not just those things specified in
the EME specification. It's hard to understand how EME can place
requirements on things outside EME, so is the implication of this statement
that the scope of the EME specification be extended to include the DRM
solution ? As it stands, the statement is like insisting that <object> be
platform independent - i.e. that <object> ensure all plugins are platform
independent. If this requirement doesn't apply to <object>, why does it
apply to EME ?

The EME specification does specify the use of open standard encryption
algorithms, but this is not sufficient to "ensure platform independence"
for the whole solution. In stating a requirement to "ensure platform
independence" I think it is necessary to have some idea as to how this
could be technically possible.

Security

It is unclear to me why the CDM component, which is outside the scope of
EME anyway, should be subject to requirements that do not apply to User
Agents themselves (the code of which is not always available for public
inspection).

Layering

Building a DRM system in Javascript is an interesting idea but should be
scrutinized a little to determine if any practical realization of that is
even possible and if so whether it would actually have the properties that
are claimed.

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. 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. We have advocated support for this kind of thing
in WebCrypto, but it seems only relevant to certain kinds of embedded
platform, not the web generally.

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". It was an
object of EME to define a "minimal" shape for the "black box" - certainly
to vastly reduce the scope compared to today's solution (Flash and
Silverlight). It's true that with the suggested approach the box is no
longer opaque - we can know exactly what it contains - but this is also
possible with the existing EME structure - there do exist open source DRMs.
I think the proposal might suffer from many of the same hurdles, especially
the business infrastructure needed to support secure attestation of TEE
robustness.

...Mark