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

Re: [permissions] Defining a testing API

From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Thu, 25 May 2017 07:41:56 +1000
Message-ID: <CAHgZEq7zGOC7uG57O+5HiJA-f6=WLivCLxiK4rQtAvOpqj1Sfg@mail.gmail.com>
To: Mike Pennisi <mike@bocoup.com>
Cc: Simon Stewart <simon.m.stewart@gmail.com>, Philip J├Ągenstedt <foolip@google.com>, David Burns <david.burns@theautomatedtester.co.uk>, public-webappsec@w3.org, James Graham <james@hoppipolla.co.uk>, Boaz Sender <boaz@bocoup.com>
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_b1
>> khvYsRcX7T4ddNcyJ9A/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

Received on Wednesday, 24 May 2017 21:42:35 UTC

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