Remove "persistent-release-message" MediaKeySessionType

Summary: It does not make sense to include a feature in the spec that is not a common or accepted practice, is not widely supported, and is fundamentally flawed. In addition, doing so will lead to an unsustainable series of requests for unimplementable features in the spec and/or implementations.

There is only one (thread) content provider planning to use the secure proof of key release for non-persistent licenses feature represented by "persistent-release-message". It is not a common practice, nor is there accepted consensus on its utility or effectiveness. Widely-accepted and supported alternatives are already supported by the spec and implementations. Including this optional feature in the spec unnecessarily increases the likelihood of platform fragmentation/segmentation: This feature is unrelated to content protection or robustness, yet a content provider reliant on it (and subsequent requirements) may deny content to clients that otherwise support the relevant levels of robustness.

In the March 17 telecon, Mark said "the system is very much dependent on getting these messages", including after the application has been closed (something that browsers and most user agents cannot support). He also said they (Netflix) "don't know what the frequency of these messages will be in the field" or how important the reliability of receiving the messages is to its effectiveness. He also hinted they may find more cases where they would want to report such messages. The mechanism is fundamentally unreliable - placing server responsibilities on every client yet expecting the reliability of the server - and thus begets additional troublesome feature to mitigate that.

Additional technical issues:

The mechanism is unreliable in a browser or other multitasking environment.^
This may significantly reduce its effectiveness and introduce user friction not present with the alternative solutions.^^
This has led to repeated requests (as recent as March 17, 2015) to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user. This is not something we can specify, and any attempt to make such behavior optional would likely lead to segmentation.
This session type is essentially a “persistent-license” session with a short expiration time. It introduces a requirement that CDMs be able to persist state even for “simple [online] streaming.” This raises the bar of entry for new implementations and/or may preclude some implementations/devices (including private browsing modes).

Note: This session type specifically relates to persisting a secure proof of key/license release of non-persistent licenses for later retrieval. It does not apply to release messages related to persistent licenses (“persistent-license” sessions) or even release messages from “temporary” sessions that do not need to be persisted.

^ Examples include the user closing the tab or browser, especially for clients that implement quick shutdown; the user closing a laptop lid; tab eviction (for limited resources, especially - but not limited to - on mobile devices); crashes. ^^ For example, if a user watching a video closes the laptop lid then goes to a TV to resume, the proof of key release will not have been sent and the user will be unable to resume until some timer expires or they open the laptop and stop the video there. This is not a problem with alternative mechanisms, which can gracefully handle the transition, or at least limit the duration of the problem.

Obviously, I disagree with the points below and with removing this feature. This use-case has been included since the very beginning of this activity.

I'll provide a more detailed response later, probably next week.

...Mark

Sent from my iPhone

On Mar 31, 2015, at 4:07 PM, ddorwin notifications@github.com wrote:

Summary: It does not make sense to include a feature in the spec that is not a common or accepted practice, is not widely supported, and is fundamentally flawed. In addition, doing so will lead to an unsustainable series of requests for unimplementable features in the spec and/or implementations.

There is only one (thread https://lists.w3.org/Archives/Public/public-html-media/2015Mar/thread.html#msg46) content provider planning to use the secure proof of key release for non-persistent licenses feature represented by "persistent-release-message" https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-release-message. It is not a common practice, nor is there accepted consensus on its utility or effectiveness. Widely-accepted and supported alternatives are already supported by the spec and implementations. Including this optional feature in the spec unnecessarily increases the likelihood of platform fragmentation/segmentation: This feature is unrelated to content protection or robustness, yet a content provider reliant on it (and subsequent requirements) may deny content to clients that otherwise support the relevant levels of robustness.

In the March 17 telecon http://www.w3.org/2015/03/17-html-media-minutes.html#item08, Mark said "the system is very much dependent on getting these messages", including after the application has been closed (something that browsers and most user agents cannot support). He also said they (Netflix) "don't know what the frequency of these messages will be in the field" or how important the reliability of receiving the messages is to its effectiveness. He also hinted they may find more cases where they would want to report such messages. The mechanism is fundamentally unreliable - placing server responsibilities on every client yet expecting the reliability of the server - and thus begets additional troublesome feature to mitigate that.

Additional technical issues:

The mechanism is unreliable in a browser or other multitasking environment.^
This may significantly reduce its effectiveness and introduce user friction not present with the alternative solutions.^^
This has led to repeated requests (as recent as March 17, 2015 http://www.w3.org/2015/03/17-html-media-minutes.html#item08) to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user. This is not something we can specify, and any attempt to make such behavior optional would likely lead to segmentation.
This session type is essentially a “persistent-license” session with a short expiration time. It introduces a requirement that CDMs be able to persist state even for “simple [online] streaming.” https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Simple_Streaming_of_a_Specific_Title This raises the bar of entry for new implementations and/or may preclude some implementations/devices (including private browsing modes).

Note: This session type specifically relates to persisting a secure proof of key/license release of non-persistent licenses for later retrieval. It does not apply to release messages related to persistent licenses ( “persistent-license” https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-license sessions) or even release messages from “temporary” sessions that do not need to be persisted.

^ Examples include the user closing the tab or browser, especially for clients that implement quick shutdown; the user closing a laptop lid; tab eviction (for limited resources, especially - but not limited to - on mobile devices); crashes. ^^ For example, if a user watching a video closes the laptop lid then goes to a TV to resume, the proof of key release will not have been sent and the user will be unable to resume until some timer expires or they open the laptop and stop the video there. This is not a problem with alternative mechanisms, which can gracefully handle the transition, or at least limit the duration of the problem.

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/45.

[Apologies if I am replying "wrong," but I can't see a way to make inline comments in Github. Also, Mark Watson commented here, but his comment doesn't appear on the public-html-media@w3c.org list (as David's did), so I'm not sure if an email reply to that list will show up here.]

Quoting David: "to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user."

Mark, can you specifically address how an implementation would design around this point? This is the core point of the feature (from a practical POV) that has always been hard for me to grasp.

I feel that it has relevance for us (JW Player) as our flagship product is a browser player. I read all the background, but I am still not understanding if are you suggesting that the key release proof be the responsibility of the CDM/UA or the web app?

I'm not comfortable with saying that proof of the release is "implementation defined," as some have suggested. I don't foresee JWP implementing this as a core feature of our products (unless it is a spec requirement, of course), but from an interop POV we might end up having to support it for a customer if it stays in the spec.

Sent from my iPhone

On Mar 31, 2015, at 5:40 PM, John Luther notifications@github.com wrote:

Quoting David: "to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user."

Mark, can you specifically address how an implementation would design around this point? This is the core point of the feature (from a practical POV) that has always been hard for me to grasp.

No, it's not a core point. Secure stop messages are persisted, so they are available later, next time the user visits the page. The security goals (detecting certain kinds of fraud) are easily met with this model.

I have pushed back, though, on the assertion that delivering such messages immediately in the 'tab closed' scenario is 'impossible'. I appreciate that it is difficult or impracticable in certain implementations but that does not mean there will never be implementations that support it.

Specifically, it's well understood that having a tab or window linger around for any period of time after the user tries to close it is a bad user experience. This just says that the user interface of the tab or window should not linger during any clean-up operations that take an appreciable time. Again, I appreciate that might be impractical in existing implementations, but that is due to implementation choices they have made. Further, in very different environments (TVs say) the whole user experience is very different from on a desktop browser.

Anyway, as I said, this point is not central: the secure stop messages get persisted and this is sufficient. Some persisted messages will be lost: user clears browsing data or never returns to the site, but this is also ok.

...Mark

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/45#issuecomment-88294352.

On Tue, Mar 31, 2015 at 4:07 PM, ddorwin notifications@github.com wrote:

Summary: It does not make sense to include a feature in the spec that is not a common or accepted practice, is not widely supported, and is fundamentally flawed. In addition, doing so will lead to an unsustainable series of requests for unimplementable features in the spec and/or implementations.

There is as yet insufficient deployment for there to be any "common or accepted practice" for concurrent stream restrictions with EME.

The mechanism is of will soon be supported by at least 3 DRMs.

There is no "fundamental flaw" (please see response to detailed issues below).

I don't see any prospect of "an unsustainable series of requests for unimplementable features". In any case, requests for "unimplementable" features are easily dealt with.

There is only one (thread

https://lists.w3.org/Archives/Public/public-html-media/2015Mar/thread.html#msg46) content provider planning to use the secure proof of key release for non-persistent licenses feature represented by "persistent-release-message" https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-release-message. It is not a common practice, nor is there accepted consensus on its utility or effectiveness. Widely-accepted and supported alternatives are already supported by the spec and implementations. Including this optional feature in the spec unnecessarily increases the likelihood of platform fragmentation/segmentation: This feature is unrelated to content protection or robustness, yet a content provider reliant on it (and subsequent requirements) may deny content to clients that otherwise support the relevant levels of robustness.

I think it is too early in EME deployment to talk about common practice. This mechanism, along with license renewal (also optional), have been supported by the specification since the very early drafts. We originally cast both as CDM-specific features exposed through a generic API but are now moving to more explicit API support (which is good). Both mechanisms are presently missing some specification.

The feature is certainly related to robustness. In general the purpose of the "robust" component of the CDM is to enable restrictions to be reliably applied on behalf of the service / content provider, those restrictions being just those in the license granted to the user for use of the content. In the case of subscription services those include concurrent stream limitations.

In the March 17 telecon http://www.w3.org/2015/03/17-html-media-minutes.html#item08, Mark said "the system is very much dependent on getting these messages", including after the application has been closed (something that browsers and most user agents cannot support). He also said they (Netflix) "don't know what the frequency of these messages will be in the field" or how important the reliability of receiving the messages is to its effectiveness. He also hinted they may find more cases where they would want to report such messages. The mechanism is fundamentally unreliable - placing server responsibilities on every client yet expecting the reliability of the server - and thus begets additional troublesome feature to mitigate that.

There is a mis-understanding here - and in the issues cited below - as to how these messages are used. There are two very distinct applications: In some cases (most likely embedded applications) delivery of the messages at session close can be made sufficiently reliably that they can be used for real-time enforcement of concurrent stream limits. In other cases (notably desktop browsers) reliable delivery on close is not always available. Instead, the messages are persisted and sent later, next time the page is visited. These messages are used for non-real time reconciliation with history data in order to detect fraud. The kind of fraud of concern is - mostly - large scale automated account sharing with circumvention of concurrent stream limits. Such a circumvention system would easily be detected whatever the "natural" rate of message delivery happened to be.

Additional technical issues:

The mechanism is unreliable in a browser or other multitasking environment.^

This may significantly reduce its effectiveness and introduce user friction not present with the alternative solutions.^^

These issues are addressed above.

This has led to repeated requests (as recent as March 17, 2015 http://www.w3.org/2015/03/17-html-media-minutes.html#item08) to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user. This is not something we can specify, and any attempt to make such behavior optional would likely lead to segmentation.

Even if it does not appear in desktop browsers, the possibility to send the messages on close events should be included in the specification as it may be implemented in other environments.

This session type is essentially a “persistent-license” session with a short expiration time. It introduces a requirement that CDMs be able to persist state even for “simple [online] streaming.” https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Simple_Streaming_of_a_Specific_Title This raises the bar of entry for new implementations and/or may preclude some implementations/devices (including private browsing modes).

I agree with the idea of testing the waters to see if any given CDM requirement can be dropped without excluding some set of providers or content. In this case, I don't think it can.

Non-real time fraud detection is a much better solution than regular license renewal, which has strong real-time system requirements, impacting users in ways that the non-real time reconciliation does not.

...Mark

Note: This session type specifically relates to persisting a secure proof of key/license release of non-persistent licenses for later retrieval. It does not apply to release messages related to persistent licenses (“persistent-license” https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-license sessions) or even release messages from “temporary” sessions that do not need to be persisted.

^ Examples include the user closing the tab or browser, especially for clients that implement quick shutdown; the user closing a laptop lid; tab eviction (for limited resources, especially - but not limited to - on mobile devices); crashes. ^^ For example, if a user watching a video closes the laptop lid then goes to a TV to resume, the proof of key release will not have been sent and the user will be unable to resume until some timer expires or they open the laptop and stop the video there. This is not a problem with alternative mechanisms, which can gracefully handle the transition, or at least limit the duration of the problem.

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/45.

As a general rule, building EME to satisfy "common or accepted practice" seems a reasonable philosophy, given that media services have been in existence for some time and have developed standard practices on a variety of topics. I don't, however, believe it should block us from attempting to expand the mechanisms we provide that help services secure themselves against exploit, especially exploits of the broad nature that Mark has suggested. This should be true whether a mechanism supports real time tools for limiting concurrent sessions, or after the fact identification of accounts being misused. Offering reasonable options to websites in this area seems like it should be given high priority.

In this particular case, the secure release mechanism is relatively simple to support, and fairly predictable in its behavior. It is subject to sessions being left pending by abrupt browser closures, so some systems will have more timely support than others. Assuming there is remaining utility for restricting large scale abuse, the feature seems worthwhile even with this limitation.

We have doubts about how scalable license rotation can be as an alternative, and whether it actually addresses all concerns. It can serve to minimize stray concurrent sessions assuming each license is individually authorized as it is issued. That clearly has a higher processing requirement for license servers than that required to support secure release. Services may benefit from having both solutions available.

@ddorwin Can you explain how the "persistent-release-message" feature is significantly more burdensome to support than "persistent-license"? In both cases, the CDM (or UA?) persists a message, in the first case it is a proof-of-key-deletion and in the second it is a license.

Summary tl;dr: Rather than start from Netflix’s chosen solution, which comes with a lot of concerns (further articulated below), we should look at the use cases and determine the right solution for the web platform across all known implementations.

There is a lot of inline discussion, so I've tried to summarize for the convenience of others.

Mark’s position as I understand it:

The unreliable nature of implementations in desktop browsers is acceptable because it still allows non-real-time fraud detection.
“Embedded applications” should be allowed to delay application shutdown to enable real-time enforcement.
He believes that “license renewal... has strong real-time system requirements” that impact users (in unspecified ways).

Question for Mark: If non-real-time fraud detection is sufficient, why do we need to enable real-time enforcement?

My concerns fall into four primary categories:

This feature will likely lead to unnecessary segmentation/fragmentation of the web platform.
This feature places an unnecessary, potentially architecture-impacting, burden on all user agents to support a single content provider.
There is no data or documentation of alternatives considered and their irreconcilable shortcomings that justifies the burden this feature introduces.
The requirements will likely evolve and eventually be pushed onto most/all implementations. The history and nature of this feature and its limited use makes this all too likely.

Details:

The goal of EME is to enable playback for all users of clients/user agents that conform to the spec and support the appropriate levels of robustness for keys and content. The HTML WG should not endorse a feature that further segments and fragments the platform in ways that are unrelated to the stated goals of protecting the content. (More on this below.)
There is no data (with explanation of alternatives considered) to make an informed decision to push the complexity of either variant onto implementors and the web platform. Specifically:
- There were no discussions of use cases, framed problem statements, or proposed solutions before settling on this solution.
- Assuming we understand the problem, there is no data that supports claims that existing mechanisms and mitigations fail to address the fraud concerns or harm the user experience.
- Experience appears to be based mostly on native applications where the issues of a general-purpose common platform, interoperability, and fragmentation are not a concern.
Mark’s distinction between “embedded applications” and “desktop browsers” is a red herring.
- Even today, it is hard to distinguish between an embedded application and a browser. Examples: mobile browsers; Chromecast; Firefox OS.
- Specifically, mobile devices often support the highest robustness levels (like embedded devices) but have browsers with the same architectures as desktop platforms.
- The real-time requirement could artificially disadvantage the web vs. native apps on the same device.
Even in the “desktop browser” case, this feature measurably complicates what is required to have any access to content that relies on this feature. What should be accessible with simpler “temporary” sessions now requires more complexity.
- I believe similar goals can be achieved without “strong real-time system requirements.” I’d be happy to discuss details.
We have not been told why real-time enforcement is necessary on some platforms or how [lack of] support for it would affect access to content.
Platform architecture - It is an architectural violation to allow media stack to dictate application lifetime or shutdown.
- This could potentially impact all websites, not just those using EME.

Furthermore, Including a flexible / “optional” feature that is defined by a single site introduces the probability of segmentation/fragmentation. Below, I describe a logical outcome:

Implementations that do not implement even the “optional” “desktop browser” functionality will be denied access to content from a provider that requires it.
Implementations that do not implement the reliable mechanism (for real-time enforcement) will likely be denied access to content and/or certain qualities of content even though they are otherwise capable of appropriately protecting the keys and content.
Real-time enforcement will likely become a requirement for most implementations (see above), potentially even desktop browsers.
- Previous iterations of this request sought to require this of all implementations, including desktop browsers.
- Specifically, I'm concerned that this capability might be (or become) required for all but the lowest categories (i.e. resolution) of content typically available to desktop browsers.
Access to content could be leveraged in an attempt to force implementations to support real-time enforcement (regardless of how “optional” it is made to seem today or in the spec).
If so, Implementors will be left with the unacceptable choice between a) breaking the web platform (i.e. application lifetime) and their architecture and b) being denied specific content.

Detailed responses to specific comments follow.

On Mon, Apr 6, 2015 at 9:01 AM, mwatson2 wrote:

On Tue, Mar 31, 2015 at 4:07 PM, ddorwin wrote:

Summary: It does not make sense to include a feature in the spec that is not a common or accepted practice, is not widely supported, and is fundamentally flawed. In addition, doing so will lead to an unsustainable series of requests for unimplementable features in the spec and/or implementations.

There is as yet insufficient deployment for there to be any "common or accepted practice" for concurrent stream restrictions with EME.

I was referring to common or accepted practice in the premium content/DRM industry. In addition, there are tens of content providers using EME without this feature.

The mechanism is of will soon be supported by at least 3 DRMs.

I am surprised that 3 DRMs will soon “support” it given that a) (as far as I know) none supported it a year or two ago, b) there is no agreed upon definition, and c) the non-real time fraud detection scenario was not discussed previously. I am curious to hear these vendors’ reasoning for implementing it and thoughts on whether/why it should be included in the spec.

There is no "fundamental flaw" (please see response to detailed issues below).

I don't see any prospect of "an unsustainable series of requests for unimplementable features".

Requiring messages at session close for some implementations is the beginning. There is nothing to say that Netflix won’t start to require it for all implementations (for some given set of content and/or quality).

In any case, requests for "unimplementable" features are easily dealt with.

That has not been my experience so far with this spec.

There is only one (thread) content provider planning to use the secure proof of key release for non-persistent licenses feature represented by "persistent-release-message". It is not a common practice, nor is there accepted consensus on its utility or effectiveness. Widely-accepted and supported alternatives are already supported by the spec and implementations. Including this optional feature in the spec unnecessarily increases the likelihood of platform fragmentation/segmentation: This feature is unrelated to content protection or robustness, yet a content provider reliant on it (and subsequent requirements) may deny content to clients that otherwise support the relevant levels of robustness.

I think it is too early in EME deployment to talk about common practice.

As I said above, I wasn’t limiting this to EME. However, Netflix has deployed EME applications without this feature.

This mechanism, along with license renewal (also optional), have been supported by the specification since the very early drafts.

While key release has been mentioned in various forms, this session type is not a long-existing feature (details below) nor has it ever been “supported” (i.e. explicitly defined behavior, more than a vague unspecified concept). 3+ years later a) there is no agreed definition of how it works and b) there is no consensus that it works or is necessary. We have objected to it since those very early drafts, and my concerns remain the same.

Secure key release was previously removed from the spec. This specific session type had been in the spec less than four months before this bug was filed. It was added primarily to disambiguate “persistent” by defining “persistent-license” and its behavior, including explicitly requesting persistent licenses. Adding "persistent-release-message" then was a mistake (and based on assurances that have since turned out to be inaccurate). The session type is not a long-existing feature.

We originally cast both as CDM-specific features exposed through a generic API but are now moving to more explicit API support (which is good). Both mechanisms are presently missing some specification.

License renewal can be implemented entirely within the license protocol and does not require special behavior and user agent support like persistent release messages do.

The feature is certainly related to robustness. In general the purpose of the "robust" component of the CDM is to enable restrictions to be reliably applied on behalf of the service / content provider, those restrictions being just those in the license granted to the user for use of the content. In the case of subscription services those include concurrent stream limitations.

Robustness levels relate to protecting the keys and content. The keys and content are no less protected without this feature. It is Netflix’s choice to eschew supported mechanisms for reliably applying concurrent stream limitations. That doesn’t mean we should force all implementations to adopt its proprietary alternative.

In the March 17 telecon, Mark said "the system is very much dependent on getting these messages", including after the application has been closed (something that browsers and most user agents cannot support).

He also said they (Netflix) "don't know what the frequency of these messages will be in the field" or how important the reliability of receiving the messages is to its effectiveness. He also hinted they may find more cases where they would want to report such messages. The mechanism is fundamentally unreliable - placing server responsibilities on every client yet expecting the reliability of the server - and thus begets additional troublesome feature to mitigate that.

There is a mis-understanding here - and in the issues cited below - as to how these messages are used. There are two very distinct applications: In some cases (most likely embedded applications) delivery of the messages at session close can be made sufficiently reliably that they can be used for real-time enforcement of concurrent stream limits.

If real-time enforcement is not necessary for “desktop browsers,” why is it desired for other platforms? Is it required for some content and/or quality of content?

The idea of two very distinct implementations confirms my concern regarding fragmentation/segmentation. Even an “embedded application” that follows normal “desktop browser” behaviors might be excluded. Furthermore, the line between embedded devices and browsers is increasingly blurred. For example, Chromecast is an embedded device but based on a browser and would have similar shutdown behavior. In addition, mobile devices often support higher levels of robustness, but rely on “desktop browsers” and cannot support this feature, meaning they could also be excluded.

This category also highlights the potential for this requirement to eventually be applied to other platforms. You acknowledge that Netflix is interested in real-time enforcement when available; it’s reasonable to assume that Netflix’s strong preference (and that Netflix is a market mover with strong influence) makes this a de facto requirement across more platforms, eventually including browsers.

Once this feature is “accepted practice” (via inclusion in the spec), there is no guarantee that the requirements remain static. In fact, previous iterations of this request did include all implementations, including desktop browsers. On the other hand, generic, simple, and easily-defined mechanisms that don’t rely on shutdown behavior or persistent state avoid the probability of fragmentation as a result of de facto requirements for "optional" features.

If the real-time enforcement variant is required in order to access certain content, we will see web platform fragmentation/segmentation based on the user agent architecture and not just the robustness properties of the CDM. Implementors will face a choice between architectural flexibility - and related user experience - and access to certain content. That is not something the HTML WG should endorse.

In other cases (notably desktop browsers) reliable delivery on close is not always available. Instead, the messages are persisted and sent later, next time the page is visited. These messages are used for non-real time reconciliation with history data in order to detect fraud. The kind of fraud of concern is - mostly - large scale automated account sharing with circumvention of concurrent stream limits. Such a circumvention system would easily be detected whatever the "natural" rate of message delivery happened to be.

Persistent release messages is one possible solution for this issue, albeit one that places the burden on the client rather than the application. However, there are alternatives, and it is premature to jump to the conclusion that CDMs and user agents must support this Netflix-only feature despite previously articulated concerns and lacking discussion of alternatives.

Alternative mechanisms are already widely deployed, which should allow for experimentation without changing the spec. I believe the stated goals can be achieved without “strong real-time system requirements.” We would be happy to work with you on such experiments.

Additional technical issues:

The mechanism is unreliable in a browser or other multitasking environment.^

This may significantly reduce its effectiveness and introduce user friction not present with the alternative solutions.^^

These issues are addressed above.

This has led to repeated requests (as recent as March 17, 2015) to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user. This is not something we can specify, and any attempt to make such behavior optional would likely lead to segmentation.

Even if it does not appear in desktop browsers, the possibility to send the messages on close events should be included in the specification as it may be implemented in other environments.

In addition to the issues articulated above, user agents MUST NOT allow the media stack to affect application lifetime or shutdown. EME relates to decrypting media - it does not relate to application lifetime or other parts of the web platform.

If detecting fraud after the fact is sufficient, why should this be an option “in other environments?”

This session type is essentially a “persistent-license” session with a short expiration time. It introduces a requirement that CDMs be able to persist state even for “simple [online] streaming.” This raises the bar of entry for new implementations and/or may preclude some implementations/devices (including private browsing modes).

I agree with the idea of testing the waters to see if any given CDM requirement can be dropped without excluding some set of providers or content. In this case, I don't think it can.

As mentioned above, there is no data / proof around exploration of alternatives. I fully support testing this in a transparent way if you intend to use that data as justification for this feature in the future.

Non-real time fraud detection is a much better solution than regular license renewal, which has strong real-time system requirements, impacting users in ways that the non-real time reconciliation does not.

Can you please elaborate on the user impact? If non-real-time fraud detection is all you expect from this feature, it should be possible to reduce the “real-time system requirements” of license renewal. Furthermore, key system implementations can facilitate lighter-weight renewal mechanisms. All of these options can be explored without complicating the spec or burdening all user agents.

Regular license renewal is used for real-time enforcement. Since that is not your goal (or so you have said), the requirements can be significantly reduced. I think they can be reduced to the point of little to no actual impact on users. I’d be happy to discuss the details with you.

On Mon, Apr 6, 2015 at 4:01 PM, jdsmith3000 wrote:

As a general rule, building EME to satisfy "common or accepted practice" seems a reasonable philosophy, given that media services have been in existence for some time and have developed standard practices on a variety of topics.

This is a general rule for all web platform specs. We specify building blocks for features that are generally accepted and useful, not proprietary practices that are only useful to one company (or even a handful).

If Mark similarly demanded a CSS feature only useful to Netflix because they chose not to follow some model, would he get it? Or would he have to demonstrate that what he wants is not otherwise possible and that it would be sufficiently useful to other authors?

I don't, however, believe it should block us from attempting to expand the mechanisms we provide that help services secure themselves against exploit, especially exploits of the broad nature that Mark has suggested. This should be true whether a mechanism supports real time tools for limiting concurrent sessions, or after the fact identification of accounts being misused.

Not including this feature doesn't mean we won't support other mechanisms in the future. I believe this specific mechanism is bad for the web for the reasons I have articulated above. I also believe there are less intrusive mechanisms (real-time and otherwise) that address such exploits. Rather than starting from Netflix’s chosen solution, we should look at the use cases and how we can best solve them in the web platform.

Offering reasonable options to websites in this area seems like it should be given high priority.

In this specific case, I have questions regarding how “reasonable” this option is, as I have articulated. I am yet to see evidence or data that disproves those concerns.

The Work Group must consider the pros and cons of options and their impact on the web platform, interoperability, users, user access to content, etc. - as well as potential consequences for the platform - and include “the right ones.” This is of much higher importance than “offering options” to a single website, despite their persistence. I have extensively articulated cons that far outweigh the benefits of offering this specific option.

But, to be honest, I was surprised by the strong endorsement. I am curious how you remain so convinced that the spec must support this feature now. Do you disagree with my concerns?

Note that there are much more commonly used models and mechanism that we have deferred from this version of the spec. Why should this feature for a single content provider be a high priority, especially when there is no evidence that the alternatives have been adequately explored?

In this particular case, the secure release mechanism is relatively simple to support, and fairly predictable in its behavior. It is subject to sessions being left pending by abrupt browser closures, so some systems will have more timely support than others. Assuming there is remaining utility for restricting large scale abuse, the feature seems worthwhile even with this limitation.

The mechanism introduces persistence requirements for basic online playback. That is hardly simple. Also, note that the persistence must be per-origin (combination). In addition, Mark wants much more complex implementations on some devices. Those implementations will be neither simple nor predictable.

You are assuming there is remaining utility, but it remains unproven (lacking data).

We have doubts about how scalable license rotation can be as an alternative, and whether it actually addresses all concerns. It can serve to minimize stray concurrent sessions assuming each license is individually authorized as it is issued. That clearly has a higher processing requirement for license servers than that required to support secure release. Services may benefit from having both solutions available.

How does PlayReady support concurrent license limits in existing systems? Note: You don’t have to rotate an entire license. (If you’re willing to add this complex feature, then you might look at supporting lighter-weight renewals.)

We have successfully deployed license renewal on many clients, and it is transparent to the user agent and application. Scalability issues can be addressed in several ways.

On Mon, Apr 6, 2015 at 4:22 PM, palemieux wrote:

@ddorwin Can you explain how the "persistent-release-message" feature is significantly more burdensome to support than "persistent-license"? In both cases, the CDM (or UA?) persists a message, in the first case it is a proof-of-key-deletion and in the second it is a license.

That is not the issue being debated. "persistent-license" serves a completely different user use case and is not a requirement to be able to access content at all (or at least it shouldn’t be). The question should be how the "persistent-release-message" feature is significantly more burdensome to support than "temporary".

Netflix wants "persistent-release-message" for the online streaming case for which everyone else uses “temporary” sessions. If a user agent has a key system that a site supports, the user should be able to view the content. If the key system implementation supports "persistent-license" and the site supports it, the user may additionally be able to store the content and license for offline playback (i.e. on an airplane). Lack of "persistent-license" support doesn’t prevent the user from viewing the content at all, though. As an example, Google Play Movies supports online streaming on many devices and supports offline playback (persisting content and licenses) on a subset of those devices.

For a site that requires "persistent-release-message", however, a user will not be able to stream content at all unless their user agent and key system implementation support this session type (and the related persistence functionality required). Users would also be unable to view content in a private browsing mode.

While both require persistence, there are important differences between "persistent-license" and "persistent-release-message":

"persistent-license" is truly optional as I explained above, whereas "persistent-release-message" would be effectively required, no matter what the spec says.
While persistent/offline licenses are well understood within the industry, persistent release messages are not (as demonstrated during multiple previous discussions of them within this group), and there is no agreed upon definition of it. Furthermore, Mark is pushing to allow additional complex behavior.
"persistent-license" sessions have a clear application-driven storage and removal/release point, but "persistent-release-message" messages are stored when the license is destroyed, possibly during shutdown.

David, all,

There is a lot to discuss here and I will try and summarize the issues in some slides for our meeting.

In the meantime, I'll restrict myself to answering the direct questions and correcting an incorrect assumption.

David asked "If non-real-time fraud detection is sufficient, why do we need to enable real-time enforcement?" and "If real-time enforcement is not necessary for “desktop browsers,” why is it desired for other platforms? Is it required for some content and/or quality of content?"

Most viewing (for our system at least) is on native applications, not desktop browsers. We have the opportunity in that context to ensure real-time enforcement of concurrent stream limits. Given that, non-real-time fraud detection is acceptable for the desktop browser subset. Obviously it is better that fraud does not occur at all than that we detect it and have to do work to curtail it. If the attacks are limited to certain platforms, that makes the fraud opportunity less attractive. That's just a judgement call based on platform volume, not a technical issue.

Whether a given feature is required for some content and/or quality of content is a matter for the provider of that content, not something we can determine in this forum. If a feature is unavailable on some platform, the provider faces a choice about whether to restrict the content or quality on that platform or to live without the feature. There are many non-technical factors (mostly about risk assessment and mitigation plans) to consider including things that change over time. Whether we specify the feature here or not does not factor much into that decision.

Regarding license renewal, David asks "Can you please elaborate on the user impact?"

Sessions share fate with license servers, so a license server outage (or connectivity issue) causes all sessions in progress to fail. By contrast, with secure release, only new sessions would be affected. We feel failing a session-in-progress is much worse for users than failing a session start, though both are obviously highly undesirable. License servers and content servers are very different in our system, the former running on commodity virtual compute resources at central locations and the latter being hardware optimized very simple web servers at the network edge. Fundamentally, either license server interaction is required for sessions to continue or it is not. If it is not, then that interaction can also be deliberately suppressed by an attacker and sessions continue.

There is an assumption below that service would be denied to platforms without this feature. Even if that were true, quite how our decisions in W3C could alter that, I am not sure. However, as you noted, at least the Netflix service is available on some platforms without this feature. Again, whether a provider chooses to "fragment" the web platform by offering service to some platforms and not others, or offering different service on different platforms, is not something we have much influence over here.

Finally, whilst it's not super-productive to argue about the history, I want to make it clear that this proposal has been part of our work since the very first draft. At one point Google insisted that both this technique and license renewal should not be explicitly described but would be CDM-specific capabilities making use of a generic API. It was on this basis that description of secure release was removed from the specification, not because the group rejected the feature. Google's position has since completely changed, in favor of explicit description of all features, which is a good thing. There has been no analysis of license renewal either: how is renewal time specified ? How is renewal triggered ? Is there a grace period ? etc. Please don't pretend the group has made a decision favoring one approach over the other.

...Mark

On Fri, Apr 10, 2015 at 7:16 PM, ddorwin notifications@github.com wrote:

Summary tl;dr: Rather than start from Netflix’s chosen solution, which comes with a lot of concerns (further articulated below), we should look at the use cases and determine the right solution for the web platform across all known implementations.

There is a lot of inline discussion, so I've tried to summarize for the convenience of others.

Mark’s position as I understand it:

The unreliable nature of implementations in desktop browsers is acceptable because it still allows non-real-time fraud detection.

“Embedded applications” should be allowed to delay application shutdown to enable real-time enforcement.

He believes that “license renewal... has strong real-time system requirements” that impact users (in unspecified ways).

Question for Mark: If non-real-time fraud detection is sufficient, why do we need to enable real-time enforcement?

My concerns fall into four primary categories:

This feature will likely lead to unnecessary segmentation/fragmentation of the web platform.

This feature places an unnecessary, potentially architecture-impacting, burden on all user agents to support a single content provider.

There is no data or documentation of alternatives considered and their irreconcilable shortcomings that justifies the burden this feature introduces.

The requirements will likely evolve and eventually be pushed onto most/all implementations. The history and nature of this feature and its limited use makes this all too likely.

Details:

The goal of EME is to enable playback for all users of clients/user agents that conform to the spec and support the appropriate levels of robustness for keys and content. The HTML WG should not endorse a feature that further segments and fragments the platform in ways that are unrelated to the stated goals of protecting the content. (More on this below.)

There is no data (with explanation of alternatives considered) to make an informed decision to push the complexity of either variant onto implementors and the web platform. Specifically:

There were no discussions of use cases, framed problem statements, or proposed solutions before settling on this solution.

Assuming we understand the problem, there is no data that supports claims that existing mechanisms and mitigations fail to address the fraud concerns or harm the user experience.

Experience appears to be based mostly on native applications where the issues of a general-purpose common platform, interoperability, and fragmentation are not a concern.

Mark’s distinction between “embedded applications” and “desktop browsers” is a red herring.

Even today, it is hard to distinguish between an embedded application and a browser. Examples: mobile browsers; Chromecast; Firefox OS.

Specifically, mobile devices often support the highest robustness levels (like embedded devices) but have browsers with the same architectures as desktop platforms.

The real-time requirement could artificially disadvantage the web vs. native apps on the same device.

Even in the “desktop browser” case, this feature measurably complicates what is required to have any access to content that relies on this feature. What should be accessible with simpler “temporary” sessions now requires more complexity.

I believe similar goals can be achieved without “strong real-time system requirements.” I’d be happy to discuss details.

We have not been told why real-time enforcement is necessary on some platforms or how [lack of] support for it would affect access to content.

Platform architecture - It is an architectural violation to allow media stack to dictate application lifetime or shutdown.

This could potentially impact all websites, not just those using EME.

Furthermore, Including a flexible / “optional” feature that is defined by a single site introduces the probability of segmentation/fragmentation. Below, I describe a logical outcome:

Implementations that do not implement even the “optional” “desktop browser” functionality will be denied access to content from a provider that requires it.

Implementations that do not implement the reliable mechanism (for real-time enforcement) will likely be denied access to content and/or certain qualities of content even though they are otherwise capable of appropriately protecting the keys and content.

Real-time enforcement will likely become a requirement for most implementations (see above), potentially even desktop browsers.

Previous iterations of this request sought to require this of all implementations, including desktop browsers.

Specifically, I'm concerned that this capability might be (or become) required for all but the lowest categories (i.e. resolution) of content typically available to desktop browsers.

Access to content could be leveraged in an attempt to force implementations to support real-time enforcement (regardless of how “optional” it is made to seem today or in the spec).

If so, Implementors will be left with the unacceptable choice between a) breaking the web platform (i.e. application lifetime) and their architecture and b) being denied specific content.

Detailed responses to specific comments follow.

On Mon, Apr 6, 2015 at 9:01 AM, mwatson2 wrote:

On Tue, Mar 31, 2015 at 4:07 PM, ddorwin wrote:

Summary: It does not make sense to include a feature in the spec that is not a common or accepted practice, is not widely supported, and is fundamentally flawed. In addition, doing so will lead to an unsustainable series of requests for unimplementable features in the spec and/or implementations.

There is as yet insufficient deployment for there to be any "common or accepted practice" for concurrent stream restrictions with EME.

I was referring to common or accepted practice in the premium content/DRM industry. In addition, there are tens of content providers using EME without this feature.

The mechanism is of will soon be supported by at least 3 DRMs.

I am surprised that 3 DRMs will soon “support” it given that a) (as far as I know) none supported it a year or two ago, b) there is no agreed upon definition, and c) the non-real time fraud detection scenario was not discussed previously. I am curious to hear these vendors’ reasoning for implementing it and thoughts on whether/why it should be included in the spec.

There is no "fundamental flaw" (please see response to detailed issues below).

I don't see any prospect of "an unsustainable series of requests for unimplementable features".

Requiring messages at session close for some implementations is the beginning. There is nothing to say that Netflix won’t start to require it for all implementations (for some given set of content and/or quality).

In any case, requests for "unimplementable" features are easily dealt with.

That has not been my experience so far with this spec.

There is only one (thread https://lists.w3.org/Archives/Public/public-html-media/2015Mar/thread.html#msg46 ) content provider planning to use the secure proof of key release for non-persistent licenses feature represented by "persistent-release-message" https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-release-message . It is not a common practice, nor is there accepted consensus on its utility or effectiveness. Widely-accepted and supported alternatives are already supported by the spec and implementations. Including this optional feature in the spec unnecessarily increases the likelihood of platform fragmentation/segmentation: This feature is unrelated to content protection or robustness, yet a content provider reliant on it (and subsequent requirements) may deny content to clients that otherwise support the relevant levels of robustness.

I think it is too early in EME deployment to talk about common practice.

As I said above, I wasn’t limiting this to EME. However, Netflix has deployed EME applications without this feature.

This mechanism, along with license renewal (also optional), have been supported by the specification since the very early drafts.

While key release has been mentioned in various forms, this session type is not a long-existing feature (details below) nor has it ever been “supported” (i.e. explicitly defined behavior, more than a vague unspecified concept). 3+ years later a) there is no agreed definition of how it works and b) there is no consensus that it works or is necessary. We have objected to it since those very early drafts, and my concerns remain the same.

Secure key release was previously removed https://github.com/w3c/encrypted-media/commit/1427b55c9a228f92d0f8d4bf87521b34386e35b0 from the spec. This specific session type had been in the spec less than four months before https://github.com/w3c/encrypted-media/commit/d075e48451f02c0815f8d7459fbf166821492ece this bug was filed. It was added primarily to disambiguate “persistent” by defining “persistent-license” and its behavior, including explicitly requesting persistent licenses. Adding "persistent-release-message" then was a mistake (and based on assurances that have since turned out to be inaccurate). The session type is not a long-existing feature.

We originally cast both as CDM-specific features exposed through a generic API but are now moving to more explicit API support (which is good). Both mechanisms are presently missing some specification.

License renewal can be implemented entirely within the license protocol and does not require special behavior and user agent support like persistent release messages do.

The feature is certainly related to robustness. In general the purpose of the "robust" component of the CDM is to enable restrictions to be reliably applied on behalf of the service / content provider, those restrictions being just those in the license granted to the user for use of the content. In the case of subscription services those include concurrent stream limitations.

Robustness levels relate to protecting the keys and content. The keys and content are no less protected without this feature. It is Netflix’s choice to eschew supported mechanisms for reliably applying concurrent stream limitations. That doesn’t mean we should force all implementations to adopt its proprietary alternative.

In the March 17 telecon http://www.w3.org/2015/03/17-html-media-minutes.html#item08, Mark said "the system is very much dependent on getting these messages", including after the application has been closed (something that browsers and most user agents cannot support).

He also said they (Netflix) "don't know what the frequency of these messages will be in the field" or how important the reliability of receiving the messages is to its effectiveness. He also hinted they may find more cases where they would want to report such messages. The mechanism is fundamentally unreliable - placing server responsibilities on every client yet expecting the reliability of the server - and thus begets additional troublesome feature to mitigate that.

There is a mis-understanding here - and in the issues cited below - as to how these messages are used. There are two very distinct applications: In some cases (most likely embedded applications) delivery of the messages at session close can be made sufficiently reliably that they can be used for real-time enforcement of concurrent stream limits.

If real-time enforcement is not necessary for “desktop browsers,” why is it desired for other platforms? Is it required for some content and/or quality of content?

The idea of two very distinct implementations confirms my concern regarding fragmentation/segmentation. Even an “embedded application” that follows normal “desktop browser” behaviors might be excluded. Furthermore, the line between embedded devices and browsers is increasingly blurred. For example, Chromecast is an embedded device but based on a browser and would have similar shutdown behavior. In addition, mobile devices often support higher levels of robustness, but rely on “desktop browsers” and cannot support this feature, meaning they could also be excluded.

This category also highlights the potential for this requirement to eventually be applied to other platforms. You acknowledge that Netflix is interested in real-time enforcement when available; it’s reasonable to assume that Netflix’s strong preference (and that Netflix is a market mover with strong influence) makes this a de facto requirement across more platforms, eventually including browsers.

Once this feature is “accepted practice” (via inclusion in the spec), there is no guarantee that the requirements remain static. In fact, previous iterations of this request did include all implementations, including desktop browsers. On the other hand, generic, simple, and easily-defined mechanisms that don’t rely on shutdown behavior or persistent state avoid the probability of fragmentation as a result of de facto requirements for "optional" features.

If the real-time enforcement variant is required in order to access certain content, we will see web platform fragmentation/segmentation based on the user agent architecture and not just the robustness properties of the CDM. Implementors will face a choice between architectural flexibility

and related user experience - and access to certain content. That is not something the HTML WG should endorse.

In other cases (notably desktop browsers) reliable delivery on close is not always available. Instead, the messages are persisted and sent later, next time the page is visited. These messages are used for non-real time reconciliation with history data in order to detect fraud. The kind of fraud of concern is - mostly - large scale automated account sharing with circumvention of concurrent stream limits. Such a circumvention system would easily be detected whatever the "natural" rate of message delivery happened to be.

Persistent release messages is one possible solution for this issue, albeit one that places the burden on the client rather than the application. However, there are alternatives, and it is premature to jump to the conclusion that CDMs and user agents must support this Netflix-only feature despite previously articulated concerns and lacking discussion of alternatives.

Alternative mechanisms are already widely deployed, which should allow for experimentation without changing the spec. I believe the stated goals can be achieved without “strong real-time system requirements.” We would be happy to work with you on such experiments.

Additional technical issues:

The mechanism is unreliable in a browser or other multitasking environment.^

This may significantly reduce its effectiveness and introduce user friction not present with the alternative solutions.^^

These issues are addressed above.

This has led to repeated requests (as recent as March 17, 2015 http://www.w3.org/2015/03/17-html-media-minutes.html#item08) to ensure or allow implementations to send messages after the window/tab/user agent have been closed by the user. This is not something we can specify, and any attempt to make such behavior optional would likely lead to segmentation.

Even if it does not appear in desktop browsers, the possibility to send the messages on close events should be included in the specification as it may be implemented in other environments.

In addition to the issues articulated above, user agents MUST NOT allow the media stack to affect application lifetime or shutdown. EME relates to decrypting media - it does not relate to application lifetime or other parts of the web platform.

If detecting fraud after the fact is sufficient, why should this be an option “in other environments?”

This session type is essentially a “persistent-license” session with a short expiration time. It introduces a requirement that CDMs be able to persist state even for “simple [online] streaming.” https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Simple_Streaming_of_a_Specific_Title This raises the bar of entry for new implementations and/or may preclude some implementations/devices (including private browsing modes).

I agree with the idea of testing the waters to see if any given CDM requirement can be dropped without excluding some set of providers or content. In this case, I don't think it can.

As mentioned above, there is no data / proof around exploration of alternatives. I fully support testing this in a transparent way if you intend to use that data as justification for this feature in the future.

Non-real time fraud detection is a much better solution than regular license renewal, which has strong real-time system requirements, impacting users in ways that the non-real time reconciliation does not.

Can you please elaborate on the user impact? If non-real-time fraud detection is all you expect from this feature, it should be possible to reduce the “real-time system requirements” of license renewal. Furthermore, key system implementations can facilitate lighter-weight renewal mechanisms. All of these options can be explored without complicating the spec or burdening all user agents.

Regular license renewal is used for real-time enforcement. Since that is not your goal (or so you have said), the requirements can be significantly reduced. I think they can be reduced to the point of little to no actual impact on users. I’d be happy to discuss the details with you.

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/45#issuecomment-91743387.

The above commit changes the enum value to "TBD" in order to:

Avoid confusion, such as that during the f2f, caused by current name (i.e. that this is the only type of session that generates release messages)
Avoid incompatible implementations until the feature is sufficiently defined
Allow us to pick an appropriate name at that time

The above change, and the two preceding ones, did a great deal more than simply change the name to "TBD".

As we saw at the f2f, the release message mechanism was actually much better defined than David has claimed. In particular, the sending of this message on remove() and various other descriptions of how this mechanism behaves have now been removed. So, I agree it is rather less well defined now, but it was not before. License renewal is also lacking quite a few details.

Anyway, I have an action to elaborate on the details of the release message mechanism and I will provide those changes this week, also restoring the functionality that was just removed.

On Tue, Apr 21, 2015 at 2:38 PM, ddorwin notifications@github.com wrote:

The above commit changes the enum value to "TBD" in order to:

Avoid confusion, such as that during the f2f http://www.w3.org/2015/04/16-html-media-minutes.html#item04, caused by current name (i.e. that this is the only type of session that generates release messages)

Avoid incompatible implementations until the feature is sufficiently defined

Allow us to pick an appropriate name at that time

— Reply to this email directly or view it on GitHub https://github.com/w3c/encrypted-media/issues/45#issuecomment-94949840.

Per my action from the Face-to-face meeting, I have created a spec update with further details on the key release mechanism.

See http://mwatson2.github.io/encrypted-media/ and https://github.com/w3c/encrypted-media/pull/54

In an attempt to allay fears about requirements to persist data or generate messages at close, I have described this more in terms of the common implementation approach of regularly persisting first and last decryption times. The API behavior is the same as the old description.

The relevant sections are:

the new definition of a "tracked" session type, replacing persistent-release-message (since it is information about the keys in use that is persisted, not the release message itself).
the remove() procedures which generate a key release message
the load() procedures which generate a key release message if there is persisted data
the update() procedures which handle the key release acknowledgment
the Encrypted Block Encountered procedures which update the first and last decrypt times
the clear key section which adds Key Release and Key Release Acknowledgement messages

I have also added some more material to the wiki: https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release

I think overall this is a good proposal and adds some details that the discussion needed.

I am a little concerned about putting too much detail about the key usage data for the release message into the algorithms, since that information really needs to be gathered by the CDM to be verifiable on the server. How can we incorporate these details into the spec without pulling more of the CDM definition in?

I would like to see the remove() still be required, rather than something that happens automatically for "tracked" sessions. I.e. load() then remove() would generate the message. This would be more inline with the "happy case" where generateRequest() and then remove() is called.

I think it would be useful to also have the keyStatuses map contain the key ids which are in a "tracked" session after load(). They would need to have a new key status of "waiting-for-release" or something like that. That would allow for easier debugging since the app could figure out which keys were actually waiting for remove() to be called (if any). If would generally improve the visibility of this feature.

Unrelated to my above comment --

Dave mentioned above that none of the DRMs were supporting this feature as-of a year ago. I assume that is referring to EME-specific support? We implemented support for license return receipts in our non-HTML product 3+ years ago, based on a much older backlog request. So this is not a new issue for our customers. We have just gotten around to supporting it in our CDM primarily because it has taken us this long to get a CDM into the field (not owning a browser). :(

Regarding specifying too much detail about the key usage data, the steps which gather this data (first and last decrypt times) are sub-steps that are to be executed by the CDM, so we are already specifying CDM behavior here. Is the concern that we are not clear enough that it is a CDM responsibility to gather this data or that there should be more flexibility for different data to be collected ?

I agree that requiring remove() in all cases is cleaner. I will make this change in the PR.

I also agree that it we should expose the existence of the tracked but released keys in the key status map. I'll add this too.

I've updated the PR (https://github.com/w3c/encrypted-media/pull/54): (1) to remove the automatic generation of release messages on load(). Instead it is always necessary to call remove() to trigger the generation of the release message. (2) to add a new key status, "released". Keys obtain this status when remove() is called or if a session is loaded containing a record of license destruction or a record of key usage. The key ids are finally removed from the keyStatus map when the release acknowledgement is provided.

The latest definition of "secure release" requires tamper-proof secure persistent storage or another form of delayed shutdown: https://lists.w3.org/Archives/Public/public-html-media/2015Jun/0021.html. Along with our previous concerns, this reinforces our stance that “secure release”, as proposed, should not be in the specification.

As per the list discussion, the non-secure-store approach requires the CDM to write to disk on page close, which is entirely different from the previous discussions around pages delaying shutdown.

Keeping the key release messages sent by the CDM is essential in implementing a solution that doesn’t introduce additional complexities, points of failure and dependencies to continue streaming for the customer. Therefore, we do not recommend deprecating the Key Release/Secure Stop messages from CDM. We should find mechanisms to handle the shut down scenarios. (bawin@amazon)

We’ve reviewed Google's position document at Microsoft, and disagree that license renewal should be used as a replacement for secure release. We have partners asking us to support secure release, and have implementation experience that suggests it is workable in devices of all levels. From our point of view:

The need for secure release has been validated by partner demand.
It is suitable for clients of all types, including smart TVs.
It is important that secure release be in the spec to ensure different implementations work in an interoperable way, whether it is a required feature or an optional one.
If some task force members don’t want it to be required, optional would be fine.
It is fully spec’d in Mark Watson’s pull request, and ready to check-in.

Closing on the EME spec is important, and given the long discussion on this specific feature, closing it has to be a priority. We don’t believe secure release should be left out of the EME spec though. Significant work has already been completed to answer spec questions and resolve ambiguities. The product of that work is in Mark’s pull request. That pull request should now be approved.

I have reviewed Google's position document as well. We do not believe license renewal can replace the secure release feature as described in the pending pull request. We also have customers who are asking us for that feature and use it on other platforms. I would prefer this was not optional, but if some implementations cannot for technical reasons support this, we are fine with this being an optional feature. We would like to see this pull approved.

CableLabs' member cable companies would like the secure release feature. AFAICT, Mark W has addressed the two issues raised (need for tamperproof storage and delayed shutdown). Two other service providers (Netflix and Amazon) and two CDM vendors have also stated the need for this feature. I think we should approve this PR.

I have proposed that we solicit guidance from the Technical Architecture Group to help resolve the current impasse.

tl;dr:

This issue is effectively replaced by issue #85 as concerns remain but are not accurately represented by this issue.
The feature is now called "persistent-usage-record".
- It no longer requires delaying application shutdown.
- It now only supports detection of abuse (not enforcement of limitations).
- There is still a requirement for either a) tamper evident CDM storage or b) write-on-application-close.

The feature has changed since I filed this issue, and there have been many discussions outside of the issue. While the most objectionable aspect (delaying application shutdown) was removed, other concerns expressed in this issue remain. Since the most significant issues are architectural, we have sought input from the W3C Technical Architecture Group. This is tracked in issue #85.

As this issue no longer accurately reflects the state of the feature or discussion, I am closing it.

For the record, below are some of the related conversations outside this issue:

Use case description
Secure release and persistence
Discussion of storage requirements (tamper evident CDM storage or write-on-application-close)
Summary of our position in June
Recurring License Renewals for Concurrency Detection and Enforcement (description of how an alternative mechanism can be used for detection and enforcement of concurrency limits)

w3c / encrypted-media

Remove "persistent-release-message" MediaKeySessionType #45