There's Math.random(), and then there's Math.random()

Do be sure to note the mention that the new algorithm is not considered a cryptographically secure PRNG.<p>Also because the specification has very little by way of requirements in that regard, no matter how good <i>some</i> implementations may be you should always assume you code may end up being used in an environment where Math.random() is no better than the worst generator you can think of.<p>If you need specific properties in your PRNG then you still need to provide something in place of Math.random().

It seems to me that defaulting to a non-CSPRNG these days is a premature optimization: for many purposes a decent CSPRNG (e.g. Fortuna) is fast enough, and avoids all the pitfalls of a non-secure or poorly-random generator.<p>Maybe it&#x27;s time to have Math.random and equivalents call a CSPRNG, with a Math.insecurerandom when performance matters?

&gt;&quot;Please keep in mind, if you find areas of improvement in V8 and Chrome, even ones that—like this one—do not directly affect spec compliance, stability, or security, please file an issue on our bug tracker.&quot;<p>Worst idea ever, this not-a-real-bug got a correction in just a few days without even being in the bug tracker, while there are real bugs stalled for years in the tracker. Writing a blog post and making a lot of noise on the internet works way better than using the bug tracker.

A worth to read article by [Mike Malone](<a href="https:&#x2F;&#x2F;medium.com&#x2F;@betable&#x2F;tifu-by-using-math-random-f1c308c4fd9d#.a7ewychse" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@betable&#x2F;tifu-by-using-math-random-f1c308...</a>) explains the problem with Math.random() in more detail.<p>Quoting Donald Knuth &#x2F; The Art of Computer Programming:<p>&gt; “Many random number generators in use today are not very good. There is a tendency for people to avoid learning anything about such subroutines; quite often we find that some old method that is comparatively unsatisfactory has blindly been passed down from one programmer to another, and today’s users have no understanding of its limitations.”

I wondered how the &quot;static&quot; visualizations were produced, then noticed the link under the image: <a href="http:&#x2F;&#x2F;bl.ocks.org&#x2F;mmalone&#x2F;bf59aa2e44c44dde78ac" rel="nofollow">http:&#x2F;&#x2F;bl.ocks.org&#x2F;mmalone&#x2F;bf59aa2e44c44dde78ac</a><p>There you can see the code and watch it run. Neat!

This article[0] hints that Microsoft&#x27;s Edge browser might also being using MWC1616, or something else that has a lot of the same limitations. Hopefully they jump on the xorshift128+ ship.<p>[0] <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;666407&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;666407&#x2F;</a>

Somewhat related, I wrote a blog post about (P)RNGs a few years ago: <a href="http:&#x2F;&#x2F;dvt.name&#x2F;2010&#x2F;clock-drift-hardware-prng&#x2F;" rel="nofollow">http:&#x2F;&#x2F;dvt.name&#x2F;2010&#x2F;clock-drift-hardware-prng&#x2F;</a>. It&#x27;s interesting to se V8 favor accuracy over speed.<p>I&#x27;d think that having a &quot;secure&quot; random number generator isn&#x27;t that important of a deal given the fact that all code runs client-side anyway (so why the need for cryptographic security?).

Pretty sure I saw the &#x27;After&#x27; picture in the mall, circa 1992. If you cross your eyes and look &#x27;through&#x27; it just right, you&#x27;ll see the sailboat.

Jan also wrote about this <a href="http:&#x2F;&#x2F;jandemooij.nl&#x2F;blog&#x2F;2015&#x2F;11&#x2F;27&#x2F;math-random-and-32-bit-precision&#x2F;" rel="nofollow">http:&#x2F;&#x2F;jandemooij.nl&#x2F;blog&#x2F;2015&#x2F;11&#x2F;27&#x2F;math-random-and-32-bit-...</a> in the context of Spidermonkey.

For people concerned with cross-browser reproducibility as well as resuming a PRNG between sessions (e.g., to reproduce random sequences in replays or multiplayer), check out arbit, an NPM package I made. It performs close to Math.random and uses floats for state internally for max resolution (i.e., length and number of unique sequences):<p><a href="https:&#x2F;&#x2F;github.com&#x2F;blixt&#x2F;js-arbit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;blixt&#x2F;js-arbit</a><p>I would also recommend running the provided DieHarder test, which is crafted to measure the quality of PRNGs.

Previous discussion (from one month ago) on the referred article with discovery of the bug:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10598065" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10598065</a>

Is there an explanation anywhere of what technical or other criteria they used to pick xorshift128+? I haven’t seen any from the handful of blog posts, etc. I’ve seen about the change. <i>“[...] having understood the problem and after some research, we decided [...]”</i> is hardly a persuasive analysis.<p>Were any professional experts on PRNGs asked for advice?

The first one looks more random to me? It has more runs. There was some article (can&#x27;t remember the source) about generating a random coin flip - the way to tell the difference between a real physical coin flip and a computer is that the real physical flip will have a lot of runs, like 10 times in a row where you get heads. A computer random will attempt to &quot;even out&quot; the spectrum. The two images presented in the article looked similar to these but were reversed, true random looked more like a pattern, while computer generated random looked more like even noise.<p>TL;DR long strings of repeated results are a sign of true randomness. Am I misinterpreting the relationship between that and this article?

This kind of stuff seems scary to me. One JavaScript engine decides to use this algorithm, another that. This type of change could lead to <i>higher potential</i> of bugs and unexpected behaviour, the average developer just can&#x27;t figure out when say, using Firefox or Chrome for testing.<p>When algorithms are getting tinkered with behind the scenes, this leads me to believe there&#x27;s still way too much churn in the JS space.