>>981
I have never used Wasm myself, but I understand that it must follow the same rules as XHR, which means, you can allow or deny remote content on your site with Content-Security-Policy, but in order for the browser to allow your site to actually read content from a remote server, that remote server must send Access-Control-Allow-Origin headers, and most sites don't do it.
Just a simple example so you know what I mean. Let's say you wanted to download image #113888452 from Pixiv, the first image from your post. The javascript to access that api would be something like
const url = "https://www.pixiv.net/touch/ajax/illust/details?illust_id=113888452";
console.log(await (await fetch(url)).text());
If you open the debug console and run that code while you're on this tab, you'll get a Content-Security-Policy error, as expected. You might think that just changing your CSP might be enough, but it's not. Open, for example, example.com, which doesn't have CSP restrictions, and run the code again. This time you'll get a different CORS error because the remote server (ie, Pixiv) didn't send an Access-Control-Allow-Origin header.
Now, still on example.com, run the following
const url2 = "https://api.allorigins.win/get?url=https://www.pixiv.net/touch/ajax/illust/details?illust_id=113888452";
console.log(await (await fetch(url2)).text());
This time, if everything worked correctly, you should see the response on the console. allOrigins.win is a CORS proxy that adds that header to all requests, so you can request stuff from any server. Except that, it's a proxy, it wouldn't actually be the user doing the request to Pixiv, it would be the proxy server, and proxies aren't too reliable. In fact, the first proxy I tried, corsproxy.io, couldn't open Pixiv because Pixiv had its IP blacklisted.
As I said, this example is specifically about XHR, but I think Wasm works exactly the same. For example, https://libcurl.js.org/ is a Wasm implementation of libcurl, it looks great, except that when you read how it works, all the traffic must still go through a proxy. This library uses a WebSocket proxy instead of a web proxy like in my example, but the idea is basically the same. The browser won't allow you to read directly stuff from a domain unless the domain explicitly allows it, whether it's because it allows it by default (I think Baraag does it, for example), or because you use a proxy that adds the header.
I'm not too familiar with web development, so my apologies if I'm missing something super obvious, but from what I know this is the kind of bullshit you'll find if you manage to make the code work, you'll still have to fight with CORS to convince the browser to let you parse the api requests you make. Don't get me wrong, it's a commendable idea, but I think you really underestimated how hard it would be.