Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose COOP and COEP state to JavaScript #4872

Closed
annevk opened this issue Aug 30, 2019 · 10 comments
Closed

Expose COOP and COEP state to JavaScript #4872

annevk opened this issue Aug 30, 2019 · 10 comments
Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header.

Comments

@annevk
Copy link
Member

annevk commented Aug 30, 2019

As @kripken points out in https://twitter.com/kripken/status/1167225879488954369 using postMessage() for feature detection (see also #4732) is less than ideal as in the success case it'll generate a message event.

(You could create an <iframe>, but that seems ungainly. You could also create a MessageChannel, except that doesn't work well across browsers and is not likely to be solved soon.)

Idea:

  • window.crossOriginOpener, returns the empty string, "same-origin", "same-site", "same-origin unsafe-allow-outgoing", or "same-site unsafe-allow-outgoing".
  • self.crossOriginEmbedder, returns the empty string or "require-corp".
  • self.isolatedAgentCluster, returns true if the first returns "same-origin" and the second "require-corp"; otherwise false.

(window. only exposed on Window, self. on WindowOrWorkerGlobalScope or potentially something that includes worklets as audio worklets will need this too.)

cc @mikewest @arturjanc @rniwa @othermaciej @domenic

@annevk annevk added topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header. topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. labels Aug 30, 2019
@rniwa
Copy link

rniwa commented Aug 30, 2019

@cdumez

@domenic
Copy link
Member

domenic commented Aug 30, 2019

My only comment is we should be careful about adding user-facing APIs using new terms that don't appear elsewhere for web developers.

I think "embedder" is probably already in some public APIs, but "agent cluster" is definitely not.

@annevk
Copy link
Member Author

annevk commented Aug 30, 2019

That's fair, I'd also be fine with crossOriginIsolated and that has the benefit of matching the other names.

annevk added a commit that referenced this issue Oct 28, 2019
Closes #4872. (I'm not convinced we need to add crossOriginOpener and crossOriginEmbedder for now.)
@annevk
Copy link
Member Author

annevk commented Oct 28, 2019

I've added self.crossOriginIsolated to #4734. I think that's good enough for the initial launch of this feature and the others can be added if there's demand.

@annevk
Copy link
Member Author

annevk commented Oct 28, 2019

@mikewest
Copy link
Member

crossOriginIsolated sounds fine as a first pass to me. Thanks!

@domenic
Copy link
Member

domenic commented Nov 18, 2019

I've learned a bit more about this problem space and I think it might be worth some last-minute bikeshedding on the name. To be clear, I am OK with crossOriginIsolated as the plan of record, but while we still have some time, let's dig in a bit more.

In particular we have two types of isolation coming down the pipe:

  • COEP + COOP, which ensure that everything in your agent cluster has explicitly allowed itself to be put there. Part of the mechanism for doing so is by moving popup agents into separate browsing context groups, which have their own agent cluster maps.

  • Origin isolation, which prevents you from sharing memory or synchronously scripting same-site-cross-origin pages. The mechanism for doing so is to change a given browsing context's group's agent cluster map to be origin-keyed.

These are both valuable and complementary. I want to check though that the names are good. In particular, we appear to be headed toward a world where we bill these to developers as "cross-origin isolation" and "origin isolation". E.g. one could imagine self.crossOriginIsolated as well as self.originIsolated. Is that too confusing?

I'm definitely open to renaming the origin isolation proposal if that would be helpful. Perhaps it could be something more like "memory sharing isolation" or "same origin-only memory sharing"? (Those kind of assume that "non-shared memory" implies "cannot synchronously script each other", which may not be obvious...)

@annevk
Copy link
Member Author

annevk commented Nov 19, 2019

I realized that origin isolation is only relevant for window agents (see WICG/origin-agent-cluster#4), perhaps that can lead to a clearer name? It's also not immediately clear we'd need to expose the API in shared/service workers as they are scoped by origin (well, they're really scoped by identity, which is arguably even better) by definition. COEP on the other hand does apply everywhere, and requires COOP in addition for window agents. (Aside: in Firefox we'll likely roll out COOP+COEP support before COEP in shared/service workers.)

@annevk
Copy link
Member Author

annevk commented Dec 4, 2019

See #5122 for a new idea around COOP+COEP and origin isolation.

I think keeping crossOriginIsolated as the name here is still good though given the names of the headers involved.

@annevk
Copy link
Member Author

annevk commented Jan 2, 2020

Folding this into #4732.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: cross-origin-embedder-policy Issues and ideas around the new "require CORP for subresource requests and frames and etc" proposal. topic: cross-origin-opener-policy Issues and ideas around the new "inverse of rel=noopener" header.
Development

No branches or pull requests

4 participants