Partitioned Popins

[arichiv]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Partitioned Popins
• GitHub URL: https://github.com/arichiv/partitioned-popins/
• Explainer URL: https://github.com/arichiv/partitioned-popins/blob/main/README.md
• Spec URL: TBD
• Proposal authors: @arichiv @johannhof @krgovind
• Bug Tracker URL: https://issues.chromium.org/issues/340606651
• Chrome Feature URL: https://chromestatus.com/feature/5949561398099968
• Mozillians who can provide input: @bvandersloot-mozilla
• WebKit standards-position: Partitioned Popins WebKit/standards-positions#349
• Tag Review: Early Design Review: Partitioned Popins w3ctag/design-reviews#956

Other information

A new web primitive is needed to cover short-lived popup use cases which require access to storage partitioned by the popup opener. This primitive should be private and secure by default, while providing a consistent UI experience across user agents. To solve this need, we propose the “Partitioned Popin”, a type of pop-up for loading web content with two unique new features: a modal-like UI relative to its opener tab and cookies/storage being partitioned to its opener context.

[bvandersloot-mozilla]

Thanks for requesting this position and for the work writing this up. This is an interesting new primitive. I have a couple of related questions for clarification:

1. Would a popover iframe be sufficient for the use cases?
2. Have you considered the risk of a phishing page spoofing the layover security-critical browser UI? I'm not as wed to the line of doom as some are, but this would be a big UX shift, you are targeting authentication flows, and autofill behavior is an open question.

[arichiv]

1. In terms of storage/cookie partitioning alone an iframe would be sufficient for many use-cases, but there was concern with encouraging such pages to weaken embedding prevention measures.
2. Our hope is that by making the popin an independent window, as any popup would be, that the risk is somewhat mitigated (or at least not worse than existing concerns around popups). As for autofill, we definitely have to consider whether to encourage keying off of the opener origin or the top-frame origin.

[bvandersloot-mozilla]

An important question here is what protections are relied upon by the embedding protections (e.g. frame-ancestors CSP). My understanding of the login page use is that it is intended to prevent training users to enter their IDP credentials on pages other than the IDP's specific login page and to prevent clickjacking. This is where my concern on the second question is amplified. Popping-in could be faked convincingly, especially if password managers did not autofill.

Clickjacking may be the missing protection here, but this feels like a big change with lots of unexplored risk where a more targeted clickjacking protection would be more useful and less risky.

If the protections sought by refusing to use an iframe are different than the UX and clickjacking concerns, let me know.

[arichiv]

I believe UX and clickjacking concerns are the primary ones, but we do also want to try not to violate a login page's potential desire for crossOriginIsolation if possible.

[bvandersloot-mozilla]

I think it is best to defer a position on this until there are answers to how to mitigate in-content spoofing of the interface and how a password manager should treat this window.