W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2017

Re: [permissions] Defining a testing API

From: Mike Pennisi <mike@bocoup.com>
Date: Wed, 24 May 2017 10:21:54 -0400
To: Simon Stewart <simon.m.stewart@gmail.com>
Cc: Philip J├Ągenstedt <foolip@google.com>, David Burns <david.burns@theautomatedtester.co.uk>, Alexandre GOUAILLARD <agouaillard@gmail.com>, public-webappsec@w3.org, James Graham <james@hoppipolla.co.uk>, Boaz Sender <boaz@bocoup.com>
Message-ID: <c7503997-0327-374e-7d96-8e74194ca266@bocoup.com>
Understood. Thanks, Simon

On 05/24/2017 04:13 AM, Simon Stewart wrote:
> Hi,
> It's going to be at least a week until I can look at this, but I'll do
> so as soon as I can.
> Kind regards,
> Simon
> On Tue, May 23, 2017 at 8:55 PM, Mike Pennisi <mike@bocoup.com
> <mailto:mike@bocoup.com>> wrote:
>     Okay, great! I've created a Google Document to begin brainstorming
>     what this
>     patch would look like. If you folks could validate the scope of
>     work I'm
>     proposing, then I would be happy to draft a patch for the
>     Permissions API. From
>     there, we could have a more concrete discussion via a GitHub pull
>     request,
>     knowing that we were on the same page in terms of the desired outcome.
>     https://docs.google.com/document/d/1Oe4VhgdFnZ6ID3WGyG97n_b1khvYsRcX7T4ddNcyJ9A/edit#
>     <https://docs.google.com/document/d/1Oe4VhgdFnZ6ID3WGyG97n_b1khvYsRcX7T4ddNcyJ9A/edit#>
>     I'm specifically interested in what Mounir and Simon have to say,
>     but I'd
>     welcome input from anyone on the list.
>     Thanks!
>     Mike
>     On 05/12/2017 11:08 AM, Simon Stewart wrote:
>>     Inline, and to everyone this time.
>>     On Fri, May 12, 2017 at 3:54 PM, Mike Pennisi <mike@bocoup.com
>>     <mailto:mike@bocoup.com>> wrote:
>>         > Does anyone have a rough idea of the shape for this
>>         extension yet? Would it
>>         > be reacting to permission requests, taking the place of the
>>         prompts, toggling
>>         > the permissions independent of requests, or both?
>>         Reading David's response again, I'm not so sure. My previous
>>         message was a
>>         little unclear, so my original question still seems relevant.
>>         I'll try to
>>         rephrase in a more coherent way:
>>         Simon mentioned how he and Andreas were designing an API for
>>         interacting with
>>         "door hanger" notifications. This sounds completely
>>         necessary, but I suggested
>>         that *first*, we would need a standard mechanism through
>>         which those
>>         notifications could be created.
>>     As a browser vendor, or someone implementing specifications, I'd
>>     agree with that ordering. As a user of a browser, I'd disagree:
>>     the UI is already in place in both Chrome and Firefox (IME ---
>>     those are the browsers I use most), and users have already been
>>     trained to look for them in those browsers.
>>     A standard mechanism would be lovely from an implementation point
>>     of view.
>>         My question was: does that mechanism need to be
>>         defined in a dedicated specification? It seems possible that
>>         it could be
>>         contained within Permissions, but if other specs need this
>>         ability in contexts
>>         other than permission management, then maybe not.
>>     It needs to be defined _somewhere_. One approach would be to
>>     define it in the Permissions specification with an eye to sharing
>>     it between different specs if it proves generally useful. Another
>>     approach would be to define the webdriver extensions required by
>>     the Permissions specification to be exactly specific for that
>>     spec. Either way, I think it's best done as part of the
>>     Permissions specification for now.
>>     In both cases, I'd be happy to advise on the webdriver specific
>>     parts, as, I'm sure, would others in the WG.
>>         If there was a standalone "Privileged User Prompt" spec, then
>>         introducing
>>         automation abilities there might preclude the need to do so
>>         within Permissions.
>>         In that world, Permissions would reference the "Privileged
>>         User Prompt" spec in
>>         "Prompt the user to choose" [1]. Instead of scripting the
>>         internal
>>         "permissions" state directly, test code would control
>>         permissions through
>>         scripted interaction with the notifications themselves.
>>     Agreed.
>>         Although this would be less artificial, I'm not sure the
>>         distinction would
>>         matter in a practical sense. This supposed
>>         "Permissions-to-Notification"
>>         interface would be an implementation detail to web
>>         developers, so whether it
>>         was exercised or not probably wouldn't be observable from
>>         application code
>>         anyway.
>>         ...but I'm getting ahead of myself. Can anyone say whether a
>>         new specification
>>         is appropriate?
>>     The lowest friction thing to do right now is to add a section in
>>     the Permissions spec that defines the webdriver URLs and messages
>>     that would be needed. If this WG has a F2F at TPAC, we could add
>>     this an agenda item too.
>>     Kind regards,
>>     Simon
Received on Wednesday, 24 May 2017 14:22:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:23 UTC