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

Re: [permissions] Defining a testing API

From: Philip Jägenstedt <foolip@google.com>
Date: Mon, 29 May 2017 15:45:42 +0000
Message-ID: <CAARdPYd+C061rG3PNAD_R=+2m1sFJ6jG5yvFEThJ2hStX+DkpQ@mail.gmail.com>
To: Alexandre GOUAILLARD <agouaillard@gmail.com>, Mike Pennisi <mike@bocoup.com>
Cc: Simon Stewart <simon.m.stewart@gmail.com>, David Burns <david.burns@theautomatedtester.co.uk>, public-webappsec@w3.org, James Graham <james@hoppipolla.co.uk>, Boaz Sender <boaz@bocoup.com>
Thanks for preparing that doc, Mike! I've commented and asked for some
discussion of the options and which we should pursue first.

On Wed, May 24, 2017 at 11:41 PM Alexandre GOUAILLARD <agouaillard@gmail.com>
wrote:

> Hi guys,
>
> same on my side, nothing before june 1st. Sorry about the inconvenience.
>
> On Thu, May 25, 2017 at 12:21 AM, Mike Pennisi <mike@bocoup.com> wrote:
>
>> 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> 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#
>>>
>>> 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> 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
>>>
>>>
>>>
>>
>>
>
>
> --
> Alex. Gouaillard, PhD, PhD, MBA
>
> ------------------------------------------------------------------------------------
> President - CoSMo Software Consulting, Singapore
>
> ------------------------------------------------------------------------------------
> sg.linkedin.com/agouaillard
>
>    -
>
>
Received on Monday, 29 May 2017 15:46:46 UTC

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