Feature Request: Allow an iframe to request Storage Access permission before the user has visited the origin at the top level

[enriquepablo]

Our use case is a Discovery Service - SeamlessAccess (SA). In this scenario the common flow is that the end user visits a Service Provider (SP) with the SA button embedded in an iframe, and upon clicking it, the user is sent to SA at the top level, where they can choose an Identity Provider (IdP). Ideally this choice, if stored in a cookie, would be available to SA embedded in the page of the SP, when the user returns to the SP. We are calling requestStorageAccess when the user clicks on the SA button embedded in an SP. The current behavior results in this UX:

• User visits SP with embedded SA iframe;
• User clicks on SA button and is sent to SA at the top level;
• User chooses an IdP, and SA stores the choice in the cookie;
• (...)
• User returns to SP, but the iframe cannot yet access the cookie;
• User clicks the SA button, and now requestStorageAccess prompts the user for access permission;
• On subsequent visits to the SP, the iframe can access the cookie.

Ideally, on the 2nd visit to the SP, the iframe would already be able to access the cookie. This would be possible if requestStorageAccess were not prevented, by the lack of a previous visit to SA at the top level, to ask for access permission on the 1st visit.

[johannhof]

Hi @enriquepablo, thanks for sharing the Discovery Service use case, that's quite interesting. What I don't really understand is why the user gesture on the SA in the third step and subsequent requestStorageAccess invocation isn't sufficient, maybe you can help me understand when you would spawn the storage access prompt instead? Before the redirect to the SA at the 2nd step?

cc @samuelgoto @cfredric @bvandersloot-mozilla As we discussed offline it would be good to consider some long term path forward for these Discovery Services / IdP Proxies when the IdP chooses to use FedCM.

[enriquepablo]

Hi @johannhof - The thing is that the user gesture in the 3rd step is happening with SA at the top level, so there's no room for calling requestStorageAccess there. So yes, for an optimal user experience we'd like to spawn the prompt before the redirect to SA at the top level, at the 2nd step. This would be specially helpful with the current (v123) firefox behavior, which resets the "storageAccessRequest state" in each browser session, so the prompt will only be spawned when there is a browser session in which the user visits SA at the top level before any SP - highly unlikely. I have also filed a bug in the ff bugzilla in this regard.

[johnwilander]

This has been requested before and I explained the link gatekeeper attack. With such functionality, a popular source of traffic like social media could force the user to accept access to cross-site cookies on destination sites to allow them to navigate.

[enriquepablo]

Sorry I haven't found that discussion, or any reference to the link gatekeeper attack.

I don't mean that an origin when visited at the top level will be able to provide storage access permission for itself when visited in an iframe. What I mean is that when a user visits a site with another origin embedded in an iframe, that embedded origin will be able to ask for storage access permission independently of whether the user has already visited the embedded origin at the top level or not.

In my view, the fact that an origin has or has not been visited at the top level may be useful for heuristics on whether to mediate granting access permission automatically or by spawning a prompt. But if when the user visits, say, a newspaper site, with a social site link embedded, the user is prompted to give permission to the social site to access storage when embedded it that newspaper, I don't see that the social site will be in any advantageous situation that it can leverage to force the user into allowing a privacy invasion, and that wouldn't exist if the user had visited the social site at the top level first.

I don't doubt I am missing some way of abusing what we propose, but I just don't see it in this case.

[enriquepablo]

Ok I think I see what you mean - a popular source of traffic might force their users to give storage access permission to other 3rd party embedded origins. Yes I can see this might be a problem, and I can see that requiring top level 1st navigation is a mitigation. I guess that to really compromise privacy the end user would have to keep giving permission to that 3rd party when embedded in origins other than the popular social media. But if there is nothing new in this discussion I am fine closing the issue.

[enriquepablo]

It seems that firefox 124 behaves as requested here, so I'll leave this open.