Sprints: Clarify the behavior of the `Cross-Origin-Opener-Policy` header

[arturjanc]

URL(s)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy

Request type

• [ ] New documentation
• [x] Correction or update

Details

I'd like to recommend a couple of updates to the recent COOP article to better explain its behavior.

/cc @annevk @Elchi3

Introduction

COOP will process-isolate your document and potential attackers can't access to your global object if they were to open it in a popup, preventing a set of cache attacks dubbed XS-Leaks.

Replace "cache attacks" with "cross-origin attacks" or "information disclosure attacks". XS-Leaks aren't only cache-based, and the ones that COOP prevents are based on direct DOM access to other documents.

If a document with COOP opens a pop-up, its window.opener property will be null. This header allows you to have more control over references to a window than rel=noopener, which only affects outgoing navigations.

This isn't accurate because same-origin pop-up with same COOP will still retain the window.opener. I'd rephrase this to something like:

"If a cross-origin document with COOP is opened in a new window, the opening document will lost a reference to it, and the window.opener property of the new window will be null. This allows you to have more control over references to a window than rel=noopener, which only affects outgoing navigations."

Syntax | Directives | same-origin

Shares the same browsing context group with same-origin documents that are also explicitly marked same-origin.

"Shares the same browsing context group with same-origin documents whose COOP is also explicitly set to same-origin."

Examples

You can only access powerful features like SharedArrayBuffer objects or Performance.now()

@annevk Is Performance.now() restricted by COOP+COEP? I thought it's just SAB and the two other APIs listed in https://web.dev/coop-coep/

Browser compatibility

COOP also shipped in Chrome 83.

[Elchi3]

Thanks for your detailed feedback, @arturjanc! Very much appreciate it :+1:
I've made the updates you suggested and also fixed the compat data for Chrome.

You can only access powerful features like SharedArrayBuffer objects or Performance.now()

@annevk Is Performance.now() restricted by COOP+COEP? I thought it's just SAB and the two other APIs listed in https://web.dev/coop-coep/

Maybe it would be more correct to say:

"You can only access powerful features like SharedArrayBuffer objects or unthrottled timers in Performance.now()"

(I think I got this from https://groups.google.com/g/mozilla.dev.platform/c/-hYWoob95LI)

@annevk can probably comment on this a lot better than I :)

[annevk]

The resolution of performance.now() is gated on cross-origin isolated. This is not yet fully standardized, but implemented in Firefox: https://github.com/w3c/hr-time/issues/89.

[Elchi3]

Thanks Anne. Added info to https://wiki.developer.mozilla.org/en-US/docs/Web/API/Performance/now#Reduced_time_precision

[annevk]

@Elchi3 I recommend calling it "cross-origin isolated" everywhere as it's the name of the primitive, it matches self.crossOriginIsolated, and we might want to eventually create a page for that. I think we reached the point where being specific about "origin" and "site" and communicating the difference to developers is relevant.

[Elchi3]

Thanks for catching that, Anne. Updated!
I'm closing this here, but I think the remaining task for closing https://github.com/mdn/sprints/issues/2219 is to actually create a page that defines cross-origin isolation and make sure we link it out from the various places where we've introduced this now.