Integrating libraries that require COOP/COEP into an existing application without a headache

[josephrocca]

Since libraries that require cross-origin isolation are becoming more common (as wasm threads browser support and compilation tooling get better), I'm wondering what the dev UX story is for integrating these libraries into existing applications. Ideally devs would be able to import a JS/wasm library without then having to think about the headers of all their resources (right down to their image/media CDNs, for example).

Would it be possible to create a special type of worker or something so that only the computations that require isolation are isolated? Or is there some other "neat" solution to this that doesn't require work on the part of the users of a library? I'm starting to see a pattern in READMEs saying something like "You need to have COOP/COEP headers to use this library" and although I love seeing more use of wasm, it doesn't seem like a good UX trend.

My initial thought on this was just that COOP/COEP headers will become "standard", so it'll end up not being an issue, but then I realised that some very normal/basic web functionality is disabled with those headers (e.g. forum users wouldn't be able to embed images from other domains unless the image host adds appropriate headers), so I'm less inclined to think that they'll end up being default headers in web servers at least for quite a while. I was recently building a static site and the simple task of embedding an external image (whose headers I cannot control) turned into a bit of a nightmare where I ended up having to add a link that the user clicks to open the image, rather than displaying the image within the page.

[annevk]

COEP's credentialless might be able to become a default at some point. We're also slowly working out a version of COOP that still allows for popups in #7713. For now though setting headers is the way to go.

[domenic]

Various people are indeed working on the sorts of things @annevk mentioned. I think https://arthursonzogni.github.io/anonymous-iframe/ is another, earlier-stage effort in this area. /cc @ArthurSonzogni @camillelamy

However, I did want to comment on this:

My initial thought on this was just that COOP/COEP headers will become "standard", so it'll end up not being an issue, but then I realised that some very normal/basic web functionality is disabled with those headers (e.g. forum users wouldn't be able to embed images from other domains unless the image host adds appropriate headers)

COOP/COEP headers becoming standard would be the "best" outcome for the web, and matches how the web would look if we had designed it with privacy and security in mind from the beginning. Forum users never should have been able to embed cross-origin images without the other origin's consent, for a variety of good reasons. (Security and privacy, but also things like: preventing bad future user experiences when the image is removed or changed on the remote server; preventing DDOSing of remote servers; etc.)

So if you want to be a really good web citizen, I do encourage you to use COOP/COEP, and conform to the web security model they imply. As you've noticed, this can require some extra work. And it can be extremely difficult for large existing sites with lots of dependencies. But especially when building a new greenfield project, it's The Right Thing To Do.

https://web.dev/why-coop-coep/ gives some more background on the history here.

[josephrocca]

@domenic Oh, anonymous iframes look like they will be very useful!

Correct me if I'm wrong here, but I think there are still some "green field" projects that can't really work without allowing cross-origin embedded content. For example, I run a site that's a bit like jsbin/codepen (though based on a custom DSL + HTML instead of JS + HTML), and users want full power to embed their own stuff (images, iframes, video, audio, etc.) and so COEP's credentialless + anonymous iframes seem like the way to go even if I were building it from scratch today?

I agree that this is not ideal in terms of content disappearing from remote servers (it's a problem with plain old hyperlinks too - hoping the web will be able to solve this with some form of content addressing one day), but I probably couldn't afford to allow them to host media on the platform even if I wanted to (it's a free service).

Definitely agree that the COOP/COEP headers are a better "default" for the vast majority of sites in the long term.

[domenic]

For example, I run a site that's a bit like jsbin/codepen (though based on a custom DSL + HTML instead of JS + HTML), and users want full power to embed their own stuff (images, iframes, video, audio, etc.) and so COEP's credentialless + anonymous iframes seem like the way to go even if I were building it from scratch today?

I would not allow users to DDOS non-consenting remote sites, if I were building a jsbin/codepen :)

[josephrocca]

@domenic Do you mean that there's some way to specifically mitigate DDOSing while allowing external content, or that you wouldn't allow use of any remote resources in a code sandbox type web app? If you mean the latter, then that would surprise me, because I think users would move to another web app that has that functionality.

Also, I'd have thought that there's really no way to prevent DDOS anyway due to the request still being made to the server (just not readable by the client-side code). And any server that doesn't have basic IP-based rate limiting set up is sitting open to DDOS regardless of whether there exists a sandbox type site where users can embed cross-origin content. I think I might be misunderstanding you here 😅

[domenic]

Do you mean that there's some way to specifically mitigate DDOSing while allowing external content, or that you wouldn't allow use of any remote resources in a code sandbox type web app? If you mean the latter, then that would surprise me, because I think users would move to another web app that has that functionality.

The latter, although more precisely, no use of remote resources that don't consent in a code sandbox type web app. And in my ideal world, no web apps would have that functionality. Thus, in an ideal world slightly closer to the real world, no new web apps should be adding it, and old ones should die out as users get sad about not getting access to various new powerful web APIs gated behind COEP/COOP.

I emphasize that this is idealistic, not realistic :). And it is a personal perspective, not speaking for any organization.

Also, I'd have thought that there's really no way to prevent DDOS anyway due to the request still being made to the server (just not readable by the client-side code).

You're right that the request is still made; however I think there's a win where it can be aborted quite quickly (e.g. at the CDN level), which is helpful in many cases. (I admit not having thought this through in full detail.)

Anyway, DDOS is just one of many concerns with allowing non-opted-in embedded content, and definitely not the most important.