Yes, a terrible decision - but still a decision left up to any developer in a similar position - which, with the trend to WASMify things may well happen again in other projects, until it's better addressed at the source.

Honestly, it's so bad it makes me wonder if a bad actor could have had influence over such a decision in this case. Reports of Trust Wallet accounts being randomly pilfered without some plausible other cause might go some way to figuring that out.

This makes no sense. What source should it be addressed?

This is an issue of standard libraries, whereas WASM is a specification of an execution environment. WASM doesn't have a standard library, since it doesn't even have a canonical source language!

It's like demanding that x86 or aarch64 offer better Unicode or SVG support.

Developers should never end up in a situation where they feel the best cryptography solution is to "roll their own". That's likely what happened here. And the situation needs to change. It doesn't matter where in the stack that change is affected.

So you're saying all languages (and in fact ISAs, because that really describes WASM more accurately!) need to come with a static analyzer that detects and prevents any attempts of implementing low-level cryptography rather than calling out to a high-quality library? Because that's what happened here.

What we can do is provide well-tested and ergonomic high-level cryptographic libraries; I don't see how we can enforce their use.

Well if you know of a simple way to target - reliably - a high-quality crypto lib that can access any underlying OS entropy source to generate a decently random number, with WASM, please inform us of it here; it'd be great to know.

Though admittedly, it seemed terrible if there wasn't, so I would be happy if the post can be proven deficient. I'd have ordinarily assumed many options available in the .js ecosystem, instead accepting it's a WASM OS-access issue.