How Zero-Knowledge Surveys Work: From Browser Encryption to Aggregate Results

This walkthrough is product-level, not a cryptography textbook. For InviziPoll-specific guarantees, pair it with our Zero-knowledge architecture doc.

01How keys and links are created

Publish with keys born in the admin browser

When an admin publishes a poll, the workspace browser generates cryptographic key material for that poll. The public half is registered with the service so respondents can encrypt to the right key. The private half stays wrapped in the admin environment (password, passkey, device-bound storage, or encrypted backup), never as plaintext on the vendor.

Shared team folders add another layer: poll keys wrapped to folder keys, folder keys wrapped per collaborator. The server stores wrapped blobs, not keys it can unwrap casually.

Distribute so anonymity starts at the link

Zero-knowledge encryption protects answer content. Distribution still matters for identity:

• Shared access links carry nothing that points at a person.
• Personal links only leak identity if the tool can match the returned answer to the link that issued it. InviziPoll's private invites are personal, one-use links, but the ballot is blinded in the respondent's browser before we sign it, so we can see a link was used but can't match the answer to the link.
• No forced respondent login avoids attaching SSO identity to a submission when the program allows it.
• Access codes can gate eligibility without naming individuals when implemented as shared secrets rather than per-person codes.

If the invite attaches your employee ID in the URL, encryption still hides text from the vendor, but unless the answer is kept apart from the link, the platform may know who submitted. Zero-knowledge and unlinkable anonymity both have to hold.

02How browser encryption, storage, and decryption work

Respond and encrypt before the network

The respondent opens the poll in a browser. When they submit:

1. Answers are serialized into a payload in memory.
2. The browser encrypts that payload to the poll's published public key (post-quantum hybrid on every new InviziPoll poll; older polls keep the classical key they were created with).
3. Only the encrypted package crosses the network.

TLS still matters: it protects metadata in transit. E2EE protects answer content from the vendor after TLS terminates.

InviziPoll does not run respondent analytics scripts on ballot flows. Marketing site analytics are a separate, cookieless system.

A short page on what leaves the browser, what the server holds, and what an admin can open.

Store ciphertext only

The database row for a response should look like: poll identifier + opaque blob. No plaintext column. No per-response timestamp exposed to admins (timing can deanonymize). No "sort by submission time" view that leaks order.

That schema choice is load-bearing. Adding "just a created_at for debugging" would weaken anonymity guarantees.

Analyze and decrypt in the admin browser

When an authorized admin opens results:

1. Encrypted submissions download to the browser.
2. The client unwraps folder/poll private keys locally.
3. Aggregates (counts, distributions, charts) build from decrypted data in memory.
4. Admin UI shows aggregate views for scores, not a row-per-person spreadsheet. Written answers are shown word for word, but shuffled and undated, so nothing lines them up with a person. Where the poll allows it, anyone who'd rather not be read can send just the topics they pick instead.

Small-group protections (thresholds before showing a demographic slice) sit on top of encryption. Math stops the vendor from reading text; thresholds reduce inference on small cohorts. On InviziPoll, nothing shows until the poll's minimum group size has answered, later answers arrive in random groups of three to five, and breakdowns by group wait until the poll closes. A few answers are always held in reserve until the poll closes, so no one's answer can be picked out.

03What the server can still see

Honest zero-knowledge copy admits operator-visible metadata:

• That a submission occurred for a poll
• Administrative actions (who published, who changed settings)
• Billing and account identity for workspace admins, not respondents

Honest copy also admits limits:

• Clients can be compromised; malware on an admin laptop could exfiltrate keys.
• Employees can self-identify in free text.
• Coercion outside the software still exists.

Zero-knowledge surveys change the vendor trust equation, not human behavior.

04Zero-knowledge encryption vs ZK proofs

Some newer tools (e.g. Veranon) use zero-knowledge proofs so respondents prove membership in a group without revealing which member they are. InviziPoll uses "zero-knowledge" in the product sense: the service does not hold decryption keys for responses. Both aim at trustworthy anonymity; the cryptography differs.

Buyers should ask which threat model each design addresses.

05Why post-quantum protection shows up in employee feedback

Employee comments can stay sensitive for years: career-long, not session-long. Classical public-key encryption faces long-term "harvest now, decrypt later" risk from future quantum computers. Every new InviziPoll poll uses a hybrid construction (X-Wing: X25519 + ML-KEM-768) so ciphertext archived today is harder to break tomorrow, and published results are signed with ML-DSA-65. Explainer: What is post-quantum cryptography?.

06Quick comparison to confidential surveys

For related guidance, see confidential vs anonymous surveys.

FAQQuestions people ask