WASM sandboxing is pretty good! Together with the presumably very limited API with which this can communicate with the outside world, I wouldn't be too concerned.
To me, it's a great reminder that the line between well-sandboxed turing-complete execution environments and messy implementations of decoders for "purely declarative" data formats can be quite blurry.
Said differently, I'd probably trust Harfbuzz/WASM more than the average obscure codec implementation in ffmpeg.
Fuzzing is good, robust sandboxing is better, I'd argue. There's just a much smaller surface area to cover for the latter.
> Is there scientific proof of above claim such as "WASM sandboxing is pretty good!" ?
I'm not aware of quantitative studies, but just from a design perspective, the surface that a WASM runtime presents seems intrinsically easier to defend than that of, say, the full Unix userspace that ffmpeg instances usually run in.
Anecdotally, many high-profile iOS and Android vulnerabilities originated in some more or less obscure codec implementation.
To me, it's a great reminder that the line between well-sandboxed turing-complete execution environments and messy implementations of decoders for "purely declarative" data formats can be quite blurry.
Said differently, I'd probably trust Harfbuzz/WASM more than the average obscure codec implementation in ffmpeg.