Re: Secure release and persistence

On Wed, Apr 29, 2015 at 9:29 AM, David Dorwin <ddorwin@google.com> wrote:

> 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].
>

​Well, the F2F agreed to give me an action to provide the remaining
specification details [4] and I in turn object to the removal of much of
the existing specification of this feature, which you did last week under
the guise of a "name change".


> There is still no data justifying the need to add this new requirement to
> all implementations
>

​It's optional.​


> nor has there been consideration of available alternatives.
>

​License renewal is an alternative which has been extensively discussed,
has significant dis-advantages and also remains underspecified ​


> 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.
>

​No, this is not required by our use-case and the more detailed
specification I will provide this week will make that even clearer, as
detailed at the top of this thread.​


>
> 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).
>

​The use-case and feature definition have been present, first in the
original specification and later in the wiki, since the beginning of the
work (i.e. several years). I'm happy to refresh this as I understand you
may have removed some of this from the wiki recently.


> 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.
>

​As I have already explained several times, the user benefit of this
feature over license renewal is that streams-in-progress do not fail when
there is a loss of connectivity to the application server or an application
server outage.​ Put another way, this feature enables detection of
concurrent stream limit fraud without imposing real-time requirements on
the application servers. This is both an architectural advantage
(non-real-time systems always being simpler than real-time ones, on many
axes) and a user experience benefit.

It's hard to quantify the benefit and unnecessary to the justification, but
nevertheless I am working on this.

So, I agree with steps 1-3 and they have been completed (modulo restoration
of material you have deleted from the wiki).


> 4. The group discusses and attempts to reach consensus on a solution for
> #1.
>

​You are treating this as a brand new feature request wheras I consider it
a feature that has been present since day one. It is already supported by
two User Agents. Whilst concerns have been expressed previously, the
outright opposition is ver​y new. I had expected those earlier concerns to
be addressed through the interaction between implementation experience and
specification development. Given the implementation status we are ready to
complete the specification work. Just because your position changes from
concerns (which I am addressing in this very thread as well as before) to
opposition does not set back the feature to a square one requirements
discussion.

...Mark


> [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
>

​[4] http://www.w3.org/2015/04/16-html-media-minutes.html#action01]​


>
> David
>
> P.S.
> "Record of license destruction" was only intended for “persistent-license”,
>

​Whatever your intention, what was actually in the specification until your
recent changes applied this to both ​“persistent-license” and
“persistent-release”.


> 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.
>>
>>
>>
>>
>