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

On Tue, Aug 25, 2015 at 3:28 PM, John Luther <jluther@jwplayer.com> wrote:

> On Fri, Aug 21, 2015 at 4:54 PM, David Dorwin <ddorwin@google.com> wrote:
> >
> >
> > 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, 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.
>
> +1. The debate over securestop/tracking has been going on for years
> and seems no closer to a resolution, a TAG review will help to move
> things forward.
>

​Actually, although a lot of time has passed, I think we have made a lot of
progress, since the mechanism has been greatly refined and the remaining
disagreement appears to be around a rather narrow question of whether
browsers can / should write to disk on close. That narrow question seems to
me to be one of software architecture, not web architecture.

...Mark

​



>
>
> >
> >>
> >>
> >> ...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.
> >
> >
>
>
>
> --
> John Luther
> SVP, Product Strategy
> jwplayer.com
>