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

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.

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