New languages should make sure the default random() is cryptographically secure, and hide PRNGs behind weakrandom() or repeatablerandom() or something. Safe and slow defaults are better than fast and unsafe.
Since dart/flutter is multi platform, using Random.secure for animation has it's own performance issues with interfacing host entropy RNG.
The majority of Dart/Flutter users are creating UI apps.
Few browsers with security policies and OS combination does not allow access to the entropy with Flutter Web in which Random.secure will fail, this isn't exclusive to Dart/Flutter. [1]
NaCL [0] offloads these concerns for developers, especially indie/startup.
[0] https://en.wikipedia.org/wiki/NaCl_(software)
[1] https://api.dart.dev/dart-math/Random/Random.secure.html
I'm more a fan of "make the defaults as secure as you can reasonably expect to get away with for each step of the way". It'll never be as secure as everyone wants but if you but up against "it's as secure as people would want to put up with by default" then things are at least at a good starting point for others to build from. The hard part is finding out what people are willing to put up with and which tradeoffs are worth it. That default random number generators "only" go at GB/s on most PCs because they produce really good random numbers is probably an easy tradeoff though.
IMO, it's not worth it: It makes working with random numbers very problematic when working on cryptographic use cases.
I don't think rng seeding has anything to do with the algorithm you choose? Seeding from the os rng is usually what you want even for a prng. If you want to use use the current time there is a `seed_from_u64` if you want.
Seeding from an entropy source is critical for encryption, but that can take time depending on how it works.
- randomWeak() - randomSecure()
[0] In my experience, most of them -- who reads documentation these days...? Or programmers using editors like vim (no slight on vim by the way, don't shoot me!) which (generally) won't alert the programmer to the library options, unless it's been set up with a suggestion/completion/intellisense plugin?
[1] randomSecure() vs randomInsecure(), which can look similar at 3:00am on three hours sleep. Naming the functions explicitly differently makes it patently clear which function is cryptographically safe. Also helps when the interpreter/compiler won't understand the context the function is being called in, therefore can't throw warnings or errors to alert the overtired/overworked programmer that they're using insecure random number generation for crypto.
Big brain idea: Perhaps cryptographically-weak/insecure random number generators should be type incompatible by default, requiring an explicit cast to integer/float? Probably overkill, but definitely wards off mistakes and/or misuses by forcing the developer to type cast out, otherwise the compiler simply refuses, then explains why by fatal error at compile time, or by exception thrown.
But then why not make secure random number generators type incompatible by default? Because we're trying to encourage secure-by-default programming, making it slightly harder (but not onerous) to use the equivalent insecure function over secure one. Create a speed bump to prompt the programmer to think about their code, not a road block.
That has the advantage of avoiding problems in a generation's time: if most platforms moved to random() being secure, it would be excusable if young programmers started assuming that would be the case on older platform too.