#916: Early Design Review: Opener Protections
Discussions
Discussed
Nov 1, 2023 (See Github)
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>
Discussed
Nov 1, 2023 (See Github)
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> Comment by @hadleybeeman Nov 16, 2023 (See Github)
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..."
Comment by @arichiv Nov 16, 2023 (See Github)
A user is visiting a shopping site and trying to check-out. Before cookie/storage partitioning, trackers could detect a conversion in an iframe but now that's not possible. Now, they have an incentive to open a pop-up (with access to unpartitioned storage and cookies) and have the shopping site pass that pop-up (loading some tracking website) information about the conversion without needing user permission. @johannhof if I missed something
Comment by @hadleybeeman Nov 20, 2023 (See Github)
Thanks, @arichiv. That's helpful indeed — we'd be grateful if you would add that to the explainer.
Comment by @torgo Nov 20, 2023 (See Github)
@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?
Comment by @arichiv Nov 20, 2023 (See Github)
Can do! I'll try to have these edits in next week.
Discussed
Dec 1, 2023 (See Github)
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
Discussed
Jan 1, 2024 (See Github)
Matthew: they have updated their explainer as asked
Amy: update milestone and read the updates?
Matthew: this is a substantial update
Discussed
Feb 1, 2024 (See Github)
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?
Discussed
Feb 1, 2024 (See Github)
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
Comment by @torgo Feb 21, 2024 (See Github)
Hi @arichiv thanks for updating those examples - that's much appreciated. You noted in your explainer that there are 2 proposals. Do you have any further info at this point about which proposal will work better? Have you done any testing or do you have any data you can share?
Comment by @arichiv Feb 21, 2024 (See Github)
Unfortunately not yet, I hope to have that in Q2 this year.
Comment by @torgo Feb 28, 2024 (See Github)
Hi @arichiv thanks for the response. We're trying to figure out how we can best be helpful here. Would it make sense to put this review on hold until you have further information about which approach you're planning to take? Is there further guidance that you'd like from the TAG at this point?
Comment by @arichiv Feb 28, 2024 (See Github)
Putting it on hold for now is reasonable, I think a revised approach might be forthcoming soon.
Discussed
Mar 1, 2024 (See Github)
Max: they agreed to put this on hold...
Dan: Sets to "stalled"
Discussed
May 1, 2024 (See Github)
Dan leaves a note on the issue asking if we should close
Comment by @torgo May 20, 2024 (See Github)
Hi @arichiv just pinging this. Should we keep this issue open or are you likely to file a new review request for whatever the revised approach is? Thanks!
Comment by @arichiv May 20, 2024 (See Github)
This can be closed out, a somewhat related initial step is at: https://github.com/w3ctag/design-reviews/issues/956
OpenedNov 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:
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