Access codes and anonymity

The hard part of an anonymous poll is limiting each person to one answer without keeping a record of who answered what. InviziPoll has three ways to share a poll, and they make different trade-offs.

#Access codes

Each respondent gets a unique code, by email, Slack DM, on paper, or any other way you choose. You can also generate codes without addresses and hand them out yourself.

• We store only a one-way hash of each code, never the code itself.
• When someone submits, their browser sends the answer (already encrypted) with a hash of the code. We check the hash against the poll's list, mark that code as used, and store the answer, all in one step. A code that's already been used is refused.
• What we don't store is which answer used which code. A stored answer is the poll and its ciphertext, nothing else, and a used code records only that it was used and when.

Be precise about what that gives you. The code and the answer arrive together, in the same request, so the separation is a matter of what we keep, not of what we could see at that moment. Afterwards there's no record to join: an admin can't ask "which answer belongs to code X?" and nothing in our database answers it.

If you distribute codes against a list of names or addresses, you hold that mapping, not us. Keep it as private as you'd keep the answers.

#Personal invite links and blind-signed ballots

Personal invites are the stronger option, and the default when your workspace has a contact list. Each person gets a one-use link. When they open it, their browser creates a random ballot, blinds it, and asks us to sign the blinded version. We check the link is valid and unused, sign, and mark the link as used. The browser then unblinds the signature and submits the answer with the ballot.

Because the ballot was blinded when we signed it, the ballot that comes back with the answer looks nothing like anything we saw at signing. We can see that a link was used. We can't match the answer that comes back to the link that issued it. Each ballot can be spent once, so each invite gives one answer.

Respondents see a line explaining this on the poll page: their personal link was swapped for an anonymous ballot in their browser, which proves they were invited but can't show which answer is theirs.

What we do keep for personal invites: each invited address as a one-way hash, whether its ballot has been issued, and the day it was issued (a date, never a time). That tells you and us that someone took part, not what they said.

#Open links and QR codes

An open link accepts any submission. There's no per-person credential, so it can't stop someone answering twice. What it does have is a rate limit per network and poll, which slows scripted ballot stuffing but is set loose enough that an office full of people behind one connection can all answer.

You can require a code on an open link. Then every submission needs an unused code, exactly as above.

#Comparison

#Your part

• Don't keep a list of who got which code alongside anything else about them.
• Access codes and personal invites stop double answers. They don't make a written answer anonymous if it names the writer.
• In a small team, knowing who took part can reveal a lot on its own. Admins see nothing below the poll's minimum group size, three at the lowest, and while the poll is open a few answers are always held in reserve. How batched release works.
• Whoever controls an open link or a batch of access codes could fill a poll with fake answers around one real one, and no threshold stops that. If that's a risk, hand out codes through someone else or use personal invites to a roster that person doesn't control.

See also Slack integration. Each page covers the adjacent settings and workflow steps.

#Related

• Sharing your poll
• Threat model
• Encryption model overview
• Slack distribution and respondent anonymity