Feature Request: passive/silent option for requestStorageAccessFor

[mikefleming]

Speaking as the engineering owner for YouTube identity and signin, we request an optional "passive" or "silent" option for requestStorageAccessFor which would enable storage access if and only if the user has already pre-consented to it and would not be prompted. This feature request can be seen as comparable to the "prompt=none" option specified in the OAuth RFCs.

We believe First Party Sets will be a valuable way to ensure existing single signon functionality continues to function for users. We would like to use First Party Sets to achieve this goal. However, our experience has shown that, by themselves, the storage access prompts presented by the browsers do not always contextualize or convey the user choice in a way that helps them understand the use case they're being asked to enable. That is, if a user is in a situation where using requestStorageAccessFor would cause a prompt, we would like the opportunity to either explain that prompt to the user beforehand or choose another signing option (such as FedCM).

[cfredric]

I believe the passive/silent option would be mostly satisfied by the existing Permissions API (e.g. via navigator.permissions.query). I wrote up some example code here.

We (Chrome) have some work to do to fix this for document.requestStorageAccessFor in particular (as opposed to document.requestStorageAccess more generally) - this is tracked here. But if you can use the storage-access permission instead, this approach should work correctly in Chrome M113 within a First-Party Set, and it will work in Chrome outside of a First-Party Set when Chrome ships Storage Access API support more broadly.

[mreichhoff]

As @cfredric mentioned, I believe the spec as-is supports this via its permissions integration. The Chrome implementation work for permission listeners is trackable in the linked crbug task; permissions.query should already work (and if not, that would also be a candidate for crbug.com, rather than a spec issue).

I do note that both requestStorageAccess and requestStorageAccessFor could consider returning granted with permission queries in the event that the user agent's implicit (without user prompt) grant logic would be met (e.g., because of being in the same first-party set, or because some numeric limit isn't reached), but I think that gets messy because:

• user activation is still required in such cases, so a granted permissions query would not indicate that a call to either API would resolve successfully.
• the information browsers use to determine whether to grant without a prompt may be time- or usage-based (where there could be race conditions where the query would return granted, but a future call could be rejected based on use on some other page or because some time limit was reached).

Accordingly, I think we probably want to leave the spec alone at this point. Closing.

[mikefleming]

I would like to request that this bug be reopened.

I am happy with delaying until user activation. I'm happy if the query API has any value prior to user activiation.

My request is indeed that if the prompt occurs conditionally via some time or usage metric, that I be aware of that so I can decide whether to delay the prompt or contextualize it.

If I cannot make this determination, First Party Sets may not have any value for me at all over FedCM (where the user interaction will be more deterministic, and easier to appropriately contextialize)