Intent to Prototype: Opener Protections
Ari Chivukula
Contact emails
ari...@chromium.org, joha...@chromium.org, cl...@chromium.org
Specification
https://arichiv.github.io/opener-storage-partitioning/
Summary
This proposal seeks to prevent or limit cross-storage-partition cross-frame communication that can bypass storage partitioning, and to do so in alignment with existing work on the Cross-Origin-Opener-Policy.
This is the start of a long road and it will be some time before anything proposed here reaches the origin trial or shipping phase. This is being sent out so early in the hope of gathering feedback and starting a conversation.
We want to limit disruption of key use cases that benefit user experiences on the web and typically have a user interaction (login, payments, authentication) of window.opener. We are concerned more with same-origin cross-storage-partition communication that lacks this direct user involvement, and thus can be abused.
Limiting cross-storage-partition cross-frame communication 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 or messages to it will simply be dropped. 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.
Blink component
Internals>Sandbox>SiteIsolation
Motivation
Storage partitioning separates the first and third party storage buckets (and some communication APIs like BroadcastChannel, SharedWorker, and WebLocks) for a given origin. Storage partitioning seeks to prevent “certain types of side-channel cross-site tracking.”
The Cross-Origin-Opener-Policy provides a way for a window to sever communication with cross-origin windows it opens or was opened by. A proposed extension (restrict-properties) of this proposal allows for a mode with limited communication (asynchronous messages and detecting if the window was closed) between a popup and its opener.
The former proposal is primarily concerned with user privacy (e.g., preventing the average user from having their browsing unknowingly tracked in order to serve ads) whereas the latter proposal is primarily concerned with user security (e.g., ensuring even a targeted user cannot have information leaked cross-site). A way to bridge the gap between these needs should be considered to ensure both constraints can be met without disrupting user experience.
TAG review
https://github.com/w3ctag/design-reviews/issues/916
Compatibility
This has the potential to break or add friction to existing multi-window flows (including payments and login). Significant evidence (via metrics and feedback) will need to be gathered in the prototyping phase before moving forward.
Interoperability
Gecko: https://github.com/mozilla/standards-positions/issues/926
WebKit: https://github.com/WebKit/standards-positions/issues/277
Web developers: Need to gather; anticipating a need to focus on potential breakage and mitigation
Debuggability
Availability of the opener and any partitioned storage will be visible via DevTools.
Is this feature fully tested by web-platform-tests?
Tests will be added.
Tracking bug
Link to entry on the Chrome Platform Status