Hacker News Reader

Comment by mmalone | Hacker News Reader

It wasn't dependent on exact behavior. It was dependent on a sensible general contract. We rely on sensible implementations of general contracts all over the place in software development.

We did make an incorrect assumption that the PRNG (created by Google, who has a good reputation, and in what is probably the most popular software in the world) was high quality. That was a mistake, and we should have done more homework. However, there's no reason why the Math.random() implementation in V8 should _not_ be good enough to not have to worry about.

View on HN

This is a tricky answer. The default random function in many environments is poor (see other examples given above and below), if you are generating a unique id using a PRNG and think in terms of the birthday paradox, then you should also be concerning yourselves with the quality of the random generator. While it is unreasonable to expect every developer to know the ins and outs of a deeply technical issue, defaulting to using a known good (enough) algorithm like MT over making an assumption about the quality of an unknown algorithm (unknown at least until you looked into the source code) just because it came from google is poor engineering (IMHO)

The analysis in this article was great engineering - something that in my experience often happens after poor engineering... YMMV

It was dependent on it being a CSPRNG which it wasn't. Math.random is designed for things like games and animations where randomness isn't critical and performance is important.

Actually CSPRNGs are slightly worse if you are more worried about distribution than predictability (he mentions this in the article). If you are using it in a context where a hostile attacker cannot gain anything via predicting or manipulating the generated numbers, then for birthday-paradox type resistance an alternate non-CS PRNG, like those typically used for simulations, is more appropriate. However when you're using JavaScript, it's likely the natively implemented CSPRNG will be faster than a custom "faster" PRNG implemented in JavaScript.

No, it wasn't. Read the article again. Assumption made was on Math.random being high quality PRNG. Being cryptographically secure is completely unrelated.

Medium quality, really. But it was neglected and bad for no reason, no tradeoffs.

Reply on news.ycombinator.com