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.