1. 58
  1.  

  2. [Comment removed by author]

    1. 9

      The fact that they aren’t using Mersenne Twister is kinda mind-boggling. Like, in gamedev, we’ve known that shit for two decades.

      1. 1

        Mersenne Twister might not be sufficient for real money gaming.

        1. 1

          In cases like this, if you ever use the default RNG without at least a wrapper so you can switch to something better–especially something you can seed reliably, which Math.random emphatically isn’t–you are doing it wrong.

          MT might not be the best, but it’s basically table stakes for this sort of stuff.

          1. 5

            MT’s great for Monte Carlo, but it’s a terrible choice if you have an adversary who might benefit from being able to predict the output of your PRNG.

            It takes 624 consecutive observations from an MT PRNG to be able to absolutely determine its internal state: https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html

            That’s also not a hard limit. Fewer observations don’t radically increase the computation difficulty of determining the PRNG’s internal state: https://jazzy.id.au/2010/09/25/cracking_random_number_generators_part_4.html

    2. 13

      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.

      1. 14

        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?

        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…

        1. 1

          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.

          1. 2

            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

        2. 7

          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 people want to have something cryptographically secure and basically don’t care about performance. In JavaScript, you 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.

          1. 1

            That’s why it’s titled “TIFU” instead of “TIL”

          2. 2

            This is an excellent post. Most posts that claim that “X is broken” are a bunch of hot-headed ranting, but this is actually very well researched and coherent with proof and a working solution to the problem. I’m proud of you, internet.