Re: Secure release and persistence

While I welcome further clarification on Netflix's feature, I object to
further specifying it in the spec for the reasons described in issue 45
[1], specifically [2]. There is still no data justifying the need to add
this new requirement to all implementations nor has there been
consideration of available alternatives. Both are important prerequisites
for adding features to the web platform. Furthermore, Netflix's stated use
case - whether mentioned in the spec or not - requires a fundamental
violation of the web platform architecture: the CDM/media stack delaying
application shutdown.

Based on these important concerns, clear lack of consensus, continuing
confusion about this feature even among the editors [3], and lack of data
or experimentation, it is still too early to include this in the spec and
require it of all implementations.

Even with Mark’s description below, there is still confusion about this
feature [3]. I propose the following next steps for Mark’s feature request:
1. Mark clearly defines (all) use case(s) for this feature (perhaps in the
wiki or a doc).
2. Mark clearly defines the feature he is requesting (perhaps in the wiki
or a doc).
3. Mark provides justification for adding this feature, including data on
alternatives considered and experimented with as well as user benefit of
this feature over alternatives.
4. The group discusses and attempts to reach consensus on a solution for #1.

[1] https://github.com/w3c/encrypted-media/issues/45
[2] https://github.com/w3c/encrypted-media/issues/45#issuecomment-91743387
[3] https://lists.w3.org/Archives/Public/public-html-media/2015Apr/0067.html

David

P.S.
"Record of license destruction" was only intended for “persistent-license”,
but it is similarly restrictive for implementations. I’ll change it to
something like "persist an invalidation of the license." Other wording
suggestions welcome.

On Tue, Apr 28, 2015 at 8:02 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> Hopefully this will catch you in your newly-freed "EME hour" :-)
>
> As promised at the F2F I will draft spec updates this week to fill in the
> missing details of this feature. However, I would like to make one
> significant change in response to comments at the F2F and previously
> regarding exactly what is persisted.
>
> The spec describes persistence of a "record of license destruction". Aside
> from the fact that we have no concept in our spec of "license", this is not
> typically how this feature is implemented in DRMs and suggests a need to
> persist data at close / shutdown / crash or other events that cause license
> destruction.
>
> In practice, what is persisted  is a record of available keys at a point
> in time. This is updated regularly *during streaming*. There is no update
> on close / shutdown / crash. In a later browsing session, this record is
> compared with the actually available keys and a discrepancy is taken as
> evidence that keys were destroyed.
>
> I propose that we describe this persisted data explicitly as "for each key
> in the session, the *first decrypt time* and the *latest decrypt time*".*
>
> Are there any comments on that before I implement it ?
>
> Based on this change in description, I suggest we call this session type "
> *tracked*" - or something similar - since really we are 'tracking' the
> usage of keys. This name will also invite appropriate scrutiny of the
> persisted data properties.
>
> ...Mark
>
> * there may of course be other CDM-specific information persisted and
> included in the release message. For example if the CDM has a concept of
> licenses, then license correlation identifiers may be present. Also, how
> the CDM communicates time in its messages may be CDM-specific.
>
>
>
>