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

Re: [permissions] Defining a testing API

From: Mike Pennisi <mike@bocoup.com>
Date: Tue, 23 May 2017 13:55:05 -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: <dfd71364-17cd-178a-362a-40a4546fb8c5@bocoup.com>
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.


I'm specifically interested in what Mounir and Simon have to say, but I'd
welcome input from anyone on the list.


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 Tuesday, 23 May 2017 17:55:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:01 UTC