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

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