Transparency
Make the privacy claim inspectable
A reviewer should be able to inspect Pluria's public pages, code anchors, rules, tests, and docs and reach the same conclusion about the voting privacy boundary.
The claim should be verifiable from implementation, not marketing copy.
The review target is new production voting, not deleted prototypes or external networks.
Public results show counts and context, not account-level ballots.
The standard
Transparency means the public claim can be tested against the implementation. For voting, the core question is simple: does the production path create a durable link between a signed-in account and the option that account selected?
The expected reviewer conclusion is no for new production votes: participation is known, selected option is redeemed anonymously, and voter metadata is counted separately from the option rollup.
Evidence bundle
Blind voting code
functions/src/callable/blindVote.ts separates credential issuance from anonymous option redemption.
Cryptographic helpers
functions/src/logic/blindVote.ts defines the blind credential purposes, manifest, signing, and verification helpers.
Retired direct voting
functions/src/callable/castVote.ts rejects the old authenticated direct vote path.
Rules boundary
firebase/firestore.rules denies client access to private voting paths and server-owned rollups.
Verifier tests
functions/test/ballotPrivacyContract.test.ts and functions/test/blindVoteLogic.test.ts encode the privacy contract.
Docs contract
docs/VOTING_PARTICIPATION_AND_ELIGIBILITY.md and docs/BALLOT_PRIVACY_AND_TRANSPARENCY.md explain the shipped behavior.
Public surfaces
Open public reading
Poll pages, result pages, embeds, methodology, privacy, safety, and terms are available on the web.
App-only voting
The web can display and share polls, but actual voting happens through the app vote contract.
Reviewable privacy boundary
The relevant code, rules, tests, and docs can be published together so reviewers can inspect the claim.
Plain limitations
Pluria does not describe itself as an official election system or a full anonymity network.
Change control
Any future change to voting should update the callable contract, Firestore rules, tests, public privacy copy, methodology, and internal docs in the same release. If a future poll family needs a richer answer payload, it should be added behind the blind redemption API without reintroducing an authenticated account-to-option write.
Questions a reviewer should ask
- Does the authenticated credential step receive a selected option?
- Does the anonymous redemption step accept Firebase Auth?
- Can demographic values travel with an individual selected option?
- Can clients write voter receipts, token markers, or rollup shards directly?
- Do tests fail if the implementation reintroduces a user-to-option record?
Limits
Pluria can make the application code path reviewable. It cannot make a public website prove every property of external infrastructure, device networking, app-store identity systems, or user coercion. See Voting privacy for the precise claim and Privacy for data categories.