RE: Secure release and persistence

I believe we agreed not to take action on removing any portion of this feature until Mark completed Action 85, due next week.  This action may not address all of your concerns (likely not), but was intended to at least address spec completeness on this feature.

I do not share your concerns about making this feature optional.  It would likely be useful to identify abusers even if only supported on a subset of browsers.  I doubt very much that it would be used to limit the user experience on browsers that do not implement it.

Jerry

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Wednesday, April 29, 2015 9:58 AM
To: David Dorwin
Cc: public-html-media@w3.org
Subject: Re: Secure release and persistence



On Wed, Apr 29, 2015 at 9:29 AM, David Dorwin <ddorwin@google.com<mailto: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<mailto: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.