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

On Tue, Aug 18, 2015 at 7:21 AM, Mark Watson <watsonm@netflix.com> wrote:

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

You're disagreeing with something I didn't say. I said there is a viable
solution. As I replied in that other thread
<https://lists.w3.org/Archives/Public/public-html-media/2015Aug/0029.html>,
I think your mail addressed something other than renewal.


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

Making it “optional” doesn’t change that there are unresolved architectural
concerns.


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

I think we should clarify how the CDM behavior for this feature relates to
the application and thus web architecture. I'll cover that in the
discussion of the architectural question. I think the underspecification of
“tracked” sessions in the current spec text further contributes to the
confusion. I'll file a spec issue to address that.


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

The crux of the impasse is disagreement as to whether this is a web
architecture issue. As I said in the telecon, the TAG is the appropriate
party to make that determination as well as provide any relevant direction,
and we will follow up.


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