#956: Early Design Review: Partitioned Popins

Visit on Github.

Opened May 14, 2024

こんにちは TAG-さん!

I'm requesting a TAG review of Partitioned Popins.

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.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): PrivacyCG
  • The group where standardization of this work is intended to be done ("unknown" if not known): PrivacyCG
  • This work is being funded by: Google Chrome

Discussions

2024-08-26

Minutes

Martin: there will be a breakout session in TPAC about this... defer until after that.

2024-10-07

Minutes

no updates

2024-10-28

Minutes

Jeffrey: altetnatives mentioned FedCM, Storage acces, Exemption Heuristics... The question is is there a way to do UI that is clear enough?

Yves: to make sure that people are not tricked.

Jeffrey: that it's not the main origin but that it has access the identity of the origin if there is communicaiton. Not clear that there is any UI that can communicate that. We can ask for solid UX studies that users understand the right thing from some plausable UI...

Dan: user need.

Yves: SSO was listed .. but if fedCM is here then maybe it's not needed?

Peter: the user need is a need for business to maintain their current product... current business model. and i don't think this actually serves... users. It's a dangerous weakening of the web security model and user protections to support a dangerous use case that never should have existed in the use case.

Matthew: they have some UX proposals.. you end up with 2 URL bars ... which is a really really big change... Setting aside the issues they might have about understanding the URL anyway, but having 2 URL bars that would cause implementation pushback...

Dan: the URL is important.

Lea: (1) cookie partitioning and (2) the UI component ... still unclear what that UI is... not sure how these mockups differ from ...

Jeffrey: there's a "please note"...

Lea: what I was going to say is that the most contraversial of the 2 is the whole cookie thing... but not sure why that's needed. None of these address post messages... So why not just use post message? If this is a differnt way to open a popup...

Jeffrey: security benefits to using cookies ... we can make it more secure ... that's some of the motivation here.

Lea: but post message is just used when the popup communicates...

Jeffrey: yes but post message has to go through javascript... This would work without javascript. Core idea is that the authentication token is never exposed to javascript... The context here is that people hire companies to do their login for them - like Octa - so if your site is foo.example, it goes to foo.octa.com ... so it blocks cookies. There have been proposals to use CNAMES and some browsers have taken action to block use of CNAMES for this purpose... Authentication companies are worried about using CNAMEs for this purpose...

Lea: cost / benefit question is open but assuming they are useful - could we layer them differently? What if the different popup UI was a different component?

Jeffrey: example of this in the Arc browser today...

Dan: I've used Octa... I think the use case is valid...

Peter: but the reliance on 3p cookies - which was a bug ... what I'm opposed to is adding features to the web ... that exist purely to support someone's business needs... I have mixed feelings about the CNAME thing... there has been abuse of CNAMEs... fundamentally I get that user authentication is hard - and some people want to outsource that. fine with building a mechanism into the web platform to allow for that. Happy with a dedicated API to do user authentication.

Dan: yes - i agree if we

Lea: I agree it's a common flow - but fedcm us way down the line... Also wondering if the main advantage is the cookie partition thing is to do post message without JS then why not just do that... and the browser takes care of communicating it to those origins... Maybe instead of extending cookies or extending the security model of cookies...

Yves: what you described sounds like first party sets though... so might not be the perfect model... If you're defining what you want to export to another site... content of a header... Also re: fedcm not being implemented... therefore there should be a clear path to deprecating...

Jeffrey: another aspect - it's partitioned - it's not intened to share identities across the 2 sites - it's trying to be like an iframe... a general popup with post message would be too powerful.

Matthew: we discussed when we talked about document PiP that maybe there is a fundamental problem. I like the idea of decoupling UI but in this case since it's privacy maybe not... They compare themselves to fedcm - what about lightweight fedcm?

dan to draft a comment based on above