STR: Set "privacy.firstparty.isolate" to true. Set "privacy.firstparty.isolate.restrict_opener_access" to true. Open https://torpat.ch in a new tab. In the web console, enter let myWindow; document.addEventListener("click", () => myWindow = window.open("https://arthuredelstein.net")); Now click on the torpat.ch document and a new tab opens. In the web console for each tab, write: window.onmessage = e => console.log(e); Now in the torpat.ch console, enter: myWindow.postMessage("hello from torpat.ch", "*"); In the arthuredelstein.net console, enter: window.opener.postMessage("hello from arthuredelstein.net", "*"); Expected results: Communication should not happen between documents with a different first-party. Actual result: Messages can be passed in both directions. Note: We should check the case where iframes open a new tab as well.

This seems like it has a very good chance of breaking FPI login flows. (ni-ing Steve just in case he happens to know off the top of his head based on his prior investigation.) For the benefit of our users who have FPI turned on, I think we should be conservative with this change and make it preffed off by default. Granted, FPI is not a supported feature, but we appreciate the bug reports people provide about it, and annoying them all seems detrimental if it's easily avoidable. Also, it will give us an opportunity to slowly roll it out to ourselves and early testers and collect bug reports while not being deluged.

One idea we discussed, to mitigate the breaking of login flows, is to pop up a permissions doorhanger whenever either tab attempts a postMessage. The doorhanger can ask the user: "Would you like A.com to share information about you with B.com?" Then, depending on the user's answer, the message is either allowed to proceed or canceled. This idea takes advantage of the asynchronous behavior of postMessage. I don't see any easy solution for synchronous access via window.opener.document.

Depends on D8521

Per discussion with Baku, we are not 100% sure about entirely blocking the postMessage across for FPI in our side since it may break websites, like SSO. But we pretty sure that Tor wants this, so I will add a pref for controlling the blocking behavior here.

It turns out this patch breaks a bunch of tests. Most of the cases are the chrome wants to post messages to content to do some test. For example, a browser chrome test uses ContentTask.spawn() to inject code to post a message to a private browsing window. Because of the injected code will be executed under the system principal and its OA mismatches with the OA of the private browsing window. So, it will hit the assertion. I would suggest that we skip the check if the subject principal is the system principal.

It turns out that many tests are going to post Messages to content from chrome with a mismatched OA. This patch exempt the check in that case. Depends on D8522

Try looks good. https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2053137e776fa5063cceac91675f7b7f1366326

Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dfc3795ef568 Part 1: Making postMessage to be aware of OAs when the targetOrigin is "*." r=arthuredelstein,baku https://hg.mozilla.org/integration/autoland/rev/0b4b3d826b3f Part 2: Add a test case for assuring postMessage cannot post across OAs r=arthuredelstein,baku https://hg.mozilla.org/integration/autoland/rev/44cd913c18f8 Part 3: Exempting the check of OAs for postMessage with the target origin is '*' if it is coming from the system principal r=baku

https://hg.mozilla.org/mozilla-central/rev/dfc3795ef568 https://hg.mozilla.org/mozilla-central/rev/0b4b3d826b3f https://hg.mozilla.org/mozilla-central/rev/44cd913c18f8