I often struggle with simple choices in life.
I often flip a coin to make a decision.
I often don’t have a coin handy.
So to solve this, I just slapped together a simple bash script that let’s me flip a coin on my phone.
I set out to make this as quickly and simply as possible so I used yad (inspired by a years-old Purism news post). It’s not very pretty and the way the screen refreshes is a little annoying (none of the yad --window-type options seem to make a difference in Phosh ), but I don’t care and wasn’t looking for perfection here, either .
If you really need to flip a coin when having to make a decision in life which you can’t decide about, you want a perfect non-deterministic bet: that is an even distribution 50/50 on a statistical scale of 1 million tries. This is called entropy (as in information theory concepts): e.g, entropy = 0 if the result is always the same and known in advance.
Have you tried to test your app’s performance in this sense? I’d be curious to know the real entropy you can achieve on such deterministic hardware as a smartphone, and I wouldn’t rely on this method if I were to decide if I should marry or not…
Reminds me of a preinstalled app on my first smartphone where you could shake the phone and two 3D dices are rolling over the screen, bouncing on screen edges and against each other. This was actually cool.
About 50/50 chance of fatal breakage (theoretical risk probability) from 2 feet (and each drop increasing the likelyhood [due to sustained damage it’s not even a fallacy])? Surely it would be simpler to have the back cover just say “tails” (would be funny on a good phone case).
Maybe also about 1/100 chance the phone lands on edge? We need Purism to commit 100 phones to give us empirical statistics! I can already see the jokes about what an L5 is good for…
The app is using the bash RANDOM variable. So the app is likely no better or worse than that - and perhaps the internet already contains discussions and evaluations of the latter.
My guess is that bash is using a pseudo-random number generator, which means “not very good” / “not cryptographically strong”.
Also, technically ‘random’ does not imply ‘uniform’ but probably for this purpose we want unbiased i.e. uniform. The bash doco doesn’t even say that RANDOM is uniform. However a true random source that is non-uniform can be made uniform in software (or in hardware).
An improved version might use /dev/random or /dev/urandom which should at least be cryptographically strong.
This is not entirely accurate. A deterministic device can contain dedicated hardware that produces non-deterministic results (specifically for the purpose of seeding an operating system’s source of randomness, and this is basically needed on any computer that is doing crypto).
There are two options:
You use the ARM built-in ‘random’ instruction. But do you trust it? And is it implemented properly in the specific ARM implementation in the CPU of the Librem 5? (Parallel questions would arise for any modern x86 computer.)
You have auditable hardware that is external to the CPU (e.g. a separate chip) to produce true random outputs. This might be a stretch target for Librem 5 v2. However maybe the existing OpenPGP card can generate random numbers for you.
Dude, if you have to toss a coin to answer that question then I think the answer should automatically be “no”.
Actually, I never use coin tosses for important decisions…rather I go by this: 2 columns, one PROs and one for CONs. This gives me a better evaluation of advantages/disadvantages of either choice, and also maybe listing the CONs makes it suddenly appear a no-go!
Oh Nooo! Sacrificing such beautiful hardware for the sake of it?
And no need: if you draw two lines from the 4 edges of the phone, the intersection (middle point of the crossing diagonals) is the supposed gravity resultant application point (aviation physics, weight and balance applying to a mobile.) Now if you carefully put the phone on a vertical needle, centering it on that point, you will see which side it falls - proving that the smartphone has not an even weight distribution internally, because of its different components and location thereof. The “coin” will more likely fall to the same edge when you flip it, so its entropy is therefore much decreased.
Not good for committing your very last money on number 35 at Vegas!
I usually go around this by using user input timestamp (the moment the button is pressed) as seed for the random-value. This way I outsource the “luck” from digital machine to analogue human. It is only important that the timestamp has a high enough resolution (milliseconds are fine) to have the time out of human control.
And the bash doco even tells you how to reseed. Good enough for human decision making i.e. the application of this topic. Not good enough for crypto.
(My computer says nanosecond precision i.e. from date --resolution. I don’t know whether that is false precision or there is some kind of cycle counter register that it can use to fill in the lower order digits. However it is certainly false accuracy, and ironically that increases the strength of the randomness slightly.)
Higher resolution is also fine. When creating games you even have resolutions in worst “normal” cases of about 33.3ms resolution, which is also still okay. But it should not become much lower. On 100ms it starts to become manipulable. And of course my solution is about coin flipping and alike. I have no idea about crypto programming etc.
PS Use SRANDOM instead of RANDOM if you want “secure random”. It does not use the pseudo-random linear congruential sequence that RANDOM uses (or so I imagine) but instead will use /dev/urandom if available.
), but I don’t care and wasn’t looking for perfection here, either 
.
