Three mistakes from Dart/Flutter's weak PRNG • Hacker News Board

Re: Three mistakes from Dart/Flutter's weak PRNG

#91

Post by Apocryphon » Sun, Dec 15, 2024, 2:36 PM UTC

mightyham wrote: post #88

Apocryphon wrote: post #87

Earlier quoted context omitted.

> numerous attractive alternatives that are more familiar and popular There’s React Native. Ionic is stuck in the same limbo that PWA are in and Tauri is obscure. Qt is hardly used in mobile apps and Microsoft’s successors for Xamarin deprecate themselves every few years. What else is there, NativeScript? Kivy? Delphi?

Dart is really not much different from a PWA/Ionic though: the language requires bindings to use native APIs; it's runtime is not native to any platform (where as most platforms do have native web runtimes); and it's rendering system doesn't support native widgets (in fact, it currently uses Skia which is the same rendering library as Chrome).

And yet, it has much higher adoption. I think it might be because PWA have long been second-class citizens on mobile, even with some recent OS updates.

Re: Three mistakes from Dart/Flutter's weak PRNG

#92

Post by liontwist » Sun, Dec 15, 2024, 4:12 PM UTC

matthewdgreen wrote: post #79

swatcoder wrote: post #65

Earlier quoted context omitted.

> this type of incident used to pop up on HN every month or so, and yet in the past few years they've become incredibly rare. And do you know why that is? It is not because developers got better. It's almost entirely due to the fact that development frameworks (particularly JS in browsers) have made a multi-year and systematic effort to reduce the availability of insecure default PRGs to bad developers. The result is…

Just to beat the horse to death, I want to be clear that what I'm asking for isn't much: 1. The default random() call/library should always produce exactly what it says -- real, secure, unpredictable (pseudo)random numbers. 2. For statistical and non-security applications it's perfectly fine to have a generator of the form random.insecureAndFast(). Or call it whatever you want, the important thing is that the develop…

I think this is a reasonable solution. I also hope we can standardize a random function which takes an integer range of maximum.

Re: Three mistakes from Dart/Flutter's weak PRNG

#93

Post by fermuch » Sun, Dec 15, 2024, 8:25 PM UTC

colmmacc wrote: post #59

cmovq wrote: post #51

PRNGs are insecure by design, why does this article frame the problem as the implementation being insecure? Applications shouldn’t use PRNGs if they need a true random source to begin with.

The only true random sources in the universe are quantum. But it's not practical or performant to hook your workload up to a raw quantum measurement like the spin of a fundamental particle, or radioactive decay. Instead we take sources that are still believed to be statistically random and influenced by underlying quantum randomness. E.g. RF interference, clock phasing, or an avalanche amplifier that are measures of…

> The only true random sources in the universe are quantum. But it's not practical or performant to hook your workload up to a raw quantum measurement like the spin of a fundamental particle, or radioactive decay.

I was under the impression that's how entropy generators for servers work?