Voting
Private choice, verifiable participation
Pluria can know that you participated in a poll, but the normal vote path is designed so Pluria cannot know which option you chose.
Needed for duplicate prevention, result notifications, and the "you voted" state.
Redeemed anonymously with a one-use blind credential.
Audience composition is counted separately from the selected option.
The claim
The claim is not "Pluria cannot know that you voted." Pluria must know that so it can prevent duplicate voting and show your participation state. The claim is narrower and more important: Pluria should not know which option your account chose.
In a poll with ten voters and ten options, the production vote path should not create a server-side account-to-option map that lets Pluria identify who picked which option.
How the vote path works
Eligibility check
The signed-in app checks that the personal account can vote on the poll.
Blind credential request
The device creates hidden credential messages. The server signs them without seeing the ballot choice.
Participation receipt
The server records that this account received a one-use credential for this poll.
Anonymous redemption
The app redeems the selected option through a callable request that does not include Firebase Auth.
Aggregate rollup
The server verifies the credential, blocks reuse, and increments aggregate option counts.
What is known and not known
Pluria can know
A specific signed-in account received one voting credential for a specific poll, plus choice-free voter metadata used for aggregate audience composition.
Pluria cannot know from the normal vote path
Which selected option belongs to that account. The selected option is redeemed without the account identity or demographic values.
Pluria can count
Total votes, option totals, participation receipts, credential reuse markers, and aggregate voter composition.
Pluria does not store
A durable document that combines user identity, selected option, and demographic ballot payload for new production votes.
Voter metadata
Pluria can count choice-free metadata for result quality, such as country, age bucket, gender, education level, and trusted-voter composition where those fields exist. That metadata is counted during credential issuance, before the selected option is redeemed.
The anonymous ballot redemption does not carry demographic values. This protects small or unique groups where "the only voter in a cohort picked option B" would otherwise reveal a person by inference.
Duplicate prevention
Participation receipts and blind token markers are separate. Participation receipts let the app know that an account already received a poll credential. Token markers block credential reuse after anonymous redemption. Neither record needs to store the selected option with the account identity.
Reviewer checklist
- The old authenticated vote endpoint is a retired compatibility wrapper.
- The credential issuance function does not accept choiceIndex or choices.
- The anonymous redemption function rejects Firebase Auth.
- Voter metadata is counted before option redemption and is not sent with the ballot choice.
- Firestore rules deny client writes to voter receipts, token markers, rollup shards, and vote history.
- Tests assert that no server voting document stores both identity and selected option.
The implementation anchors are the blind vote callable, blind vote logic, retired vote wrapper, Firestore rules, and the ballot privacy tests. See Transparency for the public review checklist.
Limits
This is a practical product privacy architecture, not an official election system and not a coercion-resistant voting protocol. Network providers, device platforms, and abuse defenses may still process operational metadata. The app-level claim is that the normal voting code path does not bind an account identity to a selected option.