Re: [w3c/permissions] Add another permission state "always-ask" (from one-time grants)? (Issue #414)

Best permission UX practice for developers is to prompt in context, i.e. always provide sufficient rationale (whether implicitly or explicitly). Websites already have at least two ways to determine whether they’ve previously primed a user, or alternatively infer the permission action the user took in the last visit:

1. They can use cookies or local storage to persist whether a user has previously been successfully primed. This approach is sufficient to streamline the process of, for example, joining a meeting in the context of a returning user who grants ephemerally (e.g. https://github.com/w3c/mediacapture-main/issues/928)
2. They can use cookies or local storage to persist whether the site has a grant. If the site also employs change listeners, they can correctly deduce whether a user has previously granted ephemerally in the vast majority of cases.

[This comment](https://github.com/w3c/permissions/issues/414#issuecomment-1430414069) says that approach 1) has previously been proposed to developers [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1609427) but was rejected due to the number of edge cases. Approach 2) was also mentioned in that discussion. The following summarizes the concerns developers raised:

1. There is no way to account for, and detect all of the ways in which users can change permissions after granting them without access to this API.
     - This concern only applies to approach 2), since approach 1) does not aim to detect types of grants & permission changes.
     - However, adding the state “always-ask” to the permission query API does not address this concern. For example, resetting a permission should also remove the always-ask state. Thus, this is a case that can’t be handled by either API version.

2. There are a myriad of edge cases that can cause the localStorage value to not be reliable
    - If multiple tabs to the same site are open, all share the same localStorage. While all localStorage operations are synchronous, if improperly used, it’s easy to imagine scenarios where one open tab to an application ‘pollutes’ values that are read and processed by the same application open in other tabs. This is an implementation concern, and not an inherent lack of reliability of localStorage.
    - Considering the site can use the query API to determine whether a permission is currently in state “granted”, “prompt” or “denied”, approach 1) is sufficient to offer good permission UX, since it provides the user’s previous permission action/state, as well as their current permission state.
3. The storage solution does not allow the site to distinguish a permanent grant from a one time grant 
     - Since the site has the grant now, it can provide the functionality it wants to provide. We don’t want to give developers information about whether the current grant is one-time or a persistent grant since this would give developers the power to reject one-time grants. This would go against the very goal of one-time grants, which is giving the user more control and thereby improving privacy.

In fact, combining a query API response with a simple localStorage tag is already equivalent to adding “always-ask” to the API (the state “prompt” + tag implies “always-ask”). In Firefox’s permission model, the storage solution could even be made superior to the proposed API: by using change listeners and recording grants as well as revocations, the site can distinguish between “granted ephemerally last time” and “granted ephemerally in another tab”, which would both be considered “always-ask” in the proposed API.

For these reasons, we don’t see any benefit in extending the current query API with "always-ask".

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/414#issuecomment-1677132613
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/permissions/issues/414/1677132613@github.com>