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

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.


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

Received on Tuesday, 25 August 2015 22:29:24 UTC