Comments on the EME opinion

In reference to
https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md ;
quotes from that document.

> CDM, which encapsulates unspecified behavior necessary for robustness.

Note that the CDM encapsulates not only robustness but the key
acquisition protocol (Key System) as well.

> It should be possible for a single web application to support multiple key systems, without writing code specific to each one

This is already mostly true for JS, in theory. However, since each Key
System needs a different server back end, some dispatch code is needed
on the server at minimum. Also, in practice each Key System is coupled
with a different browser and each browser has a different snapshot of
EME, so at least at present, JS code needs to abstract over the
different EME snapshots. Supposedly this is a temporary state of
affairs and browsers eventually catch up with the spec and the spec
stops moving.

> The goal of EME should be a common-denominator API that can be used to interface with all DRM systems equally.

Which parts of the *API* do you see not satisfying this request? (Of
course, the API passes opaque byte buffers, so anything might be
communicated in those.)

> Out-of-band communication (via the CDM or otherwise) should not be possible

Do you mean out-of-band communication with the key server or also
out-of-band communication with an individualization server?

You don't need Key System-specific JS for individualization if
 * The CDM doesn't need a downloaded individualization blackbox (IBX).
(See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c79 for how
that could be possible in the hardware case. In the software case it
could be possible by the CDM binary itself being individualized upon
delivery so that each user ends up with a different CDM binary to
begin with.)
 * The CDM downloads the IBX out of band. (Is this something you disapprove of?)
 * The IBX download is proxied by the key server, so the IBX request
and response are just another EME message pair from the JS
perspective. (See option #1 in
http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0006.html
)

You do need Key System-specific JS for individualization if
 * The JS program is expected to notice EME messages that are IBX
requests and XHR them to an individualization server rather than the
key server. (See option #2 in
http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0006.html
)

This latter option seems to be something you might like, because
there's no out-of-band communication, but also something you might not
like, since it involves coding knowledge of key system or CDM-specific
individualization server location in the JS program.

Which of the above options don't you like and why?

> The ability of the CDM to potentially run arbitrary code is a hole in the web platform’s security model.

Do you mean the CDM taking code via an EME message or a PSSH box and
running the code? Which key system has a design like this? Or do you
mean this becoming possible via unintentional vulnerabilities in the
CDM?

> To the extent that they cannot be, e.g. for robustness reasons, we should restrict access to those features such that they can only be used from secure origins, so as to make them less accessible to attackers.

It would be useful to elaborate on which attacks you hope to mitigate
with that suggestion. (See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c48 and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c70 for an
enumeration of attacks you might want to consider.) Surely, if your
concern is the CDM executing code received via an EME message or a
PSSH box, requiring the attacker to get a publicly trusted certificate
and deploying https in order to access the code injection vector isn't
much of a fix.

> Speaking to both of these areas, the way in which the CDM currently provides a potentially-permanent
> cryptographic identifier to identify the client or user is troubling. It can serve as an unspoofable
> user-agent string, with all of the attendant risks, and is a glaring privacy hole. Again, if nothing
> else, this kind of power should not be given to arbitrary coffee-shop attackers, and thus should
> be limited to secure origins.

Coffee-shop-level attackers probably aren't going to obtain a key
server that speaks the Key System, so to hide the ID from them, it's
sufficient for the EME messages to be individually encrypted (as part
of the Key System) so that the ID can only be extracted by the key
server. (There may be other kind of attackers who'd have the resources
to operate rogue key servers.)

> Another attack we are concerned about is the possibility of proprietary/encrypted license
> formats to decieve the user. The user agent should be able to read license the response
> and present that information to the user.

Can you elaborate on this concern? In the use case driving EME
(streaming), wouldn't you expect the application to take care of
potentially reobtaining DRM licenses from the key server in a way
that's an implementation detail from the user perspective? I.e. why
should the user need to know how often the licenses get refreshed?
It's not customary to seek to surface HTTP cache expiry times to the
user, either.

If you are worried about EME getting put to use for purchase-to-"own"
scenarios where the user needs to care about moving around media files
and the associated DRM licenses in an off-the-Web way, I suggest
condemning that use case specifically instead of suggesting that
implementation details of the use case driving EME be exposed to
users.

> Specific examples include ensuring the correct interaction with high-contrast mode

Is it actually customary for high-contrast mode to affect video
content in non-DRM cases? A quick cursory test with Windows 8.1
suggests the answer is no.

> and captioning systems.

Besides indications of interest to use EME with MPEG-2 video streams
that base U.S.-style closed captioning data into the "video" track in
settop boxes for walled gardens, do you see indications of any
general-purpose browser implementing support for restricting captions
using EME-style DRM or any indications of a video service serving
multi-ISP audiences (and not confined to the walled garden of a cable
company) seeking to restrict captions using EME-style DRM?

> - Independent content providers should be able to use EME to protect their content just as easily as large media companies.

As noted in http://lists.w3.org/Archives/Public/www-tag/2013Oct/0058.html
, I think this goal, especially as the first goal, is completely
misguided. It's frustrating to see the TAG not only include this item
but to put it as the first item on this list. ಠ_ಠ

In addition to what I wrote a year ago, consider this:

The CDM is the part of a DRM system that's costly to develop and to
have the permission to distribute (on the simplest level, see below
about the CDM having to contain an encumbered codec implementation).
Yet, it's the part that needs a broad installed base and, therefore,
needs to have a low externally-visible price, ideally zero. The key
server doesn't really have any magic to it, but it's the part that's
closer to the source of the DRM requirement. When the DRM system can
be monetized from the server license fees, the cost of the system is
shifted closer to the source of the requirement to have DRM in the
first place. (Shifted to the streaming services which are closer to
the source of the requirement, i.e. the studios.) If you make things
such that the server side becomes cheap or free, you are essentially
giving the source of the DRM requirement a free ride while the cost of
the negative externality they impose is borne closer to the user (e.g.
by whoever ships a browser or a browsing device).

If you don't like DRM (and it seems that you don't) you shouldn't want
things that shift the cost of the system away from the source of the
requirement and towards the entities closer to the user.

> - New browser vendors should be able to add EME support to their browser based
> on open standards, without needing to license technology. This should ideally be
> possible both for new desktop browsers and for new mobile browsers or new devices.

This is a fine goal, but you should first get the services that want
to use DRM to want to use an RF video codec, because robustness, in
practice, means putting the video codec inside the robustness
rule-governed realm, which means that e.g. in the case of dealing with
H.264, the solution space is severely limited compared to the solution
space in the non-DRM case. That's why I think it's harmful to try to
solve these problems in the wrong order. You should solve the video
codec royalty problem *first*. And I don't mean just by observing that
RF codecs *exist* but by arranging circumstances that make the
relevant services to want to use them.

> - New key systems should be able to join the EME ecosystem by implementing an open standard.

What does this even mean? Do you use "key system" to mean something
other than the DRM key acquisition protocol?

> - Content providers should be able to implement and interface with multiple key systems
> via the same code, without dealing with inconsistency in feature sets or behaviors.

Do you mean you want to standardize server-side APIs, too?

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

Received on Thursday, 16 October 2014 10:04:14 UTC