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

Unsurprisingly, I agree with Henri, but I also wanted to point out that #2
is already happening: we are working with multiple partners who are having
to add proprietary hooks to their EME implementations for secure release as
a result of this impasse on the specification.

...Mark

On Fri, Jun 12, 2015 at 4:32 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> 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
> kind).
>
> > 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.
>
> See:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/gmp-api/gmp-async-shutdown.h
>
> https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/gmp-api/gmp-storage.h
>
> https://dxr.mozilla.org/mozilla-central/source/dom/media/gmp/GMPParent.cpp#206
>
> 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
> later.
>
> 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
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>
>