Mono and .NET’s sandboxing is historically deprecated and highly recommended against by Microsoft. .NET currently is making some improvements to the CoreCLR’s sandboxing capability, but it is unknown when/if those would be useful enough for Udon. Assembly validation isn’t on its own a solution in those sandboxing models either. You need the runtime to provide many guarantees that require you to essentially audit the entire runtime’s libraries and implementation which isn’t viable.
Using Mono directly would also raise issues with platforms that it is not made for. For instance if we wanted to eventually run on iOS, web browsers, or consoles, those platforms generally have issues with either running JITs, or are architectures that Mono’s existing JIT doesn’t support. (don’t read this as an indication of any plans for platform support, this is just something we don’t want to need to eliminate as a possibility if we want to support one of those platforms at some point in the future)
This is not embedding a web browser in the client, it is embedding a standalone Wasm runtime. Right now Wasmer is what is used, but different runtimes may be used based on platform/feature requirements.
There is no IL validation in this runtime as it is not needed. It’s not possible to call Unity functions that we do not whitelist since the linkages are not generated. If you want to represent something that’s ‘unsafe’ like using pointers in C#, it’s totally possible but you are still subject to the Wasm VM’s sandbox so if you attempt to do anything malicious you’ll at worst end up crashing the Wasm runtime in the world. IL validation’s solution to stuff like that is that you just… can’t use unsafe code which prevents the use of many C# libraries.