- From: Philip Jägenstedt <foolip@google.com>
- Date: Mon, 29 May 2017 15:45:42 +0000
- 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>
- Message-ID: <CAARdPYd+C061rG3PNAD_R=+2m1sFJ6jG5yvFEThJ2hStX+DkpQ@mail.gmail.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