powerforthepeople.party / security
We don't ask you to trust us. We built a system where trust is unnecessary — the cryptographic architecture makes it mathematically impossible to link your identity to your vote. This page explains how, in plain language and in technical detail.
When you register to vote, your device creates a credential. It gets sent to the election authority in a "sealed envelope." The authority stamps the envelope proving it's valid — but never opens it to see what's inside. You open it yourself later. The stamp proves you're allowed to vote. Nobody knows what's in the envelope.
Your vote is locked in a mathematical box when you cast it. At the end of the election, all the locked boxes are added together using a special kind of math. The result — the total count — is produced without any individual box ever being opened. Your specific vote is never decrypted. Not ever.
When you cast your ballot, the system needs to verify that it contains a legal choice — not 47 votes for the same option, not a blank. A zero-knowledge proof lets your ballot prove this to the system without revealing what you chose. The system accepts the proof and posts your ballot without ever seeing the content.
The key to decrypt the election tally is split across 5 trusted community members called trustees — your steward, your block captain, a community elder. To produce the result, at least 3 of the 5 must cooperate simultaneously. One trustee going rogue, being bribed, or being pressured cannot compromise the election alone.
After you vote, you receive a receipt — a random code that identifies your encrypted ballot on the public bulletin board. You can verify your ballot is there. Any observer can verify that all ballots on the board were included in the tally. Any observer can verify the tally arithmetic is correct. None of this requires trusting us.
If someone pressures you to vote a certain way and prove it — your employer, an abusive partner, anyone — you can cast a replacement ballot that invalidates your first one. You can show the coercer you "voted" their way using the old receipt while your real vote stands. The system is designed so coercion cannot be verified.
Monitors all traffic between your device and FOLKMOOT servers. Attempts to link your identity to your ballot by correlating timing, IP address, request patterns.
A WOPR Systems employee or election administrator attempts to stuff the ballot box, alter vote totals, or discover how a specific voter voted.
Government seizes the FOLKMOOT server with a court order or by force. Attempts to identify which voters voted which way for retaliation.
An attacker creates many fake community members to cast multiple votes. Attempts to overwhelm legitimate community votes with fabricated participation.
An employer, abusive partner, or authority figure demands a voter prove how they voted, threatening consequences for the "wrong" vote.
An attacker who compromises the FOLKMOOT application container attempts to break out to the host operating system to access other services or data.
FOLKMOOT's security posture is not self-certified. Every claim on this page is subject to independent review. The audit results are published publicly — because transparency is part of the security model.
| Audit Type | Scope | Target / Standard | Status |
|---|---|---|---|
| Automated SAST Semgrep, Bandit, pip-audit, npm audit |
All Python + TypeScript source code, all dependencies | Zero High/Critical findings required to merge | Planned · Phase 4 |
| DAST / Web App Scan OWASP ZAP full active scan |
Full application attack surface on staging environment | OWASP Top 10 2021 · All Medium+ findings remediated | Planned · Phase 4 |
| OWASP ASVS Level 3 Application Security Verification Standard |
Full application checklist — authentication, cryptography, data protection, API | Level 3 (highest — same as banking/election systems) | Planned · Phase 4 |
| Container / Host Hardening Audit docker-bench-security, Lynis |
Docker container config, host OS baseline | CIS Docker Benchmark v1.6 · CIS Ubuntu 24.04 L2 | Planned · Phase 4 |
| External Penetration Test Independent security firm |
Network perimeter, web application, container escape, business logic, cryptographic implementation | Full pentest report published publicly · All Critical/High remediated before launch | Planned · Phase 5 |
| Cryptographic Protocol Audit Independent cryptographer / security lab |
Protocol specification, crypto library implementation, ZKP correctness, threshold scheme | Protocol spec + test vectors reviewed · Report published | Planned · Phase 5 |
| Ongoing Dependency Scanning Renovate Bot, automated CI |
All dependencies, continuous | Security patches auto-merged · Breaking changes reviewed | Planned · Post-launch |
| Public Responsible Disclosure security.txt · encrypted disclosure email |
External researcher community | 72hr acknowledgment · 30-day fix target · Public disclosure timeline | Planned · Phase 7 |
FOLKMOOT operates a responsible disclosure program. If you find a security vulnerability, we want to hear from you before anyone else does. Encrypt your report to our PGP key (published at /.well-known/security.txt) and send it to [email protected].
What to expect: Acknowledgment within 72 hours. Status update within 7 days. Fix target of 30 days for Critical/High findings, 90 days for Medium. We will coordinate public disclosure timing with you. We do not pursue legal action against good-faith security researchers.
We are especially interested in: cryptographic protocol flaws, authentication bypass, ballot linkability attacks, container escape vectors, and anything that breaks the coercion-resistance guarantee.