Anonymity claims are easy to make. We try to be honest about exactly what True Anonymity protects, what it does not, and what schools have to do themselves to make the technical anonymity actually hold up in the real world.
Most "anonymous" tools blur this distinction. We don't.
The database cannot connect voter to ballot. The submitted ballot is written to a separate pool from the code, and the link is deleted at submission.
Owned by: True Anonymity.
Code distribution doesn't accidentally expose identity. A teacher handing a printed code to a known student in front of the class breaks anonymity socially, even when the math is fine.
Owned by: the school's distribution protocol.
Voters believe the system protects them. Without belief, students self-censor and the result becomes dishonest even when it's technically anonymous.
Owned by: both, jointly.
The governance docs published with True Anonymity include a Distribution Protocol that tells operators how to handle layer two correctly. The voter-facing privacy page handles layer three.
No software can protect against everything. Here's what falls outside the technical guarantee.
| Risk | Why we can't fully prevent it | What helps |
|---|---|---|
| Operator hands a code to a known voter and watches them scan it. | The math is anonymous; the social context is not. | Indirect distribution (sealed envelopes, posted QR sheets, parent emails). The Distribution Protocol. |
| Tiny groups. | If only 5 people are eligible and 2 abstain, the result reveals individuals by inference. | Minimum-participation thresholds; "don't publish per-question results when ballot count is below 10". |
| QR code leakage. | If a voter screenshots their QR and shares it, anyone with the image can vote. | Print on physical paper for sensitive votes; instruct voters not to forward. |
| Voter proves their own vote externally. | True Anonymity can't unsend a screenshot or recall a verbal "I voted X". | This is a feature of voter autonomy, not a bug. Voters get to decide what to share. |
| Operator with shell access to the server. | A determined IT admin reading raw files could see that ballots exist — but not whose is whose. | Limit shell access. Encryption-at-rest is on the roadmap. For high-stakes votes, host on infrastructure the operator doesn't control. |
| Insider coercion via social channel. | "Tell me how you voted or there will be consequences" is an organizational failure, not a technical one. | Acceptable-use policy explicitly prohibits retaliation. True Anonymity can't fix this alone. |
Full threat model and distribution protocol are published with the governance docs.
No. Once the ballot is submitted, the link between code and ballot is gone — even your child cannot retrieve their own ballot after the fact. This is a deliberate property of the system: a vote whose record can be retrieved isn't really anonymous.
True Anonymity doesn't currently offer free-text in ballots — voting is structured (single choice, multiple choice, ranking, rating) plus the five-category abstention reasons. None of those carry free text. If/when written feedback ships, it will require moderation policies in writing before any school can use it. Safety-escalation protocols are documented in the governance docs.
Two safeguards. First, a built-in briefing balance check that prompts operators to verify the briefing answers five framing questions before publishing — including "main arguments for each option". Second, voters can pick "Trust barrier" as an abstention reason if they believe the briefing is biased. If a meaningful share picks that, the decision-legitimacy report calls it out as a flag.
The school sees how many people picked each of the five reasons in total — but cannot see which person picked which. The five categories exist so the school can tell information failure from trust failure from option-design failure. If 30% pick "Pressure barrier", the school has a concrete signal to investigate the climate around the vote — without knowing which 30%.
Contact the school office (not the teacher running the poll). The office contacts the operator, who marks the unused code invalid and generates a replacement. Important: if the code was already used, it cannot be replaced — that would let someone vote twice or trace which ballot was "yours".
That depends on the visibility setting the operator picked at poll creation. Three options: private (operator only), shared with voters (after close), public. The setting is committed to before voting starts and can't be tightened after the fact — meaning a school can't promise public results, then quietly mark them private if the outcome is unfavorable.
True Anonymity deployments are expected to sign off on an acceptable-use policy: no retaliation, no re-identification attempts, no selective publication, no bait-and-switch. The policy is published in the governance docs. If a school is using True Anonymity and the commitments aren't visible in writing, ask why.
The full voter-facing privacy explainer is built into the app at /privacy, linked from every ballot.