Yes. I am saying that some website operators would like to load an entire browser into your client just so they can control the presentation (make sure you're not able to block their ads, control their scripts, etc).

I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it's code running on your computer. You're free to attach a debugger to step thru native code that runs a VM that runs a nested VM that's ultimately running the code you'd actually like to influence. Let me know how that goes for you.)

Have you seen JSLinux[1]?

[1] - https://bellard.org/jslinux/

I don't think it is necessary to make websites extremely complex, to prevent you from blocking ads.

I think blocking ads is a game you can never win. If you are able to block ads on some websites today, it is just because the site owners allow you to do so (they could easily prevent you from doing so). Ads technologies can evolve to a point when you as a human can not distinguish between ads and the rest of the content.

It would make content control more complicated, but it can't make it impossible.

If the embedded browser uses the host's HTTP implementation, then you can filter and edit content there.

If it implements HTTP itself on top of raw sockets, then you can intercept traffic on socket level (although you'd need to MITM any SSL connection).

If the inner browser has its own client certificate or simply checks for a set of known server certificates, MITM won't get you anywhere. Done right, this could well be game over.

For it to be truly game over, the wasm implementation it's running on must also protect the wasm payload itself, otherwise it would be trivial to patch that to MITM it.

So, on something like iOS, it could be game over (but I'm also curious what Apple is going to do with wasm there, given that it goes contrary to their strategy of being the gatekeeper for all code running on the platform). But not for the rest.

Adding a ton of obfuscation will do the trick. Patching wasm requires reverse engineering and that is very cumbersome. For Blu-Ray it took months to reverse engineer the copy protection VM and that was with a mechanism that took a lot of attention. If it's your average website, it's far easier to stay ahead of the game.

Instagram, Facebook, Pintrest, Youtube apps are already this thing. Tens of megabytes embedding a browser to view web content. Their traffic covers a significant portion of the entire web. All of these have a lot to gain from rendering ad blocking impossible. And for keeping people on their "platform", inside their walled garden. Right now they are shipped as native apps, which the web version will nag you about until you install it. I don't think it is so farfetched that they will try to use WebAssembly for the same.

> It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage?

Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database.

So we have a file-system storing a database that exposes a completely different database that holds a file system.

Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I wouldn’t be surprised if 50 MB was a more common webpage size than 5 KB these days.