Early Design Review: Partitioned Popins

[arichiv]

こんにちは 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.

• Explainer: https://github.com/arichiv/partitioned-popins/blob/main/README.md
• Specification: TBD
• Security and Privacy self-review: https://github.com/arichiv/partitioned-popins/blob/main/security-privacy-questionnaire.md
• GitHub repo: https://github.com/arichiv/partitioned-popins/
• Primary contacts (and their relationship to the specification):
  • Ari Chivukula @arichiv, Google Chrome
  • Johann Hofmann @johannhof, Google Chrome
  • Kaustubha Govind @krgovind, Google Chrome
• Organization/project driving the design: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • WebKit Position: Partitioned Popins WebKit/standards-positions#349
  • Mozilla Position: Partitioned Popins mozilla/standards-positions#1023
• External status/issue trackers for this feature: https://issues.chromium.org/issues/340606651, https://chromestatus.com/feature/5949561398099968

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

[torgo]

The W3C TAG has discussed this proposal and I took an action last week to summarize some of the key points, which I am late on performing - apologies for that. Here are a couple of key points from our discussion:

• Regarding the potential for User Confusion: While UX solutions have been proposed, the effectiveness of these designs in clearly communicating the partitioned nature of identities and data access across origins remains uncertain. Do you have user testing studies that you can share with us which might show how this approach can safeguard against potential user confusion or use in deceptive patterns?

• Regarding Non-JS Communication Alternatives: We noted that the main advantage of Partitioned Popins seems to be allowing secure communication without JavaScript. It may be worth investigating if this benefit can be achieved without the complexities of this approach, such as through a dedicated API or secure post-message alternative that maintains privacy and security integrity.

• We'd like to suggest expanding & clarifying the description of the use case in the explainer.

[johannhof]

Thanks for the feedback @torgo.

• Regarding the potential for User Confusion: While UX solutions have been proposed, the effectiveness of these designs in clearly communicating the partitioned nature of identities and data access across origins remains uncertain. Do you have user testing studies that you can share with us which might show how this approach can safeguard against potential user confusion or use in deceptive patterns?

We are working on this with our UX team and I very much expect them to measure user understanding of the UI that we design for Popins in Chrome. It should be noted that a big motivator for this work comes from the potential user confusion from partitioning traditional popups, which is something we'd like to avoid. We believe that it can only be avoided by introducing a new UI paradigm, and this proposal builds the technical underpinnings for that. There is bound to be some level of uncertainty as we explore this space (it's a bit of a chicken and egg problem, we have to invent and prototype new designs to really measure their effect on users), but I want to make it clear that avoiding user confusion is a key goal for this effort.

• Regarding Non-JS Communication Alternatives: We noted that the main advantage of Partitioned Popins seems to be allowing secure communication without JavaScript. It may be worth investigating if this benefit can be achieved without the complexities of this approach, such as through a dedicated API or secure post-message alternative that maintains privacy and security integrity.

Can you elaborate on "the complexities of this approach", i.e. what is the complexity? I'm not sure how leveraging access to partitioned cookies, which are a simple and secure mechanism (which "maintains privacy and security integrity") and already widely adopted by the ecosystem would be inferior to the development of a new dedicated API.

[plinss]

Hi @johannhof - We're more concerned with the UI complexity. Specifically, how can we communicate to the end user the nuance of the partitioned identity? Feels like the spec should give an example of good UI - or indicative UI - especially since this informs the user's decision-making process, for example regarding what permissions to agree to, and this will be a new situation that they may not have encountered before?

It seems like some of these use cases could be solved by a narrow, focused API that is built to solve the specific use case (login flow), rather than by introducing a new technology that also introduces a new kind of partitioned identity, which introduces the potential for user confusion (and abuse).

[johannhof]

Hi @johannhof - We're more concerned with the UI complexity. Specifically, how can we communicate to the end user the nuance of the partitioned identity? Feels like the spec should give an example of good UI - or indicative UI - especially since this informs the user's decision-making process, for example regarding what permissions to agree to, and this will be a new situation that they may not have encountered before?

Thanks for the clarification. We're also concerned with UI complexity, which is why we're trying out the "popin" variant. We should follow up on some of this based on the initial UX prototype. Again, it's hard to develop that without the platform primitives in place. :)

It seems like some of these use cases could be solved by a narrow, focused API that is built to solve the specific use case (login flow), rather than by introducing a new technology that also introduces a new kind of partitioned identity, which introduces the potential for user confusion (and abuse).

I disagree, for two reasons:

1. This is not a new partitioned identity, it's a continuation of your partitioned identity on the site in a presentation that's more suitable and more secure for some use cases. If this technology helps keep user identity partitioned between sites vs. exposing additional prompts for cross-site identity joining to users, I think it's a win for everyone.

2. A long term goal of this effort is to help pry the ecosystem away from the usage of unpartitioned popups in combination with opener access. FedCM or other APIs may be able to capture some of these use cases, but I don't believe we can entirely replace popups that way. Popups allow for infinite customization of their content and that is arguably a good thing. Additionally, the integration with cookies is valuable to many developers for both security and performance reasons. IMO we should err on the side of building flexible platform primitives that open the door to niche or future use cases when our goals for privacy and security can be achieved to the same degree (and, as mentioned above, even surpassed vs. cross-site identity sharing).

[matatk]

We've been discussing two broad design approaches in this thread: low-level primitives, on top of which a variety of things can be built; and more focused, high-level APIs (ref Design Principle 2.2: Consider tradeoffs between high level and low level APIs). We understand that your team feels that the proposed low-level approach provides improved privacy versus the status quo. TAG feels that a higher-level API is more appropriate in this case, as it would avoid the potential for user confusion and abuse.

However, we haven't talked much about the use case(s). Does your team foresee any additional use cases for short-lived, partitioned, pop-up-like UI—other than login—that aren't met by existing APIs? If there are several use cases beyond login, that would make a better argument that the platform needs a low-level primitive for this.

[arichiv]

The other main use case we've been considering is web applications that (for one reason or another) are embedded in cross-origin iframes. If, at some point, there is a need to create a temporary pop-up on that same origin this provides a way for it to have the same cookie/storage context as the iframe.

[jyasskin]

We looked at this in a breakout today, with the following conclusion:

This looks like a good problem space to investigate. We'd like to see more use cases fleshed out, especially cross-site iframes opening popups on their own origin. We think the UI question is critical to a full analysis of this proposal: please let us know when you have a proposed design for that. We're also hoping to see a full description of what parts of that UI users are expected to learn to trust, and how various combinations of malicious top-level, embedded, and popup sites could take advantage of that user trust (that is, explain the "abuse cases" and how they're mitigated).

Please reopen this issue when we can look at that analysis.