Re: Concurrent streams: detection vs enforcement

On Wed, May 6, 2015 at 4:49 PM, David Dorwin <ddorwin@google.com> wrote:

>
> On Tue, May 5, 2015 at 9:18 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>> I wonder if we should make it even clearer that the license renewal
>> mechanism is targeted at *enforcement* of concurrent streams, wheras the
>> key release mechanism is targeted at *detection* of abuse ?
>>
>
> This is important information for understanding the usage of the key
> release mechanism, so this makes sense if detection is the only use case.
> ("Targeted at" doesn't exclude other uses, so I just want to confirm the
> intent.)
>

​Yes, the intent was to clarify that detection is the only use-case.​


>
>> Presently, the wiki titles are:
>> "Limited concurrent streams via license renewal"
>>
>> and
>>
>> "Limited concurrent streams via key release"
>>
>> I suggest we change these to:
>>
>> "Enforcement of concurrent stream limits via license renewal"
>>
>> and
>>
>> "Detection of concurrent stream usage via key release"
>>
>> It's worth noting, if there is still concern that the detection mechanism
>> eventually getting used for enforcement, that the arguments against license
>> renewal (UX, scalability) don't apply if enforcement is restricted just to
>> those accounts where abuse has been detected.
>>
>
> Does this mean Netflix is also interested in license renewal? (Not for
> general use, but would like it to be available to be applied as necessary?)
>

​The use-case wiki has long listed renewal as "recommended" and we are
happy with that. This isn't the place for discussion of our product
requirements.​


>
> Is this a new development? Is this combination the reason that Netflix no
> longer requires delaying shutdown for its use-case?
>

​I do not believe I have ever asked for delayed shutdown to be *required*.
I did change my position at the face-to-face by dropping my request that
messages-at-close be *allowed, *in response to your concerns, not because
of anything to do with license renewal.

It's important that we ensure that service providers have options to
address fraud if it becomes a problem. If I understand correctly, your
concern is that, in future, modifying secure release to support enforcement
might rear its head and such modification implies delayed shutdown, which
you've explained is unacceptable. So, the solution to this is
identification of *other* options which could serve as contingencies. It's
clear that license renewal is another option and - even better - as a
contingency added to a detection mechanism it does not suffer from the
problems we've identified with using it at scale.


>
> If so, that makes sense; I just want to make sure we understand correctly.
>

​I still think it would be useful if you could explain exactly what
"delayed shutdown" means to you and why it cannot be supported, so that we
can avoid anything else in future running into the same issue. I think I
have a pretty good idea, but I could be missing something or making
incorrect assumptions. Is is accurate to say that anything that relies on a
page receiving an onbeforeclose or onclose event should be avoided ? Is
that a sufficient definition ?

...Mark​



>
>> Shall I make this change to the wiki ?
>>
>> ...Mark
>>
>>
>>
>