Re: [EME] Proposal for next steps on secure release

On Aug 17, 2015, at 10:55 PM, David Dorwin <ddorwin@google.com> wrote:

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


As per my other mail, we don't agree that it covers all the use-cases with
reasonable UX and server architecture impacts.

that conforms to the web platform, and there appears to be agreement to
support it in the EME spec.


But we do agree it should be in the 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,


The feature is proposed to be optional, so nothing is imposed on anyone.

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


No, this is incorrect. The requirement is that the *CDM* not the web
application be able to write on session close. Very different.

This may have implications for client software architecture, for sure, but
not web architecture.

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.


I don't agree this needs to go to the TAG because I do not see any web
architecture issue here.

...Mark



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.

Received on Tuesday, 18 August 2015 14:21:43 UTC