A team wants to enable cross-origin isolation (COOP and COEP) across your product so a WebAssembly feature can use SharedArrayBuffer, but the product embeds several third-party widgets and uses a popup-based OAuth flow. How would you decide whether to do it, and how would you roll it out?

## Reframe the unit of decision The request as stated — isolate the product — bundles a capability need with a scope assumption. Cross-origin isolation is a property of a document, established by the headers on that document's response and inherited downward into its frames. Nothing requires it to be product-wide. So the first question is not "can we afford it" but "what is the smallest document tree that needs it". Usually the WebAssembly workload is one screen, one editor, one viewer. Moving it to a dedicated route — or, more cleanly, to a dedicated origin embedding nothing third-party — turns an organisation-wide negotiation with every vendor into a build-and-deploy task. That reframing is the actual senior contribution here; everything below is what you do if the answer really is no. ## Cost the change with data, not inspection If the feature must live on a page that carries the product's normal third-party surface, measure before deciding: ``` Cross-Origin-Embedder-Policy-Report-Only: require-corp Cross-Origin-Opener-Policy-Report-Only: same-origin ``` with a Reporting API endpoint collecting both. Run it against real traffic long enough to catch weekly jobs, campaign tags and region-specific vendors. Source inspection will not find these: tag managers, consent platforms and marketing pixels inject resources at runtime, and several only fire for particular segments. The COOP report-only header matters as much as COEP's, because opener breakage is invisible to a subresource inventory and shows up as a broken login rather than a missing image. ## Classify the inventory Sort each blocked dependency into one of four buckets, because the remediation and the *owner* differ: - **Fixable by us.** Assets on our own CDN: add `Cross-Origin-Resource-Policy: cross-origin` at the edge. Hours of work. - **Fixable by CORS mode.** Third-party assets already sending `Access-Control-Allow-Origin`: add the `crossorigin` attribute, accepting a one-off cache re-fetch since CORS and no-cors responses occupy different cache entries. - **Requires a vendor.** Ask for CORP. Treat the answer as a procurement question with a timeline, not an engineering task — a large vendor may take quarters, a small one may never. - **Unmovable.** Credentialled third-party frames are the usual residents. `COEP: credentialless` avoids the CORP requirement by stripping credentials, but that is exactly what a credentialled widget needs, so it does not rescue this bucket. If the unmovable bucket is non-empty, the shared-page plan is dead and you are back to a dedicated origin. ## The OAuth popup is a hard constraint, not a cost `Cross-Origin-Opener-Policy: same-origin` puts the document in its own browsing context group; a popup it opens is disconnected and cannot message back through `window.opener`. The value that preserves that relationship, `same-origin-allow-popups`, deliberately does **not** qualify a page for cross-origin isolation. So this is not a tradeoff to be balanced — the two requirements are mutually exclusive on one document. Either the login flow moves to a full-page redirect, or the isolated feature moves off the page that hosts the login. Discovering this after committing to the work is a common and expensive failure; establish it in week one. ## Question the requirement itself Before paying any of this, ask what the WebAssembly feature needs shared memory *for*. If the design is many workers mutating one large buffer with fine-grained coordination, isolation is the price. If it is really "send a big buffer to a worker, get a result back", a message-passing design carries no header requirement at all and no third-party negotiation. The cheapest isolation rollout is the one you establish you do not need — and it is worth an afternoon of prototyping to find out. ## Decide and sequence A defensible plan looks like: prove the capability is required; scope it to a dedicated origin unless a concrete reason forbids that; if it must be in-page, run report-only for a full traffic cycle; classify and remediate; confirm the auth flow constraint before any vendor conversation starts; enforce behind a staged rollout with the report-only endpoint still collecting; and keep a documented rule afterwards that any new third-party resource on that route must ship CORP. That last item is the durable cost, and the one usually omitted from the pitch. Isolation is not a migration that finishes — it is a standing constraint on every future integration on that surface. Whoever owns the route owns that constraint, and if the marketing team can add a tag to it without review, the isolation will silently break the next time they do.