-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opener Protections #43
Comments
@arichiv we can put you on the agenda this week, How much time do you expect to need? |
@martinthomson same as for heuristics, Ari presented on this 2 weeks ago. I think we're interested in what next steps for adoption by the group are. Given that this is a very exploratory proposal (like the nav tracking mitigations originally), what level of support do we need from other implementers? |
We can ask people to indicate here whether their implementation is interested in the work. |
I don't think we need to take this to the group again since it was two weeks ago, this is blocked on me posting to request positions. I hope to get to it in early November. |
https://groups.google.com/a/chromium.org/g/blink-dev/c/RiNkhQGvmkc I2P sent out and WebKit/Mozilla/TAG issues opened. |
I'd like to propose the adoption of Opener Storage Partitioning by the Privacy Community Group.
This work is being investigated by Chrome and was discussed at TPAC 2023.
Summary of Proposal:
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.
The text was updated successfully, but these errors were encountered: