Add a noopener-allow-popups value to COOP

[yoavweiss]

Fixes #10373

Some origins can contain different applications with different levels of security requirements. In those cases, it can be beneficial to prevent scripts running in one application from being able to open and script pages of another same-origin application.

In such cases, it can be beneficial for a document to ensure its opener cannot script it, even if the opener document is a same-origin one.

This PR adds a noopener-allow-popups Cross-Origin-Opener-Policy value that severs the opener relationship between the document loaded with this policy and its opener. At the same time, this document can open further documents (as the "allow-popups" in the name suggests) and maintain its opener relationship with them, assuming that their COOP policy allows it.

Explainer

• At least two implementers are interested (and none opposed):
  • Chromium - I'm implementing
  • WebKit - positive + I'm implementing
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/5640893/13/third_party/blink/web_tests/external/wpt/html/cross-origin-opener-policy/tentative/noopener/coop-noopener-allow-popups.https.html
  • https://chromium-review.googlesource.com/c/chromium/src/+/5640893/13/third_party/blink/web_tests/external/wpt/html/cross-origin-opener-policy/reporting/tentative/access-to-noopener-page-from-no-coop-ro.https.html
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/344963946
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1918971
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=275147
• MDN issue is filed: Cover noopener-allow-popups COOP value mdn/mdn#579
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsers.html ( diff )

[annevk]

Would like to hear what @camillelamy thinks as well, but I think one change I'd like to see is that we drop "cross-origin" from the internal naming scheme now that we make it apply to same-origin scenarios.

(We probably don't want to change any of the IDs though.)

It also seems to me some other algorithms need updating here:

• obtain a cross-origin opener policy
• check if COOP values require a browsing context group switch

[yoavweiss]

I think one change I'd like to see is that we drop "cross-origin" from the internal naming scheme now that we make it apply to same-origin scenarios

Would it make sense to spin off this editorial only change to a separate PR? (happy to work on it, just wondering RE editorial vs. functional split)

• obtain a cross-origin opener policy

Oops, added!

• check if COOP values require a browsing context group switch

I think this is covered by the change to matching COOP, but I could be I'm missing something..

[annevk]

@yoavweiss I think once we have agreement for this PR, that could be a separate PR as well (to be landed first). It would be a bit of extra work, but I agree that it would be nicer.

[yoavweiss]

I added @ddworken's commented risks as a note.
I thought that a "browser context group switch" also implied a potentially separate process. @arturjanc - should I understand from your comment that you'd like to see something more explicit here?

[arturjanc]

@arturjanc - should I understand from your comment that you'd like to see something more explicit here?

Yes, I think it could be helpful to at least add a note somewhere saying that browser should aim to put documents with this COOP value in a separate renderer process (or something along these lines) -- otherwise, same-origin documents would still be able to read arbitrary from memory even if they can't directly access it using web-level APIs.

[annevk]

@yoavweiss did you open a PR already to drop "cross origin" from the internal concepts?

[yoavweiss]

@yoavweiss did you open a PR already to drop "cross origin" from the internal concepts?

Was out, will do that now..

[domfarolino]

This is looking good, I have nothing but nits.

[yoavweiss]

Thanks for reviewing!

[shhnjk]

It'd be nice to also document the vector in this comment.

[yoavweiss]

It'd be nice to also document the vector in this comment.

I believe it's covered in the note under https://whatpr.org/html/10394/browsers.html#coop-noopener-allow-popups

[yoavweiss]

It'd be nice to also document the vector in this comment.

I believe it's covered in the note under https://whatpr.org/html/10394/browsers.html#coop-noopener-allow-popups

@shhnjk - or did you mean that the note should cover Cache API usage as well?

[shhnjk]

It'd be nice to also document the vector in this comment.

I believe it's covered in the note under https://whatpr.org/html/10394/browsers.html#coop-noopener-allow-popups

The note talks about Service worker installation as a risk from same-origin application, but I think if the sensitive application uses a service worker, those SW caches can be manipulated without Service worker installation from the same-origin application.

i.e.:

// A script running on /chat.
// Assuming the sensitive application has a service worker which returns cached contents.
caches.open("v1").then(cache => {
  const init = {
    headers: {
      'Content-Type': 'text/html'
    }
  };
  cache.put('/password', new Response('<img src=x onerror=alert(origin)>', init));
})

[yoavweiss]

Added a separate line for "Cache API manipulation or access to sensitive data". Thanks!!