[EME] Proposal for next steps on secure release

I think we agree that EME should support concurrency fraud detection and
enforcement while ensuring a strong user experience - we just differ in our
opinions of where this can be best solved and where the complexities should
lie. The renewals approach demonstrates there is a viable solution to
securely detect and enforce concurrent usage that conforms to the web
platform, and there appears to be agreement to support it in the EME spec.

Thus, the question is whether secure release, an alternative mechanism for
concurrency fraud detection (but not enforcement) is acceptable and should
also be included as an alternative in the spec.

Despite the benefits to server availability or complexity - the magnitude
of which we believe is debatable [1] - our main concerns on secure release
remain unaddressed: supporting this feature imposes architectural
constraints on (billions of) clients to ensure secure release works as
intended, and it is incompatible with some user-beneficial browsing modes
and client architectures. (There is more on this in
https://lists.w3.org/Archives/Public/public-html-media/2015Jun/0029.html.)

In the license renewal thread, Mark questioned whether “additional [server]
architectural complexity is justified and proportionate for this problem."
I noted in my reply that such complexity is not a requirement for
successful use of renewal. However, I believe that “proportionate for this
problem” is a good evaluation metric for secure release. For a very narrow
use case (a subset of the small number of sites using DRM’d media),
including secure release (a partial solution that supports detection only)
in the spec dictates that all user agents be architected to allow part of
an application to write data after that web application is closed (or
provide CDMs access to tamper-evident persistent storage). That does not
seem like a proportionate approach to address a preference for one fraud
detection mechanism over the alternative, which avoids such requirements on
all clients.

Since the implications go beyond EME and are related to platform
architecture, I propose we solicit guidance from the Technical Architecture
Group on whether the architectural implications are acceptable and
consistent with the principles of the web platform and whether there might
be alternatives we have not considered. That will either confirm or
alleviate the majority of our concerns around secure release's inclusion in
EME and resolve our current impasse.

David


[1] I am having trouble identifying meaningful advantages of secure release
over license renewal, both for the majority of users and server-side
implementation. As mentioned in the other thread, the successful use of
secure release appears to depend on server-side heuristics to identify
clients on which enforcement mechanisms should be applied. (It appears from
Mark’s reply that we should discuss this more.) In addition, services using
secure release may need different heuristics depending on whether a client
implements it using tamper-evident persistent storage or write-on-close.

As described in the license renewal document, simple heuristics would
enable variable buckets that would allow most users to be provided lenient
renewal times. We believe it’s possible that such times would be sufficient
to avoid user experience problems caused by the types of outages secure
release seeks to avoid, all without having to implement resilient
independent license servers. Add to this the fact that secure release does
not provide enforcement, and using secure release ends up being more
complex with negligible meaningful benefit.