Bots, App Check and a Cooldown: What Protects the Counter
By Rehan Sayyed, SRT Corporates · Published
A counter that anyone can click, with no account and no login, is an open invitation to automate. A script can press a button far faster than a person, and it never gets bored. If nothing stood in the way, the total would say more about one person's laptop than about the world.
Three layers stand in the way. Each does a different job.
Layer one: the database only accepts "plus one"
Every write to the counter is checked by rules inside the database. The new total must be exactly one more than the old one, nothing can be deleted, and the parts of a click have to agree with each other. That layer is described in How One Shared Number Stays Honest.
Rules can check what is being written. They cannot check who is writing it. That is the job of the second layer.
Layer two: App Check asks "is this the real site?"
Before the page talks to the database, it asks Google for a short-lived token. The token is evidence that the request comes from the genuine Click With The World site, running in an ordinary browser. The service is Firebase App Check, and the evidence comes from Google reCAPTCHA Enterprise.
This is not the kind of reCAPTCHA that shows a puzzle. App Check uses score-based keys, which work in the background, and according to Firebase's documentation the provider never asks a visitor to solve a challenge.
The token travels with every request the page makes to the database. Enforcement is switched on, which means a request without a valid token is refused. That applies to reading the numbers as well as to clicking.
Two details of how the site uses it:
- The page waits for its first token before it opens a connection to the database.
- The token is renewed automatically in the background for as long as the page stays open.
The check runs on every page that shows live numbers: Home, Milestones, Leaderboard and the embeddable widget. The widget is served from our own site inside a frame, so a click made on someone else's blog goes through exactly the same check.
Layer three: a short pause between clicks
After each click the button rests for 800 milliseconds. The database holds the same limit: it keeps the time of each browser's last click and refuses a new one that arrives less than 800 milliseconds later.
That time is filed under a random ID created in your browser. The ID is not linked to your name, your email or your IP address, and the stored times cannot be read back by other visitors.
The pause is short enough to feel instant to a person and long enough to take the point out of holding a key down.
What you notice as a visitor
Almost nothing. There is no puzzle and no sign-in. If a click doesn't count, the usual causes are:
- you clicked again during the pause,
- you were briefly offline, or
- a browser extension or privacy tool blocked the connection the check needs.
Refreshing the page normally fixes it.
What Google sees
To make its judgement, Google may collect device and browser signals and may use cookies. The details, and links to Google's own policies, are in section 4 of our Privacy Policy. We do not keep our own log of failed checks.
Why not accounts, or a puzzle on every click?
Either would stop more bots. Either would also end the idea. The site exists so that anyone, anywhere, can add one to a shared number without handing anything over first. The protections were chosen to fit that, not the other way round.
The limits
No system is foolproof. These layers are there to make automated clicking difficult and unrewarding. We adjust the protections over time, and under the Terms of Use we can correct counts that turn out to have come from automation.