Section 17 · Section 22
Threat model
The threats that matter here are mostly not exotic. They are a photographed envelope, a late scan, a tired insider, and a person standing over someone's shoulder.
| Threat | Risk | Required mitigation |
|---|---|---|
| Copied or photographed envelope code | Replay or duplicate return attempt | One-time token, digest validation, state controls, and a signed duplicate-exception event |
| Predictable token values | Guessing and enumeration | 256-bit CSPRNG, digest storage, rate limiting, authenticated status access only |
| Missing postal scan | False assumption a ballot is lost or late | Postal data is advisory; physical intake and law control the outcome |
| Delayed postal event | Incorrect event ordering | Store source time and ingestion time separately; append late evidence without overwriting a decision |
| Insider alters event history | Undetected manipulation | Append-only storage, signatures, per-token chains, anchored batch commitments, access monitoring |
| Compromised scanner | Forged or invalid events | Device identity, signed events, restricted role, anomaly detection, offline reconciliation |
| Unauthorised acceptance | Improper ballot decision | Role separation, MFA, dual control where required, complete audit trail |
| Re-linking voter to vote | Ballot secrecy violation | Hard system boundary, no tabulation references anywhere in the lifecycle system, dual-controlled separation |
| Coercion using a status proof | Pressure and retaliation against a voter | No vote-choice receipt, minimal disclosure, strong authentication, no third-party portal |
| Service outage | Lost records, operational disruption | Offline controlled procedures, encrypted queues, disaster recovery, reconciled back-entry |
| Bulk void or reissue error | Disenfranchisement at scale | Dual authorisation, dry run, scoped batches, a reversal plan, and an audit alert |
| Public metadata exposure | Voter privacy risk | Restricted postal/token mapping, aggregate-only public reporting, access review |
The three that are easy to get wrong
The photographed envelope code
This is the threat everyone thinks of first, and the mitigation is not secrecy — a code printed on an envelope that travels through the mail is not a secret and cannot be treated as one. The mitigation is that the code is single-use for acceptance. Photograph it all you like; the second presentation after acceptance writes an exception and moves nothing.
Which is also why the raw token is stored only as a SHA-256 digest. A database breach yields digests, and a digest cannot be printed on a counterfeit envelope.
The late postal scan
A scan that arrives three days after the office already made a decision must not be able to retroactively rewrite that decision. It is appended as evidence, with its source time and its ingestion time recorded separately, and the earlier determination stands unless an authorised official changes it through a compensating event.
The single-timestamp version of this design is the bug. If you only store "when it happened", you cannot later prove the office did not have that information at the time it decided.
The insider who edits the database
Per-token hash chaining catches an edit. It does not catch a deletion of the most recent events, or a whole token's worth of records removed together — the remaining chain is still internally consistent. That is precisely why batch anchoring exists: the signed root and sequence range committed an hour ago cannot be re-derived from a shortened log.
And it is why one anchor copy must live somewhere the authority does not control. See the anchoring page →
Explicit prohibitions
Not defaults. Not configurable. These do not become acceptable because a customer asks, a vendor offers, or a deadline is close.
Tokenize, record or encode vote choices — anywhere, in any form
Put selections in a QR code, barcode, token, log, receipt or notification
Let a voter prove how they voted
Use a public blockchain as the lifecycle record
Publish individual token or postal records
Require a video call, biometric demonstration or possession check to vote
Make a postal scan a prerequisite for counting a lawfully received ballot
Give campaigns or unauthorised third parties individual ballot-status access
Permit the tabulation system to query lifecycle or identity data
Store ballot images in the lifecycle system
Make participation conditional on an app, wallet, biometric, QR scan or internet access
Override statutory deadlines, cure procedures or election-official authority
Claim certification that has not actually occurred under applicable law
The last one is about this page too. Nothing here is a claim of EAC certification, VVSG conformance or legal compliance. If a jurisdiction classifies a product like this as voting-system equipment, or integrates it into a certified workflow, the applicable certification and testing requirements are determined by that jurisdiction — not by the people who built it.