1556816 - Synchronous cross-frame DOM access (e.g. leaked through window.opener) breaks dynamic FPI

Status: RESOLVED DUPLICATE of bug 1657250

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[(no longer active)]

Here is the attack scenario.

• https://tracker.example/shady.js is a tracking script not on the Disconnect TP list which is widely deployed across the web.
• shady.js does something like below:

  let userId = localStorage['myUserId'];
  if (top.opener) {
    for (let win of top.opener.frames) {
      try {
        win.contentWindow.localStorage['otherUseId'] = userId;
      } catch (e) { continue; }
    }
  }

• This script is opportunistically snooping the opener's frame list, and if it finds a same-origin iframe, it'll leak the unique user ID from within the current frame into the iframe that was served from https://tracker.example, breaking the dynamic FPI partition boundary.

Comment 1

[Anne (:annevk)]

Why does only synchronous access break FPI? As long as opener is there they could also postMessage() everyone. This might lead to weirdness but they probably wouldn't care, right?

I think the fundamental problem is a browsing context group owning multiple top-level browsing contexts. noopener and COOP are effective opt-outs of that and at some point we should move endpoints to actively opt-in, I suppose (with COOP: unsafe-none).

Comment 2

[Tim Huang[:timhuang]]

We are in favor of fewer-openers to address this issue. Just like Anne said in comment 1, synchronous access is not the only issue, postMessage() poses the same issue here. And it could break websites if we block all sorts of channels which could lead to this issue. Reducing the opener relationship would be a better solution.

I am closing this bug, for now, that given that we want to go the direction of fewer-openers. Feel free to reopen it if you find out it is necessary.