Honestly, this just makes Betable look bad, IMO.
First, I thought it was common knowledge that most languages have crappy RNGs in their standard libraries. Good random numbers (and especially cryptographically secure random numbers) are a lot of work and have a lot of overhead that most people don’t need. Did they really think a RNG originally meant for silly web browser animations and number guessing games was going to be any good?
Second, how the hell did they not look into it before using the built-in RNG for something involving real money?
And, also, it’s kinda lame to shift blame for their screw up to v8.
I think people do not know what bad means. Everybody knows about rand() returning alternating 0 and 1 in the low bits (so rand() & 1 makes for a pretty bad coin toss). But how many people stop to think if their 32 bit rng is two 16 bit rngs pasted together?
rand() & 1
People also hear that they need a CSRNG to prevent people from predicting the output. however, it sounds they didn’t care about these identifiers being unguessable, just not repeating.
I am firmly in the camp of using a CSRNG for all purposes (to the extent, I’ll argue CSRNG is the only RNG worthy of the title “random”), but there remains a lot of pushback from people insisting that sometimes you don’t really need a CSRNG. As even you put it, they “have a lot of overhead that most people don’t need” which I think very much exaggerates the problem, and also leads to people not selecting them. Oh, this doesn’t have to be crypto secure, so I don’t want the overhead…
I’ve also gone in the camp of defaulting to a CSRNG, because they are so much less likely to be just crap. But I do find that a bit annoying, maybe more out of conceptual clarity than practicality or efficiency concerns. For scientific simulations and various kinds of randomized algorithms, my failure case isn’t an attacker trying to reverse-engineer the PRNG state to recover crypto keys, so the whole problem (and attacker model) that CSRNGs investigate is not that relevant to my needs. But it happens that the two things in easy reach often end up being 1) a CSRNG, and 2) a really janky PRNG that isn’t even good for making kinda-sorta-looks-like-white-noise type of randomness. So then I use #1.
I recommend mentally mapping CSRNG -> RNG and RNG -> (not RNG). Then you have fewer concerns about conceptual clarity. :)
I understand that perhaps we want to reproduce Monte Carlo results, but doing that with a fixed seed and generator actually seems somewhat suspect. If your result is correct, I should be able to reproduce it, within bounds, with any decent RNG. There’s a cute example of picking the right seed to get the right result for fizzbuzz: http://chalain.livejournal.com/68788.html
There are a couple closed bugs about the quality of the random number generator, but this one has a particularly relevant quote: https://code.google.com/p/chromium/issues/detail?id=316359#c4
IMHO programs which use Math.random() for anything serious are flawed, the spec is very vague about it, and it is
basically something fast-and-not-too-embarrassing. The use cases are far too diverse to fit into a single API entry, e.g.
somebody just wants something fast to control the ghosts in a pacman clone or a nice graphical explosion, while other
are in the pacman world. :-)
Perhaps the author of the article disagrees with this perspective. If so, the best way to make things change is to file a bug or submit a patch.
That’s why it’s titled “TIFU” instead of “TIL”