InviziPoll Security Threat Model

Note

This page lists what we design against and where the protection stops. For the behaviour behind each row, see Zero-knowledge architecture and the Encryption model overview.

InviziPoll is built so that nobody can tell who gave an answer, and so that answers are encrypted before they leave the respondent's browser. We can't read your answers, because we never hold a key that opens them, and nothing we store links an answer to the person who gave it; this page is honest about the places where protection rests on how we run the service rather than on mathematics.

#What the architecture protects against

Threat	How we address it
Database breach	Each answer is encrypted in the respondent's browser to the poll's public key before it's sent. A copy of our database holds answer ciphertext, not answer text, and no key that opens it.
Our copy of your keys	Your key backup is locked in your browser before it reaches us, with your password or your recovery key. Nothing we store can open it. Your recovery key never reaches us at all. Proving you control your inbox gets you that locked copy, not the keys, so you still type your password or recovery key.
Forged results documents	Your workspace's signing key never reaches us in a form we can open, so a valid signature is a claim we couldn't have forged.
Someone else approving your new device	A new device can only be approved from another signed-in device on the same account. No owner or admin can approve a device for someone else.
Someone restoring access they shouldn't	An owner can restore a colleague's access only after confirming a code with them directly; we can't do it for them. The owner types a code the colleague reads out by voice or in person, and the owner's browser restores exactly what the colleague had before, never more.
Linking an answer to a person	A stored answer is the poll it belongs to and its ciphertext, nothing else. No name, email, IP address, device, or submission time is saved with it.
Double voting on private invites	Personal invite links use blind-signed ballots. The ballot is blinded in the respondent's browser before we sign it, so we can see that a link was used, but we can't match the answer that comes back to the link that issued it. Each ballot can be spent once.
Linking access codes to answers	A code is checked and marked used in the same step that stores the answer, so one code gives one answer. We keep only a hash of each code and never store which answer it was used for, so there's no join to look up afterwards.
Small-group inference	Admins see nothing until the poll's minimum group size has answered, and that's never fewer than three. Cohort cuts, shared slices and published documents need at least five people, or the minimum group size if higher, in any group they show.
Timing inference	While a poll is open, answers reach admins in randomly chosen groups of three to five, never oldest first. A few answers are always held in reserve until the poll closes, so no one's answer can be picked out. At close, everything shows. The response count still goes up by one each time. How batched release works.
Comparing a group before and after	Breakdowns by group only appear once a poll has closed, never on a poll that stays open. At close they're checked once, together, against every release group, and any cut that could be worked out by subtraction is withheld without a reason.
Ordering inference	Answers aren't stored with a time, and admins receive them shuffled, so the order on screen says nothing about who answered first.
A manager seeing more than their team	A shared slice is an aggregate snapshot for one group. It never carries the poll key or any single answer.
Answers sent to an AI provider	Summaries of written answers run on a model in the admin's browser. No AI on responses leaves the browser.
Script injection on our pages	Our pages send a strict Content-Security-Policy. The browser only runs script files served from our own site, and no inline script runs, which closes the usual way an injected script would read what's on screen.

#What we do not claim to prevent

Limitation	What it means
You trust the code we serve	Encryption happens in the page we send to your browser. If our site were compromised and served altered code, that code could read answers before encryption. The strict script policy narrows this; it doesn't remove it.
Network metadata	We don't store IP addresses with answers. Our submit rate limiter counts submissions per network using a keyed hash of the IP address that rotates daily. The raw address isn't stored, and expired counters are deleted on a schedule. A counter records that a network submitted to a poll, never what it answered.
One vote per invite is our rule	Each poll's ballot-signing key is held on our servers. One vote per invite is enforced by us; it isn't something you can check independently.
A compromised admin device	Once an admin has unlocked the workspace, anything that controls their browser can see what they see.
Weak backup passwords	A key backup or recovery file protected by a guessable password can be guessed.
Social engineering	People can be talked into sharing recovery files, passwords, or their inbox. An owner restoring a colleague's access should only accept the code from that colleague in person or by voice, never from a message.
Open links	An open link or QR code accepts any submission, slowed by a per-network rate limit. It doesn't stop one person answering twice.
Fake answers around a real one	Whoever controls an open link or a batch of access codes could fill a poll with fake answers around one real one, and then the floors protect nobody. No threshold stops that. Ballots tied to a roster that person doesn't control do.
Self-identifying written answers	Admins read written answers word for word, shuffled and undated. Content can still identify its writer, unless they send only topics.
Very small audiences	If only three people are invited, knowing who took part can be revealing on its own.
The on-device summary model	A small model can restate one person's answer. Read summaries as a draft.
Availability	An outage isn't a breach, but it can stop people answering before a deadline.

See also Share a slice: one team's results for one manager, On-device AI summaries: what runs where, Recovery, emergency kit, and device handoff. Each page covers the adjacent settings and workflow steps.

#What the architecture protects against

#What we do not claim to prevent

#Related