More explicit exception handling for StorageAccessAPI

[bretticus-mc]

The StorageAccessAPI throws a DOMException if the requestStorageAccess call is denied. The exception throws the same generic "requestStorageAccess not allowed" message even though there are a number of reason the RSA call can be denied (user explicitly blocked access, a user gesture is needed, top-level interaction needed, user closed the UI prompt X times, etc). The console does show a more explicit message for the deny failure. It would be great if wording similar to the console message was included in the exception.

We have an application where customers solely interact with it in an embedded context. We've found that the RSA calls are being denied because the customer has never interacted with our product in a top-level context. Therefore, we need to generate a popup with our domain as the top-level context where customers can interact with it for the RSA call to succeed. With more explicit exception handling, we could generate said popup only when the customer runs into the "top-level context interaction" denial. Otherwise, we'll be forced to spam all of our customers with popups every time they need to use the StorageAccessAPI.

[cfredric]

This request is related to privacycg/storage-access#60. I suggest engaging in that repository if you would like to change the specification, but I think it's unlikely for this decision to be changed; it was an explicit goal to avoid exposing to the script the reason why the request was denied. This was to discourage retaliation by the script if the user denied/dismissed the prompt.

I think there are other ways that you can mitigate the need for a popup:

• You could use some kind of partitioned state, e.g. CHIPS or partitioned localStorage, to store a showedPopupAt = <timestamp> signal so you could avoid opening a popup more often than once per month under a given top-level site.
• You can store the top-level interaction timestamp in unpartitioned DOM storage or a cookie (belonging to your site) from the popup, so that as soon as future popups open, they can immediately read that state and close themselves without requiring attention from the user.

With that in mind, a given user only needs to interact with one popup per month. Does that sound reasonable to you?

My suggestion does mean that you'll potentially be opening N popups per month (if your application is embedded under N distinct top-level sites and a given user visits all of them), even though the user will only interact with one popup. So I'm curious:

• Under how many top-level sites is your site embedded?
• What proportion of your users use your application while it's embedded under 2 or more distinct sites?
• What proportion of your users only use your application while it's embedded under a single top-level site?

[samdutton]

@cfredric @bretticus-mc I'll close this since there's been no additional discussion for more than four weeks, but reopen if necessary.