W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2016

Re: Permissions store

From: Martin Thomson <mt@mozilla.com>
Date: Wed, 17 Aug 2016 23:26:37 +1000
Message-ID: <CAPLxc=UYQdGagZ4tqsYh9Mp4xdcytnxR6c-Yz=RGJiydoC_dUA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Raymes Khoury <raymes@google.com>, Jeffrey Yasskin <jyasskin@google.com>, WebAppSec WG <public-webappsec@w3.org>, Marcos Caceres <marcos@marcosc.com>, Mounir Lamouri <mlamouri@google.com>, Ben Wells <benwells@google.com>
On Wed, Aug 17, 2016 at 6:29 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> Is the fact that there has been a click observable from script in any
>> reliable way?  I guess that you can show popups and check if they were
>> displayed, but that's massively annoying.
>
> Well, you get a click event...

In practice, browsers have a window after the click event in which
they will accept a popup.  Microtasks in the same crank of the event
loop are definitely ok, and I believe that setTimeout(..., 0) is too,
even though that takes a non-zero amount of time.

>> Where I'm going is that this implies a new entry to the key:
>> recent-click.  Well, if any browser wants to gate showing a prompt on
>> having clicks.
>>
>> That makes .query() less reliable unless we make the recent-click
>> state explicit.  I guess the same goes for any top-level flag.
>
> Presumably Chrome would return "granted" for the permission but still
> require the gesture. Which I guess arguably doesn't make it part of
> the key, but something else? I'm not sure to what extent that has been
> thought through.

I believe that the intent is to require a click only when showing the
permissions prompt, not on the acquisition of the resource.  So:

state==prompt: call api =>  denied
state==prompt: click then call api => prompt shown
state==granted: call api => success

you could model this as:

.request({name: "foo", click: true }) => "prompt"
.request({name: "foo", click: false }) => "denied"

Somehow, I don't think that was the intent though.
Received on Wednesday, 17 August 2016 13:27:08 UTC

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