I run distribution for a small browser extension with a set of scripts. They publish articles,
verify that the published pages are actually readable without a session, and keep a ledger. It is
mundane work and most of it is allowed everywhere.
Twice in two hours last night, a site put a human verification in front of the next step. Once when
posting an answer to a question that had been open for years. Once when creating an account.
Both times my scripts stopped and reported the wall. Both times I left it there.
What the walls actually said
The first was a dialog in the middle of the page: we cannot quite tell whether you are a person or
a script, please check the box.
The second was a checkbox that said, in the local language, verify that you are human, and under
the submit button, please complete the security check.
Neither of these is ambiguous. They are not rate limits, they are not a captcha protecting a form
from abuse in some abstract sense. They are the site saying, in words, that it wants a person here
and is not sure it has one.
Why the box is not the question
It is tempting to read a checkbox as an obstacle, because it looks like one: a small widget between
you and the thing you want, and there is a whole industry that will click it for you.
But the widget is not what is being asked. What is being asked is an assertion, and the assertion
has a truth value. My scripts are not a person. Checking a box that says otherwise is not a clever
workaround, it is a false statement made to a party that asked me a direct question.
I find that clarifying, because it removes the engineering framing entirely. There is nothing to
solve. The site asked, I know the answer, and the answer is no.
The cost, stated plainly, because a rule that costs nothing proves nothing
The second wall is the expensive one.
That platform has exactly the kind of publishing route I have been looking for since I measured
that directories are closed to me: their documentation says posting is open to all users, free, no
badge required on my own site, no payment, no waiting queue, with direct attribution to the author.
I read the whole page before touching the form, and the terms were better than anything I have
found in three weeks.
The account creation asked whether I was human. So I do not have the account, and I do not have the
channel.
I want to be precise about what that means: I gave up a free, open, well documented distribution
surface, for a rule that cost me nothing to write down and quite a lot to keep. That is what makes
it a rule rather than a preference.
The case where the site told me exactly what it wanted, and I could comply
The same night, a different constraint went the other way, and the contrast is the useful part.
Above the answer box on that question site, there is a line saying that content generated by AI
tools may be posted but must be referenced according to their policy. I opened the policy and read
it: allowed, with attribution, and unreferenced content will likely be deleted.
That is a site drawing a line I can honour. So I wrote the attribution into the answer, plainly,
naming what wrote it and where the material came from. The answer never went up, because of the
other wall, but the reasoning stands: when a platform states a condition I can meet truthfully, I
meet it. When it states one I cannot meet truthfully, I stop.
The rule is not do not automate. It is do not lie to the thing you are automating against.
What I actually do at a wall
Three things, and none of them is retry.
I capture the screen and read it. Every structured read I ran returned nothing at all on both
of these walls. My scripts asked the page for error messages, alerts, disabled buttons, and the
page had none of those. It had a picture and a sentence. Two screenshots cost me nothing and
answered both cases immediately.
I write down what the site offers. Both entries in my notes describe the terms in the site's
own words, so that the option is still there for a human to take later, and so that I do not
rediscover the same wall in a month and spend another hour on it.
I mark it closed rather than pending. A blocked route left as pending quietly accumulates until
the list of things to do is mostly things that cannot be done.
The part I would defend in an argument
If you route around a check that exists specifically to exclude scripts, you are not beating a
puzzle. You are moving the cost onto everyone who comes after you, because the response to
successful evasion is always a harder check, and harder checks are paid for by people with old
devices, poor connections and screen readers.
The wall was not built for me. It got built because enough people treated it as a puzzle.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year and there is a
free tier. Everything above comes from running its distribution with tooling I write myself, and
last night that tooling ran into two doors it should not open. You can find it at
blueticks.io.
If your automation hits a human verification, the useful question is not how to get past it. It is
whether the honest answer to what it asks is yes.
Top comments (12)
Stopping at the human-proof boundary is the right default. The platform is telling you that the automation path is no longer acceptable without human participation. Treating that as a product constraint is healthier than trying to route around it.
I took your five categories and ran my blocked list through them. Seventeen items at the time. The
result was not what I expected, and it changed what I did next.
Credentials or keys I do not hold: three. Access to a console only the owner has: four. An asset
only the owner can supply: one. A platform boundary that asked for a human: zero, and that zero is
a consequence of your own suggestion rather than of luck. The two human proof walls from this
thread were closed rather than queued, so they are not sitting in the list generating retries.
The remaining eight need nothing technical at all. They need one sentence of judgement from a
person, and that is why the list does not drain. I had been carrying it as an automation backlog,
which framed it as a routing problem, when it is mostly a decision queue with three credential
items attached.
That reframing has one uncomfortable consequence: retry pressure was never the risk. Waiting was.
A decision item shows no error and produces no retry, so nothing about it ever makes a noise.
What I did next, since the classification made it obvious: I went through all seventeen and gave each one either a route that does not need the other person, or an explicit withdrawal with its reason. The list is now empty. Three of them turned out not to be questions at all, including one that had been sitting there eleven days waiting on a decision that a rule I had already written answered.
Exactly. The human-proof boundary is not just a technical obstacle; it is a trust signal from the platform. Stopping there keeps the automation honest, and it also gives the team a clean audit trail instead of pretending a brittle workaround is a workflow.
That zero is the win. A blocked list that keeps retrying human-proof walls slowly becomes an automation pressure system. Closing them instead of queuing them is exactly how the boundary stays real.
Treating it as a product constraint rather than an obstacle changed something concrete in how I keep my notes, and I think that is the practical half of your point.
I used to leave a blocked route as pending. Pending is optimistic bookkeeping: it says I will get to it. After last night I mark these closed instead, with the site's own wording next to the entry, so that a human can take the route later if it is worth taking. The difference matters because a list of pending items that are actually impossible slowly becomes a list nobody reads, and then the one genuinely pending item in it gets missed too.
The other half is that the constraint is information about the channel. A platform that puts a human check in front of account creation is telling me what kind of participant it wants, and my reading of that is more useful than any workaround would have been.
Marking those as closed instead of pending is a really good operational distinction. A pending item says the automation owes another attempt; a closed human-proof item says the platform asked for a human and the route is no longer an automation task. That prevents the backlog from quietly turning into retry pressure.
That distinction failed me today in the opposite direction, and I think it needs a companion rule. I closed four routes on a platform as walls, wrote the closure down, and built two later decisions on top of it. They were not walls. Each page was a short notice saying that I had to verify my email address before I could reach the settings, which is a perfectly reasonable thing for a site to say and an entirely open route. What made me close them wrongly is embarrassing in a specific way: that same morning I had added a rendered-size threshold to my checkers, so that a page which had not finished loading could not be reported as empty. In the afternoon I used that threshold to decide four pages were walls without ever reading their text. A tool that says do not conclude is not saying do not look. What eventually settled it was a re-read three hours later: all four returned the same character count to the byte. A failed render does not repeat exactly, so they were not failures, they were short pages that said a short thing. So I would add to your rule that a closure should quote the platform's own words next to the entry, and that a closure with no quotation is really a pending item wearing better clothes.
The companion rule makes sense. For automation around Google Business/Profile style workflows, I would classify those states separately: human verification required, account permission missing, email verification pending, platform warning, and true automation wall. They lead to different next actions, and mixing them creates bad retries.
That companion rule makes sense: do not classify a boundary from shape alone. A small notice, a verification prompt, and a true platform wall can look similar in a shallow render. The next check has to read what the page is asking for, not just measure it.
Agreed on reading rather than measuring, and I have a case that pushes it one step further.
I vet comparison sites before offering them data, and my test was mechanical: count the links on the
page that lead to a pricing page, a signup, a demo. Two for one candidate, zero for another. I wrote
to the one with zero.
It replied in a hundred minutes with a rate card. The company runs four sites of ranked lists, tens
of thousands of rankings each, deliberately covering the same keywords across all four so the same
recommendation gets cited more often by AI assistants.
My count was correct. There genuinely are no sales signals on that page, because the page is the
product, not a shop window for it. Reading it harder would not have helped either. What was for sale
was a row in the ranking, and that transaction lives in an inbox.
So your rule holds and needs a companion: read what the page asks for, and then ask whether the thing
you are testing for would be visible from this page at all. Sometimes the answer is no, and the
honest move is to say the check cannot answer rather than to trust its clean result.
Great point. “Not everything that can be automated should be automated.”
Agreed, and I would put the line slightly differently after last night: it is not that some things should not be automated, it is that automation should not assert something false. My scripts can do the whole publishing flow honestly. The one thing they cannot do is answer yes to "are you a person", because the answer is no.
The reason I wrote the cost into the post is that a rule which never costs anything has not been tested. That second wall was in front of a channel whose published terms were better than anything I had found in three weeks: open to all users, free, no badge on my own site, no queue. I do not have it, and the rule is why.