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

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 ?

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.

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

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.

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.

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.

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