#916: Early Design Review: Opener Protections

Visit on Github.

Opened Nov 13, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Opener Protections.

Our goal is to maintain cross-page communication where important to web function while striking a better balance with user-privacy.

This will be done in two steps. First, whenever a frame navigates cross-origin any other windows with a window.opener handle pointing to the navigating frame will have that handle cleared. Second, either (a) any frames with a valid window.opener (or window.top.opener) handle at the time of navigation will have transient storage via a StorageKey nonce instead of access to standard first- and third-party StorageKeys or (b) the opener will be severed by default until user interaction or an API call restores it.

The first proposal should be less disruptive than either of the second, but metrics will need to be gathered on both. Once implemented, these proposals together prevent any synchronous or asynchronous communication between a first- and third-party storage bucket for the same origin. Instead, communication between two buckets for the same origin will only be possible if one of the buckets is transient. This mitigates the threats we are concerned with.

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): Privacy CG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Privacy CG
  • This work is being funded by: Google Chrome

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @arichiv, @johannhof


  1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
    • This feature might expose whether or not user interaction has occurred to enable opener access between windows.
  2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
    • Yes, we should be reducing the amount of communication between windows possible overall.
  3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
    • This feature does not differentiate between the type of information communicated.
  4. How do the features in your specification deal with sensitive information?
    • This feature does not differentiate between the type of information communicated.
  5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    • No.
  6. Do the features in your specification expose information about the underlying platform to origins?
    • No.
  7. Does this specification allow an origin to send data to the underlying platform?
    • No.
  8. Do features in this specification enable access to device sensors?
    • No.
  9. Do features in this specification enable new script execution/loading mechanisms?
    • No.
  10. Do features in this specification allow an origin to access other devices?
    • No.
  11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
    • No.
  12. What temporary identifiers do the features in this specification create or expose to the web?
    • It would be possible to detect if permission to communicate cross-origin to another window had been granted.
  13. How does this specification distinguish between behavior in first-party and third-party contexts?
    • The heuristic for communication may differ in first and third party contexts.
  14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    • This feature does not work differently in such contexts.
  15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
    • Yes
  16. Do features in your specification enable origins to downgrade default security protections?
    • This feature does not downgrade default protections.
  17. How does your feature handle non-"fully active" documents?
    • This feature cannot be used until the document is active.
  18. What should this questionnaire have asked?
    • N/A

Discussions

2023-11-13

Minutes

<blockquote>

Hi @arichiv @johannhof. We are looking at this to triage it in today's W3C TAG meeting.

We appreciate the careful diagrams in the explainer, since they help us understand WHAT you're focusing on, but can you help us with the WHY? Specifically, when would a user encounter this, and how would it change their experience on the web? Something that starts like "a user is visiting xyz type of site and trying to do abc type of action and this can put them at risk to pdq type of attack..."

</blockquote>
2023-11-20

Minutes

Hadley and Dan try to unwind what exactly is being proposed in https://arichiv.github.io/opener-storage-partitioning/

Hadley: the risk is that they can share unpartitioned storage? The goal is to maintain cross-page communication... How often do we really want cross page communication?

Rossen: payment... auth... there are a bunch...

<blockquote> @arichiv It would be really helpful to have a bit more information in the examples - that you've laid out - so we can understand what risk is being introduced / mitigated against at each step? I think this info is evident to you, but not evident to the reader. Could you build on the example that you provided in the comment above and extend that a bit? </blockquote>
2023-12-18

Minutes

Dan: we asked some questions in November.. looks like they've added more information to their explainer

Amy:

Matthew: the payment thing may be a genuine issue

Amy: 3 different but complementary proposals...

Dan to re-read explainer and come back with proposal at plenary

2024-01-london

Minutes

Matthew: they have updated their explainer as asked

Amy: update milestone and read the updates?

Matthew: this is a substantial update

2024-02-19

Minutes

Dan: they've updated their explainer with some additional examples... https://github.com/arichiv/opener-storage-partitioning/pull/3

Max: they have 2 proposals in their explainer... do they want both proposals reviewed?

2024-02-26

Minutes

Max: they responded - they have said they don't have feedback but hope to have "in Q2" but that doesn't answer the question... do they want us to choose which proposal is better?

Dan: leaves request for further info as a comment

2024-03-25

Minutes

Max: they agreed to put this on hold...

Dan: Sets to "stalled"

2024-05-20

Minutes

Dan leaves a note on the issue asking if we should close