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.
Title of the spec
Opener Storage Partitioning
URL to the spec
https://arichiv.github.io/opener-storage-partitioning/
URL to the spec's repository
https://github.com/arichiv/opener-storage-partitioning/
Issue Tracker URL
https://crbug.com/1159586
TAG Design Review URL
https://github.com/w3ctag/design-reviews/issues/916
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/926
Description
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.