Re: Secure release and persistence

The tone of this thread has turned for the worse. I've addressed some of
Mark’s comments below, but I'll wait for #1 and #2 before replying further.

On Wed, Apr 29, 2015 at 9:57 AM, Mark Watson <watsonm@netflix.com> wrote:

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

I believe #1 and #2 are consistent with [4]. It doesn't make sense to
“provide... technical recommendations” for a problem that isn't fully
defined.

I’m not sure why you think I removed “much of the existing specification of
this feature.” Perhaps because there wasn't much actually specified, minor
deletions appear to be “much” of the specification. I assume you are
referring to the change to remove() (see below) or [5]. The main changes in
[5] other than the name were the removal of a) “generate a persistable
proof of license release”, which was incorrect, and b) specification of
what the license passed to update() must contain, which depends on further
definition of the feature. Both were replaced with "*TBD*."


>
>
>> There is still no data justifying the need to add this new requirement to
>> all implementations
>>
>
> ​It's optional.​
>

I disagree with this justification. As discussed at the f2f, optional
features are considered an anti-pattern because they either become required
to remain competitive or are never implemented. In this case, “optional” is
de facto required because Netflix (may) require it.

Regardless, there is no data justifying even the “optional” feature and the
resulting fragmentation.

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

I said consideration, not discussion. Specifically, there has been no
experimentation with the already available feature set. Only your
assertions that they will not work and Netflix will not consider them.

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

Are you saying that with this new solution, Netflix will not require *any*
user agents to delay shutdown and ensure that messages reach the server?

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

The use case has been unclear and there has never been a complete feature
definition. As an example, see the text from “the beginning of the work”:
[6]. Also, as far as I am aware, this thread is the first time that saving
decrypt times has been discussed publicly.

Yes, I removed the text from the wiki and added a note that the model has
not been explicitly defined. The text, much of which I had written, was out
of date, and I did not want it to add confusion to the ongoing discussion.

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

I disagree that steps 1-3 have been completed. Specifically, this thread
has raised new information. As I said above, I think steps 1-2 are are
prerequisites for [4].

The old wiki text is all there in the history. However, I highly doubt
simply reverting the deletion addresses these steps. We need sufficient
detail to understand the use cases, implementation requirements,
algorithms, and whether delayed shutdown might reappear as a requirement on
some platforms.

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

The definition you appear to be proposing is brand new. Earlier this month,
you were arguing for a different solution. If some of this information is
new to me and the public discussion, I find it hard to believe “It is
already supported by two User Agents.” Not to mention, there is no clear
definition of what “it” is. The spec process is more than just documenting
existing implementations. Features aren’t typically dictated by a single
site, either. Perhaps there are others that would like similar
functionality, but they would be excluded by the rubber-stamping of such
privately-developed definitions.

The spec started as a proposal for some simple APIs to perform license
exchanges. Through the spec process, including input from WG members and
the TAG, the importance of interoperability, fragmentation,
implementability, privacy, security, etc. have all become clearer. We've
also learned of additional use cases and discussed various user agent
implementations. Through this process, the bar for features and
functionality has been raised (to be consistent with the general spec
process). Having never been concretely defined and posing a number of
concerns, it seems reasonable for this feature to be expected to reach this
bar.

We have opposed this feature “since the beginning of the work.” At one
point, it was "allowed" due to underspecification. Five months ago, a
session type was added because we needed to specify behavior for a
different use case ("persistent-license"). A month ago, I accidentally
specified the remove() behavior was the same for both session types.

We have always strongly objected to any scenario that involved delaying
shutdown. There was a period of time where we were led to believe various
things were no longer required, at which time our opposition was lessened.
However, that turned out to be false and/or subject to change, and our
opposition returned. You'll have to forgive me if I'm cautious about any
new claims that delaying shutdown is off the table.


It’s worth noting that without such evolution to the group's approach to
the spec and our consistent pushback, delayed shutdown might well be a de
facto requirement for all implementations, including desktop browsers. If
we are now at a point (different from even earlier this month) where that
is no longer being considered, then I would call that a success for the web
platform.


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

There was one inadvertent case where this was the case. It was added a
month ago in the commit to ‘Define the behavior for "persistent-license"
sessions’ [7]. In your original email, you said it was incorrect for your
use case. Fixing this mistake and separating the session types still seems
like the appropriate action.

>
>
>> but it is similarly restrictive for implementations. I’ll change it to
>> something like "persist an invalidation of the license." Other wording
>> suggestions welcome.
>>
>
> [5]
https://github.com/w3c/encrypted-media/commit/71e4352d4a737f3cdba879217dc9daf74020751d
[6]
https://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1/encrypted-media/encrypted-media.html#key-release
[7]
https://github.com/w3c/encrypted-media/commit/76c48b4f0a171af89ed93c21745900ecbb75f7a2


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