W3C home > Mailing lists > Public > public-html-media@w3.org > June 2015

Re: [EME] Netflix’s secure release is unreliable without tamper-proof secure persistent storage and/or delayed shutdown

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Fri, 12 Jun 2015 14:32:27 +0300
Message-ID: <CAJQvAueX_PsTAjaVP9yEC=vCnpQ23qTyUdLR2gtU1fFKbosYdw@mail.gmail.com>
Cc: "public-html-media@w3.org" <public-html-media@w3.org>
On Fri, Jun 12, 2015 at 3:19 AM, David Dorwin <ddorwin@google.com> wrote:
> Unless there
> is a solution that can be equally and reliably implemented across the wide
> breadth of web platform clients, we do not believe secure release has a
> place in EME.

Considering these alternatives...

 1) No secure release in either CDMs or EME.

 2) Secure release support in CDMs but not in EME; JS has to dispatch
on flags inside the supposedly opaque EME message data or on
vendor-specific EME extensions.

 3) Secure release support in CDMs and in EME.

...it seems to me that from a UA perspective, #1 is the best option,
but #3 is better than #2.

I'm worried that by withholding enum values from the EME spec to try
to force #1, we may not actually end up with option #1 but with option
#2. And if that happens, we'd be better off with option #3. To end up
with option #1, the right method isn't withholding enum values from
the spec but showing that there's a better way such that those who now
want to do secure release no longer want to do it.

I think there are parallels to the "individualization-request" issue
(though that feature is truly optional in the sense that if you have a
CDM that doesn't do download-based individualization or you have a CDM
that does it out of band, then you don't need to emit messages of that

> For some
> CDM implementations, this may be simple because they run as a separate
> process, but others, such as those that rely on the user agent for storage,
> may require that the hosting user agent delay shutdown until such writes are
> committed.

FWIW, Firefox supports asynchronous CDM shutdown, which allows the CDM
to still use (within a finite time window) the storage API provided to
the CDM before the CDM stops running. (The CDM sandbox doesn't allow
direct file system access by the CDM.) Obviously, not to have this
complication would be simpler.


Firefox does nothing to ensure the integrity of the stored data. It is
assumed that the data that the CDM passes to the storage API is such
that the CDM itself can verify its integrity upon reading it back

Firefox provides UI for deleting the stored data. Additionally, the
user could make a copy of the stored data and overwrite subsequently
stored data with the old copy without Firefox noticing.

Henri Sivonen
Received on Friday, 12 June 2015 11:32:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:02 UTC