It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me.
There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world.
While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful.
Here’s an example. In my essay about Gorton, there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross:
But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better:
An interesting flavour of a molly guard that can only happen in onscreen interfaces is “occasionally moving things out of the way to mess with the user.”
The messing-with-the-user part is, ostensibly, for their benefit. Making something not appear in the usual position, or not behave the usual way, becomes a speed bump, cancels out motor memory, and forces a conscious reaction rather than flying through the interface on autopilot.
The simplest example is dialogs that ask about dangerous actions suspending the “default action happens when you press Enter” behaviour:
(There is a way to continue the dialog on the right using the keyboard alone – but it’s only via ⌘R and not the default, breezy Enter.)
Another version is swapping buttons or showing them in an otherwise unusual order:
But remember when I said “can only happen in onscreen interfaces?” Well. The apotheosis of this very idea, spotted in a New York alley, proves otherwise:
It’s a Hirsch ScramblePad, inconsistent very much by design, a login mechanism where every time the digits get put in a different place.
The idea is meant to help with two problems:
It makes it harder for someone standing behind to learn your code from just watching your movements, as it abstracts the movements to be one step away. (The strange visual filter is meant to make the viewing angle as narrow as possible, too.)
It prevents uneven wear and tear of the buttons, which people could use to guess your code:
I understand “ScramblePad” was the original product (here’s the patent with some nice illustrations), and the name got genericized since. Here’s competition, MIWA Random Tenkey – once probably so much more futuristic, today equally quaint:
One can occasionally see more modern versions today:
But back to our beloved screens, where some banking web apps copied the idea:
I’m not a security expert, so I won’t try to opine how effective those things are. I tried to research whether forcing a password out of motor memory – which these will accomplish – is ultimately better or worse, but a lot of the papers I found were inconclusive. (As always, some of the theoretically good ideas for security bounce off of human limitations and convenience: Forcing someone to remember a password might mean they will write it down somewhere, effectively making things worse.)
By definition security and usability coexist wearily, so it was nice someone thought about allowing me to do this at an opportune time, rather than at a random moment that might be extremely untimely or stressful.
