Random vs Pseudorandom

Three things called random

True randomness comes from a physical process with no predictable structure — radioactive decay, thermal noise, atmospheric noise. Genuinely unpredictable, and generally slow and awkward to obtain.

Pseudorandom means an algorithm. Give it a starting value — a seed — and it produces a stream of numbers that look random and pass statistical tests. But the same seed always produces the same stream, and given enough output you can work out the state and predict the rest. Math.random() is this kind.

Cryptographically secure pseudorandom is also an algorithm, built so that observing any amount of output does not let you predict the next value or reconstruct the state. It is seeded from real entropy collected by the operating system — timing jitter, hardware noise, interrupt patterns. crypto.getRandomValues() is this kind, and it is what Wheel Cue uses.

Why the middle one is not enough

Math.random() is not broken. Its output is uniformly distributed and passes the statistical tests you would apply to a wheel. For a food wheel it is completely fine.

The problems appear where a wheel is doing something with stakes:

• It is predictable. Browsers use fast, non-cryptographic algorithms. With enough consecutive outputs you can recover the internal state and predict every subsequent value.
• Nothing is guaranteed. The specification requires no particular quality. Two browsers, or two versions of the same browser, can behave differently.
• It is a bad answer to a fair question. When someone asks how a giveaway winner was chosen, "the default JavaScript random function" invites more scrutiny than it deserves.

Switching to the cryptographic source costs nothing — same one-line call, imperceptible performance difference — and removes the whole category of question. There is no reason not to.

So is a wheel spinner "truly random"?

No, and neither is almost anything else you will use.

crypto.getRandomValues() is an algorithm, seeded from physical entropy your operating system collected. It is not radioactive decay. It is *unpredictable in practice* — nobody can predict its output without breaking assumptions that also secure your bank connection.

That distinction matters for cryptographers and does not matter at all for picking a name. What matters for a wheel is:

• Uniform — every entry gets exactly its share. Yes, with rejection sampling to remove modulo bias.
• Unpredictable — nobody can call the result in advance. Yes.
• Independent — one spin tells you nothing about the next. Yes.

A wheel that meets those three is fair in every sense a giveaway, a classroom or a dinner decision requires. Claiming "true randomness" would be a marketing phrase rather than a technical one, so we do not make it.

Reading other spinners' claims

Some things worth checking when a tool tells you it is fair:

• Does it say which source it uses? crypto.getRandomValues() is a specific, checkable claim. "Advanced algorithm" is not.
• Does it mention modulo bias? Most do not, because most do not handle it. The effect is tiny, but a tool that has thought about it has probably thought about the rest.
• Is the winner chosen before or after the animation? After is worse — a rendering bug or a rounding error at a slice boundary becomes a fairness bug.
• Can you read the code? Unminified, commented client-side source is a stronger signal than any badge.
• What does it not claim? A tool that is precise about its limits is usually more careful about everything else.

Wheel Cue's answers are on how randomness works, including the part about what we cannot promise.