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

FYI, I have implemented the proposal. There are a few remaining issues,
which we'll continue to track in the Bug 25923
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923>.

David

On Mon, Oct 6, 2014 at 1:41 PM, Mark Watson <watsonm@netflix.com> wrote:

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

Received on Monday, 13 October 2014 23:37:06 UTC