Links

TPAC - The Future of Popups

GitHub

Attendance

Ari ChivukulaGoogle
Aaron Selya (Google Chrome)
Zachary Cancio (Google Chrome)
Kyra Seevers (Google Chrome)
Jeremy Roman (Google Chrome)
Sandor Major (Google Chrome / Privacy Sandbox)
Simeon Vincent (Mozilla / WebExtensions Community Group)
Johann Hofmann (Google Chrome)
Matthew Finke (Apple)
Annette Greiner (Berkeley Lab)
Chetan Krishna (PayPal)
Paul Zuehlcke (Mozilla)
Brad Triebwasser (Google Chrome)
Abrar Rahman Protyasha (Apple)
Ben Kelly (Google Chrome)
Mihai Cîrlănaru (Google Android)
Zachary Tan (Google Chrome)
Shuran Huang (Google Chrome)

Notes

What are popup use cases? Login, payments, background video/audio players, doc to print format, multi-window applications,
Issues devs/browser vendors encounter. Need to have a window proxy linkage. Window.opener might break cross-origin isolation. Strange situations with storage partitioning is changing. Popup would have access to same embedded cookies no longer the case.
Stranger experience on mobile. Might open in a separate tab, pushes you into that UI. unclear whats going on.
Hard to manage of the position on desktop.
Issues with spam. Ideally all popups are ons the user wants to interacts. But sometimes they’re blocked when they shouldn’t been.
Cookie in popup not available in embedded context if partitioned.
Replacing old popups. popups that need first party state, but not opener communication. Popups that could use partitioned state with communication opener. Some popups that need to share cross-site with their opener.
Popup replacement.
Redirection. General purpose solution. Need some kind of server side communication, or sending tokens of http. Strange loops w/o user to reenter. Hard to understand usage for tracking vs user functionality.
FedCM is federated login flow, like Google, this is a browser native way for user to login that doesn’t require a generic popup. Doesn’t necessarily require 3p cookies. Complexity in implementation. Not a general solution for popups.
Payment request. Integrate with the OS native payment method. Have it pre-pop with information. Might manifest that looks like a popup, but UI is more primed to trust and is more limited in scope.
Document Picture in picture; video tag in PIP. Root frame of a window is able to open. Limited to one per browser. Populate with whatever. PIP window opened is forced to be anchored in a corner. Depends on browser. Can’t have multiple going at a time. Hovering over a browser. Root Same-origin to frame that opened it.
Partitioned Popins- popup limited in key ways; partitioned as iframe in opener. Iframe and popup have access to same cookies. Don’t need 1st party state in popup. Locked to the tab that opened it. Would reappear when you go back to the tab. Couldn’t interact with tab until the popin closes.
Companion Windows - super iframe that can survive the same origin navigation. Popout an audio player that survives navigation same origin. Don't want to redesign like Youtube.
Open discussion
What extent we live with popups or need replacements?
Johann - popups with opener access are a problem from a privacy pov. Retaining tracking identifiers and exchanging those through opener connection that you retain. How do we retain use cases for user benefit and we’re hoping that partitioned popins that cuts off a large % of that space. Opener access but okay to share partition access. Like an iframe that can communicate with the embedder. But its more secure because it can’t be manipulated by the embedder. 3rd bullet point - popups that surely need to share cross-site state with their opener. What is the sufficient replacement for those? Could be FedCM. Or is this partitioned popin that can be upgraded, but for one domain that needs to get out use SAA prompt.
Jeremy - When we say replace? How ambitious are we being? More capabilities to have devs migrate towards them. Or break or remove some of things that characteristics we don’t like.
Johann - its hard to deprecate if they’re being used. Popups are a feature that a lot of sites are using it.
Jeremy - window.open wouldn’t get deleted. But limit the opener communication.
Ari - goal is not replace popups. New APIs offering additional functionality that make it better experience. Is replacing popups a goal?
Simeon (web extensions cg) - similar user cases covered, some that aren’t. Environments where web engines are used but not the web. Find ways extensions can coexist with web content without full access to the document itself. Inject an iframe onto a page so that an extension can do something useful, without requring full access to page by extension. How to upgrade the access in response to a action. Active tab, extension can get access to the tab. Inject content into the page without page knowing which extensions are injected, without extensions requiring page access. Isolate extension from rest of page. Parallel, but slightly orthogonal of core web use cases.
Ari - extensions could also be thought of as replacing popup functionality.
Ben - partners moving to solutions that rely on opener access more. A clear vision could save rework. Not sure if 3rd or 2nd bullet, but it's a difficult position to be asked is this (opener) is going to be available in the future. Don’t want devs to feel like they're building on sand.
Johann - having an early discussion leads to fear of “we’re removing xyz”.
Ben - not feeling threatened, but what's the alternative. If we’re not going to follow through on that, creating added complexity .
Johann - the truth is, all of these mechanisms that are not browser built APIs in the face of 3pc restrictions, need to discuss them with other browser vendors and web standards
Paul (Mozilla) - it is a problem worth solving. On the side of building fit-for-purpose apis. Training users that this is trusted UI and users can pretend to be another site. Referring to the pop-in solution.
Ari - intention is that its a separate system window. The requirement of interaction.
Paul - overlay the window
Ari - its draggable. Spoof a window inside web content. Can do that now with a popup.
Josh - popup video player on a new screen. Worried how people will use them for ads.
Jeremy - always possible to make annoyance.
Johann - special apis will alow limiting, but will resort to their old ways.
Jeremy - if we close companion window, would resort to div
Matt Finkel - outside of abusive use cases, from your convos with devs and partners. Are popups just a workaround they want to solve? Or do they genuinely want to show separate.
Ben - auth flow a SaaS provider, multiple idps, proxying auth through Idp. solution involves the popup and opener bc thats the way the web-platform. Want to support users with arbitrary IdPs.
Johann - they wouldn't be able to migrate to anything, maybe redirect, but if you give something that also works they will use it.
Jeremy - is there a reason FedCM can’t expand
Ben - partner tried to do FedCM. If you’re dealing N idps; need N Idps to adopt it. In an ideal world, its probably technically feasible, but its a collective action problem.
Jeremy -
Ben - very long-term view, and the pragmatic medium/short-term view. If opener is too appealing, then not enough to move to FedCM.
Johann - specifically for authorization two things: FedCM doesn’t do today, multiple IdPs. proxy idp stores session. The other: additional authorization info. You’re signed in, want to grant auth or additional setting.
Yi - Popups more appealing because its in-context. FedCM active mode, can replace via a popup through a native browser window. Multi-hop chain IdP is an issue, if everyone adopts fedCM could be made simpler.
Ben - should popups exist on the web - FedCM and very specific use cases should be working down those. Side of the web ecosystem. The composability that have not been considered. Ability to use for other use cases. Is there a path creates a popup that triggers SAA check. Still allows people to innovate. Keep even if not best UX if made safe.
Yi - popin solution it has good properties. With popups when i close browser window there are multiple behind it. Can it be addressed with popins?
Ari - if you close browser window should close all popins when the tab closes. I don’t know. I think there are extensions to that. Need to close. Popin that isn’t partitioned, open in some contexts.
Jeremy - when you blurred tab/window popin hides. If you click a different tab, it hides the popins.
Yi - If you go back to the original is the popin appear. Can two popins be used for abuse.
Ari - think through how it can be used for abuse.
Yi - accesiblility screen readers, need to re-announce.
Johann - Leaving devs the space to innovate. We have things like CHIPS and SAA, but FedCM for better use cases. Partitioned Popins is like the CHIPS like thing… Doesn’t work everywhere. Should we have a requestStorageAccess for opener access? Worth considering for solutions that we don’t have concrete apis for.
Ari - access to SAA only after a user interaction. If you open a popup it might immediately dismiss. For opener where one-page has secured access to shared buffer, so opener has to be
Zach - interested popins huge pain point to sign in with an idp; historically easy to use. Hidden behind other windows dig through to get it back. A flow, opens a dialog on top. Modal overlaps. Would a popin able to go into the browser area or go past window context. Can be anywhere on the screen. Goes hidden.
Jeremy - is that an intentional choice.
Ari - Anchoring to browser chrome at the top, does that get into.
Jeremy - can UA set?
Ari - browser vendors could do it differently.
Matt - one step closer to moving off 3pcs, these proposals are good refinements. I think the web has shown there are good use cases for popups. Having something more purpose built and has similar semantics. Curious for popups themselves, whether or time we can give them safer defaults. Like of adding storageAccess like opener prompt. Sever the opener if it has 1pcs; partition popups so that only same as iframe that opened it. To make things work seamlessly. Can popups work similarly but with permissions to get access.
Ari - probably need to pursue both. Make popups safer by default. Limiting functionality on the opener long timeline. Distinction you want to entirely go away, vs ones you want to have permissions.
Johann - default partitioning, a big reason of partitioned popins, need a way thats user understandable. Can’t partition popup. Often they’re new tabs. Ability to change the URL bar, we found coherent concept. This is way we went with a opt-in approach.
Jeremy - request opener access API; i worry the concept of opener access for web and browser devs, maybe get delegated. “Do you want foo.com to manipulate the address?”
Johann - sketching in my head. Changing to something like a promise. A user can confirm close and send token back. Similar with SAA.
Ari - impossible to message
Ben - prior art for bounce tracking mitigation; we only enforce those if 3pcs are blocked for 1p/3p pair. If 3p gets SAA for that 1p; then the redirect flow just works. Could do something similar to opener restrictions. “These two sites” can share data doesn’t allow DOM manipulations.
Ari - don’t necessarily like one permission to rule them all;
Ben - similar concept of cross-site. Semantically similar.
Matt - super curious about DOM manipulation of cross-site popups.
Ari - For Popins this is blocked even if same origin. If you have two things locked down; if they’re in control of what cross-origin open. Maybe not bad to do synchronous dom manipulation.
Johann - rel=nopener - btw… if we are to design a new api; this is a problem for security don’t want to reproduce