Threat model

InviziPoll is designed for respondent anonymity and confidentiality by design: the platform cannot read plaintext answers or access admin key material without secrets that stay on the client or with trusted admins.

What the architecture protects against

Threat	How we address it
Database breach	Responses are stored as encrypted blobs with no usable plaintext for the service.
Insider access to sensitive data	Database permissions restrict routine operational access so that response ciphertext, key material, and data that could re-link access codes to submissions are not available through standard tooling.
Small-group deanonymization	Poll results stay locked until at least 3 responses; cohort breakdowns require at least 5 matching responses before showing splits. Below threshold, the product stays locked and does not expose exact counts.
Linking access codes to responses	Access codes are verified without retaining a reversible link to submissions. Storage is designed so the service cannot associate a consumed code with a particular response.
Ordering inference	Authorized decrypt flows receive ciphertext blobs in random order so list position does not imply submission sequence.

What we do not claim to prevent

Limitation	Notes
Compromised admin device	Malware or physical access to an unlocked admin session can see what that admin sees after decryption.
Weak backup passwords	Strong key derivation slows guessing but cannot fix low-entropy passwords.
Social engineering	Users may be tricked into sharing backup files, passwords, or recovery secrets.
Server-assisted checks (non-content)	Some flows use the server for eligibility or delivery checks in ways that do not require decrypting poll answers. This is separate from the client-held keys that protect response ciphertext end-to-end.
Availability	DDoS and outages are separate from confidentiality guarantees.

Related reading

• Encryption model overview
• Access codes and anonymity
• Anti-inference deep dive