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

> The pragmatic answer is: they just aren't.

Since implementation of such functionality is reasonably straightforward, I'm not convinced of this. A more likely reason for sites not using such solutions may be that there is no real need for them. However, how did you arrive at the conclusion that sites don’t employ such approaches?

> .. a subset of privacy sensitive users run with settings like this one in Firefox:  [Delete cookies and site data when Firefox is closed]

Assuming the always-allow state would be added to the API, you're implying that even though all cookies and site data are cleared, the site can still learn about a previous, ephemeral (!) permission grant that happened before the clearing. This would negatively impact privacy. I would be surprised if privacy-sensitive users would expect this behavior. It would also introduce a new bit of information that can be used for fingerprinting.

> Permissions outlive local storage in most browsers.

That's correct. There seem to be two cases

1. The user clears cookies & site data: In this case, information about previous priming would be lost because localStorage would be cleared. However, as mentioned above, I don’t think sites should have information about past ephemeral grants after the user cleared cookies and site data.

2. Cross-device synchronization of permissions: this is user-agent specific implementation that is not part of the permission spec. The spec neither says that user settings can or should be synchronized, nor does it say that site data should not be synchronized. For that reason, user agent specific implementations of cross device synchronization shouldn’t be the motivation for this API change. Additionally, in the cross-device scenario, the worst case is that the user would be primed once per device, instead of once in total. The impact this would have on user experience seems negligible. By requiring authentication, the site can also fully circumvent this concern by storing information about grants server-side instead of client-side.


> We felt it would have been better if something like "default" was the default, leaving the other states "granted", "denied" and "prompt" to always represent actual user choices. 

The permission state “prompt” is defined as:
 > "The user has not given express permission to use the feature (i.e., it's the same as denied). It also means that if a caller attempts to use the feature, the user agent will either be prompting the user for permission or access to the feature will be denied."

If the user agent should prompt on permission access, it doesn’t matter whether the user has previously granted ephemerally or not, hence “default” and “prompt” would be equivalent from a permission state perspective.

Exposing this permission state through site settings certainly makes sense, however independent of whether this setting option is labeled “Ask”, “Always Ask”, “Always prompt” or similar variations, the underlying permission state can be accurately represented by “prompt”.

In other words, “prompt”, “granted” and “denied” don’t represent user actions, but permission states. There is a clear distinction: a user action can change the permission state, but it doesn’t correspond to a permission state. Incidentally, a grant user action leads to the permission state “granted” and a deny user action leads to the permission state “denied”; that doesn’t turn permission states into user actions. For example, a persistently granted permission has permission state “granted” while there exists no user action. Having the query API return permission state instead of user action seems like a good approach.

> Of course it's clearly too late to undo that mistake now, hence this request for a new "always-ask" value.

I disagree with the assumption that a mistake was made, and don’t see how adding "always-ask" is an improvement. “always-ask” introduces ambiguity, since “always-ask” and “prompt” both behave the same. Additionally, never resetting "always-ask” doesn’t seem like a good path forward due to the negative privacy impact.

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

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