- From: Jan-Ivar Bruaroey <notifications@github.com>
- Date: Tue, 13 Jun 2023 11:52:58 -0700
- To: w3c/permissions <permissions@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/permissions/issues/414/1589855689@github.com>
The premise here is that "once"-permissions represent a level of user buy-in worth persisting and informing apps about: 1. `"denied"` — user has blocked permission and there will be no prompt 2. `"prompt"` — no indication of user trust and there will be a prompt 3. `"granted-once"` — user accepted permission last time but there may be a prompt 4. `"granted"` — user has accepted permission on every visit and there will be no prompt Here's an [example](https://jan-ivar.github.io/dummy/gum_and_query.html) using a [shim](https://jan-ivar.github.io/polyfills/granted-once.js) in Chrome Canary 116 which is running a user experiment I appear to be included in:  I click the top choice, _"Allow this time"_, and `navigator.permissions.query` now says `"granted"` (I'm examining my choice from the URL bar which is why you don't see my face):  If I ↻ it's still `"granted"`, but once I close the tab and reopen it, I'll be prompted again. This is where my shim kicks in:  Instead of `"prompt"` it returns `"granted-once"` to reflect that the user's last interaction with the prompt was positive. This gives the website extra information which it can use to decide whether to accept the current level of permission as satisfactory, or continue to train/push the user to escalate permission to every visit in order to avoid the training. In short, I think this is the right abstraction to capture the current diversity in user agents and UX. The [shim](https://jan-ivar.github.io/polyfills/granted-once.js) is imperfect¹, but highlights that there's more state to tackle here than websites want to deal with just to work reliably in all user agents. --- <sub>1. The shim relies on localStorage, and thus cannot detect user changes when the page is closed. It's also hampered by Chrome not notifying the page for some reason when the user chooses to "Reset permissions" even while the page is up (a bug?). Still, it tries to remove</sub> -- Reply to this email directly or view it on GitHub: https://github.com/w3c/permissions/issues/414#issuecomment-1589855689 You are receiving this because you are subscribed to this thread. Message ID: <w3c/permissions/issues/414/1589855689@github.com>
Received on Tuesday, 13 June 2023 18:53:04 UTC