Re: [EME] Handling CDM availability, permissions, and supported types

I wasn't arguing that your proposal doesn't work, only trying to see if we
could do something simpler. Seems that having a static and member method,
with the same signature and with the only difference being that the static
one might be optimistic (might not have access to user preferences) is
simpler to understand and implement than the one you proposed.

...Mark

On Mon, Oct 6, 2014 at 1:34 PM, David Dorwin <ddorwin@google.com> wrote:

>
>
> On Mon, Oct 6, 2014 at 11:28 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>> On Mon, Oct 6, 2014 at 10:46 AM, David Dorwin <ddorwin@google.com> wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2014 at 8:38 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>
>>>> Hi David,
>>>>
>>>> It's not clear to my why we can't require that all capability
>>>> information for all keysystems supported by a UA is registered with the UA
>>>> up front, so that the original isTypeSupported can operate in a synchronous
>>>> manner. This capability information is essentially a static table for each
>>>> keysystem. The UA presumably has *some* information for each supported
>>>> keysystem, even if the CDM itself has not been downloaded (for example, it
>>>> probably knows the URL and hash of the CDM) and that information could
>>>> include capability information. Is there some issue associated with
>>>> exposing that information in advance of CDM download ?
>>>>
>>>
>>> See the discussion in the bug. Yes, the UA could know the possible
>>> functionality (I called this "best case support" in comment 35
>>> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c35>), but the UA
>>> may not know what the user will allow. Also, it's possible that different
>>> functionality will be enabled depending on what the user allows (regardless
>>> of whether the CDM needs to be downloaded). The only way to provide the
>>> application with a definitive answer is to allow the prompt, download, etc.
>>> to take place before responding.
>>>
>>
>> Could we have a synchronous isTypeSupported​ method, which checks the
>> statically configured capabilities information and then a member method on
>> MediaKeys that checks what is actually supported / allowed after the user
>> permissions step ?
>>
>
> This is returning  "best case support." The API would have to be named
> such that this would be clear to the author. However, I don't think this is
> a common API model and I don't see why we would do this when we have an
> alternative.
>
>>
>> Then sites would use isTypeSupported to determine a keysystem supported
>> by the UA with the capabilities that the site needs, create the MediaKeys
>> (which might prompt) and then check that the returned MediaKeys object does
>> indeed support what they need.
>>
>
> It's also possible that no MediaKeys object is returned.
>
>>
>> This would seem to be an easy flow to implement, since the site will need
>> to handle the case where the createMediaKeys fails, so the case where it
>> succeeds but the "allowed capabilities" check fails can be handled
>> similarly (try a different keysystem, say).
>>
>
> What is the advantage of this two-step flow to the current proposal? The
> application would need to handle lack of support in at least two locations.
> It seems less likely that applications would implement this two-step flow
> correctly, especially to handle the potential for another key system.
>
> See the discussion starting at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c30.
>
>>
>> Additionally, if there are CDM capabilities that the user might not allow
>> (persistent identifier and persistent storage might be examples, since you
>> call those out), then a site might provide different levels of service
>> depending on whether these are supported.
>>
>
> This is also supported by the current proposal. (See the last item
> under Areas for Discussion.)
>
>>
>> So, we have "isTypeSupported" as a static method based on static
>> configured properties of the keysystem and "isTypeSupportedAndAllowed"
>> member method which is based on the post-download, post-prompt status.
>> [That naming might not be right, since once the load/permissions step has
>> been done once, you would expect the static isTypeSupported to return the
>> "supported + allowed" information.
>>
>
> The current proposal ensures that the correct response is always returned
> and applications only need one flow and one API to call.
>
>>
>> If users are to individually approve CDM capabilities, there is also a
>> problem of making it possible / easy for them to change their minds. A user
>> might click through a permission prompt quickly and they it would be sad if
>> we have to direct them to an obscure settings page to undo that and give
>> the CDM permissions that a site needs.
>>
>
> These are implementation details. I don't think the current proposal makes
> this any worse. If anything, it gives the user agent insight into what is
> required, which might help surface UX to help the user.
>
>>
>> ...Mark
>>
>>
>>
>>
>>>
>>>> Secondly, whilst it is up to UAs whether and when to prompt for user
>>>> permission, we should not assume that a permission prompt is required: the
>>>> ideal situation is that the CDM is designed such that it introduces no
>>>> incremental privacy or security risks to the user (and the UA knows this)
>>>> and so no permission prompt is required. I think we should aim for this
>>>> outcome.
>>>>
>>>
>>> The proposal does not assume or require a prompt, but it does consider
>>> it, which is necessary to design a solution that accommodates inclusion of
>>> this outside data into the response.
>>>
>>>>
>>>> ...Mark
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Oct 3, 2014 at 7:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>>
>>>>> On 10/3/14, 6:18 PM, David Dorwin wrote:
>>>>>
>>>>>>          1. If the member's name is unrecognized or unhandled and the
>>>>>>             value is not “optional”, continue to next iteration of
>>>>>> the loop.
>>>>>>
>>>>>
>>>>> This requirement can't be fulfilled for the "unrecognized" case.  See
>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c40
>>>>>
>>>>> Other than that, this makes me happy.
>>>>>
>>>>>        o It's unclear why this is the case or why the same rule does
>>>>>> not
>>>>>>         apply to Sequence. Maybe Boris knows.
>>>>>>
>>>>>
>>>>> Also see the link above.
>>>>>
>>>>> -Boris
>>>>>
>>>>>
>>>>
>>>
>>
>