Partitioned popups

[annevk]

@krgovind at the last Privacy CG call you floated an idea around popups. Whereby you could open a popup and get a handle to it, but the popup would end up being partitioned in some way. I was wondering how serious that idea was as there are other proposals around popup handling and I wonder to what extent they should be pursued jointly.

cc @hemeryar

[krgovind]

Sorry for the delay in responding here; I wanted to acknowledge that we are indeed interested in pursuing the idea of allowing developers to opt-in to receiving partitioned-by-opener state in a popup. I'm working on writing up a rough sketch idea and will share here as soon as I've ironed out the kinks.

[darkowic]

We faced an issue with popups accessing a different storage reference than the opener. It seems to be similar to privacycg/CHIPS#82 but our primary use case is authentication.

The setup:

• first-party site A
• third-party site B that is embedded in site A via an iframe
• SSO IdP service C

The expected scenario and previous behavior

• A renders iframe containing B.
• B within iframe triggers a popup window that renders B app which attempts to authenticate using OIDC flow
• Within the popup, the user is redirected to SSO service C when they log in (they can also be already logged in; at least it is like this if both apps are under the same site).
• SSO service redirects back to B (part of OIDC flow) and tokens are obtained and stored in service worker
• The popup closes and iframe B detects the popup window has been closed
• B expects that the user is authenticated and tokens exist in the service worker and can be used

Unfortunately, the last point is not true anymore. B doesn't have access to the same instance of service worker and is never authenticated. We must open the auth flow in a separate popup because of security concerns (we can't and don't want to render the SSO login page within an iframe).

I hope it is a valid use case. We will be happy to provide additional information.

[krgovind]

@darkowic Thanks for the feedback! We now have a proposed API/solution for this scenario at explainers-by-googlers/partitioned-popins; which we are proposing to incubate in the PrivacyCG.

In your case; does the login state on C need to be carried to other first-party/top-level sites? Or is it sufficient if it is anchored to A? We'd love for your feedback via issues on the other repository.

[darkowic]

In your case; does the login state on C need to be carried to other first-party/top-level sites? Or is it sufficient if it is anchored to A?

Taking into consideration all the privacy effort here, I imagine that hoisting that login state to the first-party B site would be difficult and most likely harm the overall initiative (correct me if I'm wrong). However, the SSO C's state should be pointing to the first-party C state to not require the user to log in again if they were already logged in before. Then, after successful login, the B state can be safely partitioned under A site.

[krgovind]

@darkowic Got it. That is what I would call needing to "unpartition" C's state within the partitioned popin. This is alluded to as future work in the explainer at explainers-by-googlers/partitioned-popins; and something that could be potentially enabled via a user permission prompt within the popin. I would recommend that you direct your feedback as a new issue on that repository if possible; since this use-case is out-of-scope for this (storage-partitioning) repo.