zlacker

>>fugled+(OP)
Well this definitely won't get exploited at all or lead to new strict limits on what Harfbuzz/WASM can do

>>bastie+YR
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.

>>lxgr+dU
Is there scientific proof of above claim such as "WASM sandboxing is pretty good!" ?

At least most if not all ffmpeg decoders and demuxers are fuzzed all the time and any found issue is addressed.

>>pbmaho+xD1
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.