I was trying to get something done on DigitalOcean when the website asked me to prove I was human. That seems reasonable enough. Cloud platforms attract automated account creation, credential attacks, spam, fraud and all manner of machinery that has no business wandering in through the front door. I have spent a fair amount of my life helping people keep such machinery out of places it doesn't belong. I am not opposed to security checks.
Then the dice appeared.
On the screen was a collection of five oddly rendered dice, covered in little black-and-white pictograms that looked as though somebody had emptied the miscellaneous-symbols drawer onto a camouflage tablecloth. Beside them was another pictogram, a pair of arrows and an instruction that began, “Use the arrows to find the image where the number of symbols on the top sides of the dice matches the left image exactly.” This was the first of two rounds.
I read it. Then I read it again. Was I supposed to match the type of symbol? The total number of symbols? The number of symbols on each die? What were the “top sides,” plural, in a picture where some of the cubes were tilted and the pictograms themselves seemed to have been designed by a committee of startled hieroglyphs? How was the image on the left a number? The longer I stared, the less confident I became that the sentence and the picture belonged to the same puzzle.
I started talking it through with an AI system. Yes, an artificial intelligence. The thing I was using to think through my work was now helping me understand the instructions for a test intended to distinguish humans from machines. Somewhere in that conversation, I finally noticed the almost comically small “×1” beside the sample symbol. Oh. I wasn't being asked to make the dice look like the sample. I was looking for the image in which that particular symbol appeared one time on the upper faces of the dice.
Perfectly obvious once you know.
Or, to put that differently, a human being had to enlist an AI to help him understand how to prove to a computer that he wasn't an AI.
I have rarely encountered a more compact metaphor for the present state of cybersecurity.
The meeting where this must have sounded like a good idea
I have no idea what happened in the meetings that produced that challenge, who designed its particular puzzle, or how well it performs against abusive automation. The DigitalOcean brand was on the page; that does not tell us who authored the CAPTCHA or what its measured effectiveness is. So allow me a little fictional reconstruction of the design meeting, based solely on the fact that this thing exists.
“We need a way to distinguish humans from bots.”
“Right. What can humans do that bots can't?”
“Interpret an obscure pictogram, notice a tiny multiplication sign followed by zero, identify the upper surfaces of five crooked dice, and use arrows to search through a series of nearly identical illustrations.”
“Will it stop the bots?”
“Hard to say. But it will definitely make a human stare at the screen for five minutes trying to figure out what the hell we're asking.”
“Excellent. Ship it.”
That meeting is imaginary. The architectural failure it illustrates is not.
We have spent so long talking about friction as a security mechanism that we sometimes forget whose movement the friction is supposed to impede. A lock is useful because it frustrates unauthorized entry while allowing a person with the right key to open the door. A gate is useful when it governs a boundary. A security check is useful when it separates materially different risks. If the gate requires an authorized person to learn a new language before entering, while the adversary can study, automate or outsource that language at scale, we may be congratulating ourselves on the wrong achievement.
The difficulty of a task is not evidence that it measures the thing we claim it measures.
In this case, the supposed distinction was human versus automated. What I experienced was a test of willingness to spend human attention on unexplained visual logic. Those are not the same categories. A perfectly legitimate user may give up, misunderstand the rule, miscount, have impaired vision, struggle with the spatial presentation, be tired, be using a small screen, or simply have better things to do. An automated attacker may fail. It may also use computer vision, a different attack path or an inexpensive human-solving service. You cannot determine the security value of the challenge by watching one annoyed customer fail to understand it.
You can, however, determine something about the customer experience.
And that something is not trivial.
We have started charging the wrong side of the transaction
A CAPTCHA does not merely occupy screen space. It takes attention. It interrupts the task a person came to perform, requires them to interpret the platform's invented problem, demands a response, and withholds progress until the platform is satisfied. Sometimes that exchange is justified. A bank might reasonably demand an extra confirmation before moving a large sum of money. A sensitive administrator action may deserve a hardware-backed second factor. An anonymous public endpoint under attack may need to slow down suspicious traffic.
But if you make the ordinary, legitimate user repeatedly demonstrate compliance with an increasingly abstract ritual, the resource being consumed is not the attacker's compute budget. It is the user's finite supply of patience, concentration and trust.
I have been writing lately about the need not merely to pay attention, but to save it. Human attention is an operational resource. We protect processor time, network capacity, memory, storage and battery life. We tune systems so that they don't generate unnecessary retries or floods of meaningless events. Yet we routinely build security and administrative processes that treat a human's attention as free because it doesn't appear on a cloud invoice.
The person who spends six minutes deciphering a puzzle has paid a bill. The security product's dashboard may never show it.
Multiply that by registration forms, identity checks, access requests, changing passwords, approvals, cookie notices, training acknowledgements, meaningless alerts, escalating support tickets and meetings arranged to explain why somebody cannot get into an account. Each individual mechanism may have a locally defensible story. The organization can be very busy measuring how often the controls fire while remaining almost entirely blind to how much legitimate work those controls prevent.
Security then begins to exhibit a familiar pathological behavior: it imposes a cost on the people it is supposed to protect, calls that cost compliance, and treats resistance as evidence that more controls are needed.
Not all friction is bad.
But friction without a demonstrated security benefit is just drag with a badge.
There is a secondary cost that practitioners ought to recognize immediately. People adapt. They look for shortcuts. They ask coworkers to complete an exercise for them. They switch devices. They reuse approved sessions in unapproved ways. They look for browser extensions and automation that will make the obstacles go away. In my case I started asking an AI for help understanding the challenge. None of that makes the user malicious. It means the security design is producing workarounds, and workarounds are the beginning of a new threat model.
If the human has to work around the security system to complete the legitimate task, you should be curious about what else the human will eventually work around.
A little litmus paper in the internet's pond
When I was looking at the screenshot, I kept thinking about litmus paper. Dip a test strip into a solution and the color tells you something about the chemical environment. Acidity means lower pH, by the way; higher pH means more alkaline. We are not going to accidentally invent basic acid just because cybersecurity could use a new metaphor.
A single strip does not identify every substance in the water. It does not tell you the whole ecosystem is doomed. But when it changes color, you have a reason to ask what is happening to the environment that everything else must live in.
I think this little CAPTCHA is a litmus strip for the internet.
Not because one awkward puzzle proves that DigitalOcean is insecure, or that its bot-defense vendor is incompetent, or that CAPTCHAs never work. Those would be claims unsupported by the screenshot. I mean something subtler: the interface reveals an operating assumption. It assumes that complicated effort imposed on a legitimate person is acceptable collateral in demonstrating the presence of security. It assumes the platform's challenge is self-explanatory, even when its human user cannot readily determine the question. It treats successful passage through a ritual as a proxy for a property the ritual is supposed to measure.
When enough of our systems adopt those assumptions, the water turns acidic.
The resulting environment is corrosive to ordinary participation. New users learn to expect suspicion. Existing users expect interruption. People with disabilities encounter barriers that others barely notice. People who are unfamiliar with the platform or its visual conventions spend their time trying to decode the interface instead of accomplishing their purpose. The work gradually becomes less about establishing trust and more about surviving whatever the system throws in the way.
The accessibility problem here is real and not particularly new. The World Wide Web Consortium has long documented the difficulty CAPTCHAs present for people with visual, sensory and cognitive disabilities, and its guidance on accessible authentication explicitly addresses puzzle-based tests. The screenshot did include an audio option, which is worth acknowledging. An alternative modality can help. But the presence of a little headphone icon does not make the original instruction comprehensible, and it doesn't tell us how usable the alternative is for any given person.
The point isn't that a human struggled, therefore the security failed. The point is that a human struggling is itself a signal worth measuring, especially when the struggle concerns deciphering the test rather than demonstrating the property the test is meant to establish.
A litmus strip doesn't fix the water.
It tells you to stop pretending you haven't noticed the color.
The attacker, unfortunately, gets a vote
There is a reason we have CAPTCHAs. Abusive automation is real. Fake registrations, credential stuffing, inventory hoarding, card testing, scraping and other automated misuse can damage services and the people who depend on them. Eliminating every challenge because some people dislike challenges would not be serious security engineering.
But neither is making the puzzle stranger every year.
OWASP's bot-management guidance treats visible CAPTCHA challenges as a last-resort step-up rather than a primary defense. Its recommended posture is broader: understand the abusive behavior, combine signals, limit rates and use proportionate responses without turning every legitimate visitor into a suspect. This is not a promise that any alternative is perfect. Nothing in this area is. It is an argument for measuring the actual adversarial problem instead of making the user's inconvenience stand in for a risk assessment.
Here is the measurement I would like to see beside every CAPTCHA success-rate graph: How many legitimate people did we delay, confuse, or lose in exchange for the abusive activity we actually prevented?
Not how many challenges were displayed. Not how many images were clicked. Not how many people finally got the answer right after three tries. Those numbers describe the operation of the mechanism. They do not establish that the mechanism produced a positive security outcome.
Show me bot-abuse reduction. Show me false positives and registration abandonment. Show me the experience of people using assistive technology. Show me how the challenge behaves when a legitimate user has a poor connection, a tiny screen, an unfamiliar language, or simply an exhausted brain at the end of the day. Show me what happens when the risk is low compared with when the risk is high. And show me whether the system can recognize that it already has trustworthy evidence about a person rather than repeatedly demanding fresh performances of humanity.
Security is an exercise in allocating friction to risk.
When we cannot explain what risk a particular friction reduces, we should be cautious about calling it protection.
What the dice are really telling us
The five dice are funny. I may keep the screenshot around for years just because it illustrates the absurdity so efficiently. But the reason it feels larger than one CAPTCHA is that the pattern appears everywhere.
We build a permission process to make sure the right people can act, then require the right people to navigate so many opaque approvals that the real decision is made by whoever happens to know the workaround. We build alerting to help an analyst notice danger, then bury that analyst in notifications until the only practical way to survive is to ignore most of them. We add labels intended to distinguish trustworthy information, then require ordinary people to interpret a taxonomy that changes more often than the threats do. We build a security awareness program that trains employees to recognize suspicious behavior, then send messages from legitimate internal systems that look indistinguishable from phishing.
Every component can be fulfilling its local specification while the surrounding system moves further from its purpose.
That is the failure to watch for. A control can be technically functional and architecturally misaligned. Its tickets close, its dashboard turns green, its audit evidence is tidy, and the mammal standing in front of it still has no idea what the hell it wants.
If you are a security practitioner and you encounter one of these experiences in your own environment, treat it as a useful environmental reading. Ask who is being asked to do work and why. Ask whether the demand measures a real threat or merely satisfies the assumptions of the control. Ask how much ordinary human attention the mechanism consumes. Ask whether automation has made the adversary's work cheaper while making the legitimate user's work harder. Ask whether the organization knows the difference between a control that is present and a control that is accomplishing its purpose.
Above all, remember who the system is supposed to serve.
I eventually understood the little ×1. It was a symbol-counting instruction, not an occult initiation rite. I could play the game once I knew the rules. That does not make the experience good, and it does not establish that the game protected anything.
What it did give me was an unexpectedly sharp way to test the condition of the water.
If your system makes a human ask an AI how to prove he isn't one, don't congratulate yourself on the strength of the gate.
Check the pH.
