That’s why there so much work being put into giving wasm a more typical (for a vm) typed heap. Similar issues occur with lifetime of objects - if you get anything from the dom, you have to keep it live if wasm references it, but wasm has no idea of what memory or a handle is.
These are solvable problems, but you’re not getting dom access until after they’re solved.
Because the wasm memory model doesn’t have typed memory - if you call a dom api and get a handle back, you need to store it. Then you need to be able to pass it back to the host vm.
So now your wasm code needs to make sure the handle stays live - wasm by design doesn’t interact with the host GC, so you have to manually keep the handle alive (refcounting apis or whatever), and the host VM has to have someway to deal with you trying to use the handle without having kept it alive.
Similarly because wasm is designed around storing raw memory in the heap the wasm code can treat the handles as integers. Eg an attacker can just generate spoof handles and try to create type-confusion bugs, or maybe manually over release things.
So the problem isn’t “how do we let wasm make these calls” but rather “how do we do that without making it trivially exploitable”.
https://github.com/WebAssembly/reference-types/blob/master/p...
Those that aren't have an extremely limited API - that would be logically not dissimilar from "untrusted wasm talks to more trusted JS".
https://github.com/WebAssembly/reference-types/blob/master/p...