- From: David Dorwin <ddorwin@google.com>
- Date: Mon, 13 Oct 2014 16:36:18 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-html-media@w3.org" <public-html-media@w3.org>, Anne van Kesteren <annevk@annevk.nl>
- Message-ID: <CAHD2rsg+93zbKRHZpbmuTZD5UantK+jzAonzZ1fhR52pyrXa+Q@mail.gmail.com>
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