Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partitioned popups #28

Open
annevk opened this issue Mar 2, 2022 · 5 comments
Open

Partitioned popups #28

annevk opened this issue Mar 2, 2022 · 5 comments

Comments

@annevk
Copy link
Collaborator

annevk commented Mar 2, 2022

@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
Copy link

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
Copy link

darkowic commented Jul 2, 2024

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
Copy link

krgovind commented Jul 2, 2024

@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
Copy link

darkowic commented Jul 3, 2024

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
Copy link

krgovind commented Jul 3, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants