Re: Comments on the EME opinion

On Sat, Oct 18, 2014 at 12:08 AM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
>> Do you mean out-of-band communication with the key server or also out-of-band communication with an individualization server?
>
> I must confess that the issues you brought up here are not at all what we had in mind. In particular individualization is not an area we looked in to very much. It seems that's encapsulated in a non-normative note about "an initialization or provisioning process"?
>
> In any case, this wasn't the kind of out-of-band communication we were attempting to prohibit.

What kind then? The spec, at least as of today says:
"All messages and communication to and from the CDM, such as between
the CDM and a license server, MUST be passed through the user agent.
The CDM MUST NOT make direct out-of band network requests. All
messages and communication other than those covered in the following
paragraph MUST be passed through the application via the APIs defined
in this specification. Specifically, all communication that contains
application-, origin-, or content-specific information or is sent to a
URL specified by the application or based on its origin, MUST pass
through the APIs. This includes all license exchange messages."

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124 about the
spec needlessly requiring application/origin-independent
individualization to happen out-of-band.

>>> 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?
>
> The former is definitely one concern. The question is not necessarily "which key system has a design like this", but instead, "can I design a spec-complaint key system that does this?" This wouldn't necessarily be for nefarious purposes; e.g. it could simply be easier for a key system to implement certain functionality by sending executable code to the CDM in order to implement certain features. The issue is really that EME messages and license requests can contain *anything*, according to my understanding.

I see.

>>> 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.
>
>> 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.
>
> The simplest attack we are considering here is a HTTP page using such a code-executing CDM talking to a key server over HTTP. In that case an attacker could modify the EME messages sent to the page in order to execute arbitrary code. Whereas, if EME were only usable on secure origins, this would not be possible.

I think this assessment is incorrect. If you have a CDM that executes
"arbitrary code" from EME messages and you have an attacker capable of
forging network packets, if EME restricted to https, the attacker
simply carries the attack as follows:
 1) The attacker legitimately purchases a domain name and legitimately
acquires a certificate for this domain.
 2) The attacker serves the page from this domain, over https, such
that immediately upon loading the page, a JavaScript program uses EME
to execute "arbitrary code".
 3) The attacker intercepts a completely unrelated plain http request
(and in practice there will always be some) and forges the response to
include a redirect or an iframe that causes the victim browser to
navigate to the attacker -controlled https site.

Thus, if the Key System is dangerous enough in terms of how the CDM
processes EME messages that you have to limit who gets to send EME
messages to the CDM, requiring https alone is placebo. You also have
to have a permission system that allows different treatment for
different origins (in which case, as you note, you need https for the
permissions to be meaningful in the face of an attacker capable of
forging network packets).

>>> 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?
>
> Is it necessary for something bad to happen before we say in the spec that it's bad? That is a large purpose of the TAG review, and a them that comes up again and again in your questions.

Well, there's a difference (at least for the purpose of assessing how
bad the situation is) between commenting as if doom is imminent in
practice and commenting to pre-emptively address theoretical concerns.
I'm OK with the TAG requesting theoretical concerns to be addressed
pre-emptively if the requests can be clearly understood to be about
pre-emptive theoretical concerns as opposed to being immediate
practical concerns.

> As for the walled gardens, we'd rather see such walled-gardens be non-compliant than say nothing and accommodate them.

FWIW, I think the only walled-garden-relevant EME caption
accessibility question is:
If video plus U.S.-style captioning data are entangled in an MPEG-2
video track and DRM applies to the whole track, can the captioning
text be piped to text-to-speech (why?) or a braille display on the
client? (Presumably, the module that can render DRMed MPEG-2 video
will be able to overlay the caption visually within the same module if
the design is at all sane in the light of U.S. captioning requirement.
In the European case, subtitles are bitmaps to begin with and, AFAIK,
separate tracks.)

I wouldn't object to the TAG requesting pre-emptive spec language on
this point, but good luck with cable company Members or Members who
are technology suppliers for cable companies. :-(

>>> - Independent content providers should be able to use EME to protect their content just as easily as large media companies.
>>
>> 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.
>
> I think you are assuming that this is a zero-sum situation. The collection of bullets (in whatever order) seems like a good set of principles, and I'm surprised you disagree with them.

Whether it's zero-sum is unimportant. Do you disagree that if the cost
of developing and maintaining a CDM and making sure you are permitted
to ship it and making sure your CDM is permitted to decrypt the sort
of content that users want to watch couldn't be recouped from the
server side, browser vendors would have to internalize that cost? In
terms of opportunity cost, i.e. what other Web features browser
vendors could develop with those resources, do you think it's a good
trade to give those who deal with Hollywood a free ride in order to
enable indie content providers to entangle their stuff in DRM, too?

Sure, that sort of trade make sense sense if you think DRM is a good
thing like any other Web Platform feature that everyone should have,
but if you don't, making that trade as a matter of principle (if
*they* have it, *everyone* must have it, even if it's not a good thing
to have) makes less sense. Also, it might make sense from a Googly
perspective considering that judging from "Google does not assess
license fees for the Widevine product." Google apparently has decided
to internalize the cost of DRM, but I don't think it's automatically
good policy to force all browser vendors to be like Google (or not be
browser vendors if they can't be like Google).

> Is there another web API that effectively requires fees and agreements on one or both ends?

All browser behaviors that are conditional on the site having a
publicly trusted certificate for https effectively require fees on one
side. (Even if your site is eligible for a "free" cert from StartSSL,
you are provisionally liable for a $25 revocation fee if events
requiring revocation per the terms of service occur. As for
CloudFlare, it's them, not you, terminating TLS and I bet they pay
they CA partners *something*.)

> Non-royalty-free codecs are the closest, and those have had the disturbing effect of segmentation.

Yes. As noted below, non-RF codecs and the cost of shipping a CDM are
intertwined.

>>> - 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.
>
> This is a prime example of something that should probably be moved elsewhere, but since it's a very interesting topic, I can't resist: How would you recommend solving the codec problem? Browser vendors have a role here too, from what I understand, e.g. in supporting RF codecs with EME.

I think the question of what it would take for the relevant services
to want to use RF codecs is a question best answered by
representatives of the relevant services.

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

Received on Wednesday, 22 October 2014 08:44:15 UTC