I think this evokes the static vs dynamic linking argument again though. If you consider your browser client code as your "source code" and the browser as a "dy

I think this evokes the static vs dynamic linking argument again though. If you consider your browser client code as your "source code" and the browser as a "dynamically linked library", then there are substantial pros and cons. Your proposal, while feasible, turns this into a static linking affair. This comes with many risks, like becoming complacent and not updating the "inner browser" due to browser incompatibilities and bugs. It creates a giant mess of dependency update hell if you aren't regularly updating the webview. At that point, you might as well ship a desktop app that does something similar and proxies ads through the first party server since it's probably less work. You are right that it would work. I just don't know if going to such lengths is required to achieve the same thing. A good counter is that a desktop app could be exploited to alter the behavior via reverse engineering. But a browser would show you the WASM as well, so I'm sure you could reverse engineer it and alter it with an extension like a traditional binary. Maybe I'm missing something though - I'll admit that I'm an advocate of WASM but don't keep super up to date on all advancements.