Why ciphertext-only storage matters for sensitive polls
Many tools advertise “anonymous surveys.” InviziPoll separates marketing language from architecture: poll responses are encrypted in the respondent's browser before they reach us, and servers persist ciphertext - not identifiable answers.
Illustrative diagram: an answer is sealed in the respondent's browser with ML-KEM-768, stored as ciphertext, and readable only in the respondent's browser and your team's browsers, never by our operators.
Respondent browserplaintext
How likely are you to recommend this workplace?
Sealed in this browser before anything leaves it.
What we storeciphertext
sealed51ae14076884e5134d3a
sealedfcdee845fadb72b05dfd
sealed164a0f529a92d827f32f
sealeddf3729e233e7d1236156
sealed75901ace745a9ebc363d
no names · no IPsno unlocked keys
What operators seeresults
Theme · Workload & process
“41% of us have been asked to work time we can't log.”
61 of 148 responsesnone identifiable
ciphertext only · no exceptionsEveryone answers. No one is singled out.
BLUF: Bottom line up front
What can operators see?
Workspace admins decrypt results in their own browsers using keys they control. Admins see totals and charts, and written comments word for word, in a shuffled list with no name, time or order attached. Where the poll allows it, anyone who'd rather not be read can send just the topics they pick instead. Speak-up inboxes work differently: once the first reports are in, each new report appears on its own, so authorized admins read and reply to it individually. It still carries no name, account or IP address, and replies reach the reporter only through a return code that never reaches us. Individual responses are not readable by InviziPoll operators as part of normal service delivery - the ciphertext boundary is described in our Security hub and encryption docs (linked below).
your admins: totals, charts and shuffled, unattributed comments
results computed client-side with their own keys
cohorts above the k-anonymity threshold
InviziPoll operators: any individual response in the clear
respondent identity or device
a mapping from an answer back to a person
Guardrails
k-anonymity, enforced before the chart renders
Encryption protects the response in transit and at rest. Suppression protects it at the moment of analysis, when a well-meaning filter would otherwise narrow a result down to one person.
Set a floor for each poll
Pick a minimum group size for each poll, never below 3. Nothing shows until that many people have answered, and any result computed from fewer responses is withheld rather than rounded or blurred.
default: k = 5, set per poll
Filters are checked too
The guardrail runs on every breakdown, not just the total, and breakdowns appear only once a poll has closed. "Engineering, London, contractor" collapses to two people and returns nothing instead of a portrait.
checked on: every cut, every combination
Respondents can be told
Ballot pages can display the active threshold, so people answering know the rule before they answer, not after.
effect: stated guarantees raise response candor
On-device AI
Summarise what people wrote, without sending it to anyone
Every engagement tool now offers to turn forty comments into three themes, and every one of them does it by uploading those comments to a model vendor. Ours does it in the browser you are already reading them in. Our separate AI poll-writing assistant does use a provider, and it only ever sees questions you typed.
One click downloads a small open-source language model to the admin's own machine. It reads the written answers after your browser has decrypted them, and it writes three to five themes and a two-sentence summary there.
model: Qwen3.5-0.8B, Apache-2.0, 432 MiB, once per device
Nothing is sent anywhere
No answer, prompt, or summary leaves the browser. There is no AI subprocessor for this feature and nothing to add to your vendor list. The one network request is the model download itself, which is checked against a hash we ship before it is allowed to run.
requests carrying your text: zero
It is a draft, and we say so
A model this small can restate one person's wording closely, and it can repeat a claim a respondent wrote as though it were a finding. Every summary is labelled, needs five or more written answers before it will run, and never appears on a shared results link, in a snapshot, in Slack, or in an export unless you tick a box.
floor: 5 written answers, same as a shared slice
Desktop only, and only where the browser supports WebGPU. Where it does not, the control says so rather than quietly doing something else.
Or don't let anyone read your comment at all
On any comment box, people can choose to send only topics instead of their words. Your words stay on this device. Leadership sees only the topics you pick, and only topics several people chose: a topic shows once 2 people picked it, and the topic list appears once 5 people answered that way. If what you write mentions a name, a date or your job title, we'll offer to send just the topics. That check runs on your device too, so your words aren't sent anywhere to be checked.
What it doesn't hide
Your admin's browser unlocks each answer to count the topics. A determined, technical admin could see the topics one person picked, alongside their other answers. They can never see the words, because the words were never sent. The check before you send catches names, numbers, dates, job titles and a few phrases, in English. It can't know you're the only person who'd describe the Friday meeting that way, so no prompt doesn't mean a comment is safe.
The honest caveats
Cryptography is necessary, not sufficient
Technical controls set the boundary; process and questionnaire design protect it in practice.
Re-identification risk is a process problem too
Cryptography cannot stop a survey author from asking identifiable questions (“Submit your desk number”). Pair technical controls with sensible questionnaire design and HR policies - the same discipline required for any feedback channel.
GUIDANCE · questionnaire review before launch
Marketing telemetry vs respondent flows
Public marketing pages run first‑party, cookieless analytics for aggregate traffic only. Respondent ballot pages follow the ZeroTelemetry-style posture documented in our Privacy Policy - never mix the two when evaluating vendors.
Does InviziPoll read individual poll answers on the server?+
No. Responses are encrypted in the respondent browser; our servers store ciphertext. Aggregate insights are produced without exposing individual plaintext answers to operators.
How is this different from “anonymous mode” toggles elsewhere?+
Architectural: ciphertext-only persistence is the default boundary for poll payloads - not only a UI label. Always validate third‑party docs for each vendor you evaluate.
What about telemetry on marketing pages?+
Public marketing pages use first‑party, cookieless aggregate analytics - separate from respondent flows. See /privacy for detail.
Ask the questions people won't answer out loud.
Start a workspace and publish polls where architecture (not adjectives) protects respondent anonymity.
