[blink-dev] PSA: Opener Storage Partitioning Explainer

[Ari Chivukula]

Contact Emails

ari...@chromium.org, ahe...@chromium.org, tit...@chromium.org, mike...@chromium.org, cl...@chromium.org

Explainer

https://github.com/arichiv/opener-storage-partitioning/blob/main/README.md

Summary

This proposal seeks to prevent or limit same-origin cross-frame communication that can bypass storage partitioning, and to do so in alignment with existing work on the Cross-Origin-Opener-Policy.

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, 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.

Rough target for an origin trial severing window.opener on cross-site navigation is Q4 2023 while transient storage for frames with a window.opener likely needs to wait for storage partitioning to fully launch first.

[Charlie Reis]

Thanks for sharing.  I have a few questions and concerns about this approach, which might be worth discussing.

1) Giving transient storage to windows with openers (i.e., Proposal 2) seems like a reasonable way to prevent a subframe in one partition from leaking info to a same-origin popup in a primary partition.  It does seem like it would degrade single-sign-on quite a bit by making users sign into every new OAuth popup (per your User Friction note), correct?  That may be worth consideration by API owners.

2) I'm guessing that the "clearing the opener" behavior in Proposal 1 mostly exists so that the popup has the ability to leave the transient storage state?  It does seem safe, but I'm not sure I see a common scenario where that would happen in practice, without causing unexpected interactions between tabs.  If A opens B, it seems potentially surprising for A's window to control whether B's next navigation switches storage partitions or not.  Is there an example of a flow where this will be useful, or is Proposal 1 something that could be skipped to reduce the complexity?

3) I think there may be ways to bypass this approach, since window.opener is not the only way to get a reference to another window in the same Browsing Context Group.  For example, you can look up a named window, which might allow a subframe to find a same-origin document in a primary partition.  Example:

• On page A(B1), B1 runs window.open(B2, "foo").  B2 is now a named popup with an opener and thus transient storage.

• B1 navigates to C, causing B2's opener to be hidden (i.e., "pending").

• B2 navigates to B3, upgrading to primary storage for origin B since it has no opener.

• C navigates back to B1.  B3 does not have its opener restored, since B1 and B3 weren't sharing an opener in the past.  However, both windows are still in the same Browsing Context Group.

• B1 does window.open("", "foo"), giving B1 a reference to B3 and creating a new window.opener in B3.  This allows B1 (in A's storage partition) to synchronously script B3 (in B's primary storage partition).

Would you need to block named window lookup across storage partitions within a Browsing Context Group?  I'm not sure if that would be disruptive in practice (maybe not?), or if it would be sufficient to block all ways that B1 and B3 might find each other.

Charlie

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLTmXFYhFZScCSPcEsUrj9WiN-KAcosf_fOprQPcYy2og%40mail.gmail.com.

[Ari Chivukula]

(1) A agree that user friction is likely to be significant with proposal 2. I think it would be difficult to turn it on by default until something like FedCM is widely adopted.

(2) Your insight is correct, and some UI based communication would likely be needed. On Desktop, one could imagine the 'popup' tab ui being enough to indicate that storage was (and maybe would even always be) transient), but if a normal new tab is opened that happens to maintain an opener reference that would confuse users. This is even worse on mobile where the popup tab might appear identical in the UI to any other type of tab.

(3) That's a good point, we probably need to consider breaking out of the browsing context group when a navigation switches a tab from transient -> non-transient storage. I'll be taking some measurements soon to get an idea of the current use patterns and will add this to the list to track.

~ Ari Chivukula (Their/There/They're)

[Charlie Reis]

(2) Your insight is correct, and some UI based communication would likely be needed. On Desktop, one could imagine the 'popup' tab ui being enough to indicate that storage was (and maybe would even always be) transient), but if a normal new tab is opened that happens to maintain an opener reference that would confuse users. This is even worse on mobile where the popup tab might appear identical in the UI to any other type of tab.

Most window.open cases I'm aware of don't use the popup UI, and create a normal tab in the tab strip.

 

(3) That's a good point, we probably need to consider breaking out of the browsing context group when a navigation switches a tab from transient -> non-transient storage. I'll be taking some measurements soon to get an idea of the current use patterns and will add this to the list to track.

Interesting.  I agree that a new Browsing Context Group would probably be needed to support switching away from transient storage.  Specifically, my earlier suggestion to block named lookup wouldn't be sufficient, because there are additional repro steps that could bridge the partitions without requiring named lookup: 

• Open page A(B1, B2)
• B2 opens a popup to B3 (in transient storage).
• B2 gives its sibling B1 a window reference to the popup with B3.
• B2 navigates to C, so B3 loses its opener.
• B3 navigates to B4, upgrading to primary storage.
• B1 can now script B4, across storage partitions.

If B4 ended up in a new Browsing Context Group, that would help.  It might just be weird that a renderer-initiated navigation from B3 to B4 changes BCGs or not based on whether the opener exists.

Charlie