Methodology

Why this page exists

HumanVotes is built to produce data worth citing — a long-term record of what real people thought at a specific point in time. Citing data requires knowing how that data was collected. This page documents exactly how votes are gathered, stored, and protected on this site, so that anyone referencing a poll from HumanVotes can also reference the methodology that governs it.

The intended readers of this page are researchers, journalists, archivists, and anyone evaluating the credibility of a result published here. The tone is deliberately dry and technical.

Who can vote

• A registered HumanVotes account is required. Accounts can be created with an email and password, or via an external identity provider (Google, Facebook, Microsoft).
• Email addresses must be verified before voting.
• Users must be at least 18 years old to use the service, as stated in the Terms of Service.
• Each account must hold at least one credit per vote it casts. Credits are earned through human verification (see below). Credits cannot be purchased.

How a vote is collected

1. The user opens a poll's details page and selects an option.
2. The server checks that the user is authenticated, has at least one credit, and has not already participated in that poll.
3. A random VoteToken is generated and returned to the voter as a receipt.
4. A VoteProofHash is computed as SHA256(VoteToken : PollOptionId). This binds the receipt to the specific option chosen, so the recorded choice cannot be silently altered later.
5. Two records are written, in separate tables:
   • A PollParticipation row containing the user's id and the poll id — used only to prevent the same user from voting twice in the same poll. It does not contain which option was chosen.
   • A Vote row containing the chosen PollOptionId, the VoteToken, the VoteProofHash, and a UTC CreatedAt timestamp used for vote-trend analytics. It does not contain any user id or foreign key to the voter. See the Vote privacy model section below for why this timestamp does not re-create a user→choice link.
6. The user's credit balance is decremented by one and the transaction is recorded in a credit log.

Aggregate vote counts are not displayed publicly until a poll has at least 20 votes. Below that threshold the UI shows progress toward the threshold rather than percentages, to limit how much early-vote framing can shape later voters.

The credit system

Three actions on the site cost one credit each: casting a vote, creating a poll, and posting a comment. Credits exist so that contributions are not free clicks: each contribution represents real human effort spent at some point by the account that made it. Credits are earned in two stages of human verification:

1. An ALTCHA proof-of-work challenge that the user's browser must solve. The work factor is randomized between configured minimum and maximum complexity values; challenges expire after a configured number of seconds and cannot be reused.
2. An image rotation puzzle: the user is shown a randomly rotated image and must rotate it back to upright within 15 seconds, with a tolerance of ±10°.

On a successful run the account is awarded 2 credits.

Rate limits in force on this earning path:

• After a successful run, the account must wait 60 minutes before attempting again.
• After a failed run, the account must wait 15 minutes before retrying.
• An account may attempt verification at most 10 times per day, regardless of outcome.

The values above are the defaults shipped with the application. They are environment-overridable via configuration; an operator running this deployment may have set different values. If a documented value changes, this page is updated and the methodology version is bumped.

Bot resistance strategy

HumanVotes does not assume that bots are impossible. It assumes only that bots are expensive. The structural defense has two parts that must be paid per account:

• Effort per attempt. Each successful run awards two credits and requires solving a proof-of-work challenge and an image-orientation puzzle within a strict time limit. This raises the marginal cost of every additional vote.
• A daily cap per account. Even an account that fully automates the puzzle can only earn a bounded number of credits per day. Buying more influence requires controlling more accounts — which requires more verified emails or external-provider identities, each of which has its own cost.

The combination — cost-per-vote multiplied by cap-per-account — is what makes large-scale brigading economically unattractive on this site relative to platforms where votes are free. It is not a guarantee against sophisticated adversaries, only a structural disincentive.

Vote privacy model

A vote is recorded as two separate database rows that are not joined:

• PollParticipation stores who voted in which poll — user id and poll id only. It does not contain the chosen option. Its only purpose is to prevent the same user from voting twice in the same poll.
• Vote stores what was chosen — the PollOptionId, a random VoteToken, the VoteProofHash described above, and a CreatedAt timestamp. It contains no user id and no foreign key to a user.

The CreatedAt column on Vote is the only time-correlated column on any vote-adjacent table. PollParticipation and the credit-spend record carry no timestamp. They are also stored WITHOUT ROWID, meaning SQLite's hidden auto-incrementing row identifier — which would otherwise preserve insertion order — is not present on those tables. The practical consequence: an operator cannot order users by vote-time to align them with the time-ordered list of choices on Vote. The user-side and choice-side tables share neither a join key nor a parallel ordering, by design.

After voting, the user is shown their VoteToken. They can later enter that token on the vote verification page to confirm the chosen option still hashes to the recorded VoteProofHash — i.e. that their vote was preserved unchanged.

Known limitations and biases

Anyone using data from this site should be aware of the following caveats:

• Self-selection bias. The respondents are people who chose to register, verify, and spend earned credits on a vote. They are not a random sample of any population.
• Low-N inference. The unlinkability guarantee is a database-record guarantee: no shared key joins a user to a choice. On polls with very few participants, an operator with full database access could still infer choices statistically — in the limiting case, a poll with one participant and one recorded vote trivially reveals that voter's choice. The 20-vote public-display threshold protects readers from early-vote framing but does not eliminate this inference risk for an operator at low participant counts.
• Demographic skew. No demographic characteristics are attached to votes. Any inference about which populations are represented must be made externally and clearly disclosed by the citer.
• No cross-IP coordination analysis. The site does not log or correlate IP addresses across votes, so coordinated voting from a single network is not detected at this layer. The credit-cost and daily-cap defenses operate at the account level only.
• Operator trust. Vote choice is unlinkable to identity at the database-record level, but the application code is the source of truth for tallying. Independent verification of tallies depends on the exports and snapshots described in the project's archival roadmap.
• Moderation effects. Polls or comments that violate the Terms of Service may be hidden by moderators. Hidden polls are excluded from public listings.

Versioning policy

This page carries a methodology version label at the top. Any change to how votes are collected, scored, filtered, or displayed — or any change to the documented numeric values — will result in a version bump and a new "last updated" date.

Prior versions of the methodology are preserved in the project's git history and will be archived alongside data exports as that infrastructure comes online. A poll cited from this site should always be cited together with the methodology version that was in force when the poll closed.