- From: Philip Jägenstedt <foolip@google.com>
- Date: Fri, 02 Jun 2017 08:07:47 +0000
- To: Simon Stewart <simon.m.stewart@gmail.com>, "youenn@apple.com" <youenn@apple.com>
- Cc: Alexandre GOUAILLARD <agouaillard@gmail.com>, Mike Pennisi <mike@bocoup.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: <CAARdPYedeKj=7T+0FsCfEHR-2jkasvRq5ObSaDfNbuOLSzb_=A@mail.gmail.com>
+Youenn Fablet <youenn@apple.com> FYI, this will have some relevance for WebRTC test automation. On Thu, Jun 1, 2017 at 2:40 PM Simon Stewart <simon.m.stewart@gmail.com> wrote: > Hi, > > Thanks for preparing the document. I've added a couple of comments to it. > > Do we feel the best place to have the discussion is in the comments of > that doc, or here in this thread? I'm happy either way, but (ignoring > extensive evidence to the contrary) I'm not fond of repeating myself :) > > Cheers, > > Simon > > On Mon, May 29, 2017 at 4:45 PM, Philip Jägenstedt <foolip@google.com> > wrote: > >> 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 Friday, 2 June 2017 08:08:32 UTC