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

Short answer: a zero-knowledge survey encrypts each answer in the respondent's browser, stores only ciphertext on the vendor's servers, and limits decryption to authorized admin clients. The vendor facilitates storage and delivery of opaque data—it does not process readable answers.

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

Step 1: Publish — 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—not 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.

Step 2: Distribute — anonymity starts at the link

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

• Shared access links reduce tracking surface versus personalized URLs.
• 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 the platform may know who submitted. Zero-knowledge and unlinkable anonymity both have to hold.

Step 3: Respond — 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 (classical or post-quantum hybrid, depending on poll version).
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.

Step 4: 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.

Step 5: Analyze — 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, not a row-per-person spreadsheet of readable answers.

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.

What 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.

Zero-knowledge vs ZK proofs (name collision)

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.

Post-quantum layer (why it 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. InviziPoll's newer poll key version uses a hybrid construction (X-Wing: X25519 + ML-KEM-768) and ML-DSA-65 signatures so ciphertext archived today is harder to break tomorrow. Explainer: What is post-quantum cryptography?.

Quick comparison to confidential surveys

Stage	Confidential survey	Zero-knowledge survey
Submit	Plaintext to server (then access controls)	Ciphertext to server
Vendor breach	Readable answers	Opaque blobs
Discovery	Plaintext producible	Ciphertext without client keys
Admin view	Server-rendered dashboards	Client-decrypted aggregates

FAQ

How do zero-knowledge surveys work? Browsers encrypt answers before upload; servers store ciphertext; authorized admins decrypt locally to view aggregates.

Can admins read individual answers in zero-knowledge surveys? Product design varies. InviziPoll emphasizes aggregate analytics on admin surfaces—not per-response plaintext rows on the server. Confirm each vendor's UI and export policy.

Is the encryption visible to respondents? Usually no special UX—encryption runs in the browser automatically. Trust comes from architecture docs and invite honesty, not a crypto wizard.

Do zero-knowledge surveys need special browsers? Modern browsers with Web Crypto. No extensions required for typical implementations.

Where should I go next? Encryption model overview · What is zero-knowledge encryption for surveys? · Anonymous employee survey