Why We Sign Survey Results (and What a Signature Can't Hide)

A signed survey result is a set of numbers, the rules that produced them, and a signature that fails if any digit changes, checkable by anyone with the public key and an off-the-shelf verifier. That's the whole feature. What follows is why we built it that way, why the anonymity floors are inside the signed part, and what a signature honestly can't tell you.

The problem with a chart

A survey finding usually reaches the people who act on it as a chart in a deck. "38% of one department doesn't feel safe raising concerns." Everyone in the room takes the number on trust, because there's nothing else to take it on. A chart with a different number typed in looks identical.

That's fine while the finding is comfortable. When it isn't, "where did this come from" stops being a curious question, and the answer is usually a chain with no independent link in it: a tool the audience didn't choose, an export someone made, a slide someone built. Nobody has to be dishonest for that chain to be weak. It's weak because every link is a person saying "trust me".

We wanted a result you could check instead of trust. That turns out to need three decisions, and each one closes a door that would otherwise stay open.

Decision one: sign the numbers, not the picture

The thing that gets signed is a JSON document: per-question counts and percentages, the cohort definitions, the response count, the date it's as of. Not a PDF, not a screenshot. A picture can be signed too, but a signed picture only tells you the picture wasn't edited. It says nothing about whether the numbers in it were the numbers the survey produced.

The document is built to be canonical. Keys go in a fixed order, numbers are rounded to a fixed precision, and nothing in it records where or when it was computed. Two independent programs fed the same responses produce the same bytes. That matters more than it sounds: it's what lets a reviewer re-derive the aggregate and compare, and it's what will let a future aggregator that isn't a browser produce a document that verifies identically.

Decision two: the workspace signs, not the vendor

The obvious implementation is a server key. We'd sign every document, publish one public key, and every verifier would trust it. Easy, and wrong for this product.

A vendor signature asserts "our server computed this". The entire reason to sign a survey result is to make a claim that doesn't rest on trusting the vendor. So each workspace holds its own ML-DSA-65 keypair. The secret is created in an owner's or admin's browser and stored wrapped under the workspace's own encryption key, which our servers can't open. The public half is published. A document signed that way is a claim we couldn't have forged, which is the property that makes it evidence rather than assertion.

It also means signing can fail. If the browser that publishes hasn't unlocked the workspace's encryption, it can't reach the signing key. We let the publish go ahead unsigned, warn before the click, and the public page then says out loud that it couldn't verify what it's showing. A quietly unsigned document would teach people the badge means nothing, and that's worse than no badge.

Decision three: the floors go inside the signature

This is the one people miss, and it's the one that makes the numbers mean anything.

A percentage over a group is only a finding alongside two other facts: how many people were in the group, and what the smallest group the tool would report was. "38% of that department" over four people isn't a finding. It's an accusation with a percentage sign.

So the document carries three floors as plain integers. Nothing exists until three people have answered. No group smaller than five is ever reported. And whoever set up the survey chose their own minimum, at least three, which the document records too. A validator checks every group's count against the document's own floors, with no knowledge of our product. And because the floors are signed alongside the counts, nobody can quietly widen a cohort after the fact to make a number read better or worse. The conditions of the number's validity travel with it.

A group under the floor isn't in the document at all. Not as a blank, not as a "suppressed" marker. A marker tells you a small group exists, which is itself information about people.

How checking actually works

You need the document's JSON and the workspace's public key. Then:

1. Parse the document and confirm it has the published shape.
2. Rebuild the canonical bytes and hash them. The hash must match the one in the envelope.
3. Find the signature whose key id matches the public key you hold. No match means failure, not "unknown".
4. Verify the signature over those bytes with any ML-DSA-65 library.
5. Read the floors and check every count against them.

No account, no login, nothing from us. Change one digit anywhere and step two fails. The verification guide walks through the shape field by field.

On our own pages the check runs in the reader's browser and the result is one sentence: "Signature checks out. These numbers are exactly what the workspace published." Or "We couldn't verify this", followed by the reason.

What a signature can't hide, and can't tell you

It's worth being precise about the limits, because a signature is the kind of thing people over-read.

It can't hide a small group. The floors are the protection there, and they're inside the signature so they can't be weakened after the fact. But a signature doesn't make a group of five safe if you already know exactly who those five are. That's a property of arithmetic, not of cryptography, and the honest answer is that some breakdowns you'd like simply aren't in the document.

It can't tell you the survey was fair. It tells you the numbers weren't altered after the workspace published them. Whether the questions were leading, the audience was well chosen, or the timing was manipulative is not something bytes can attest.

It can't tell you a person clicked. When a poll closes, a browser that has already published once may republish on its own so the public link shows the final numbers. The signature attests the numbers, and that's all it ever attested.

It can't stand in for the encryption underneath. None of this would mean much if the vendor could read individual answers, because then the aggregate is just their word about what they read. Answers are encrypted in each respondent's browser and the aggregate is computed by someone the workspace gave a key to. The signature says this aggregate came from that workspace. The architecture says nobody, including us, saw the answers that went into it. You need both, and they're separate claims.

Why bother, if boards don't verify

Mostly they don't. Their security teams sometimes do, and a consultant who has been asked "where did this number come from" once will remember which supplier made the answer checkable. The value isn't in the checking. It's in being the result that could be checked, which changes how carefully everyone, including us, treats it.

FAQ

What does someone need to verify a result? The document's JSON and the workspace's public key. Both are served publicly for a published poll, and an admin can export the JSON as part of an evidence packet. Any ML-DSA-65 implementation does the check.

Is this a blockchain? No. It's an ordinary digital signature over a canonical document, with the public key published. There's no ledger and nothing is distributed.

Can InviziPoll sign a document on a workspace's behalf? No. The signing secret is created in the workspace's own browser and stored wrapped under a key our servers don't hold. That's the point: a document we could sign would be a claim about us.

What happens if the numbers were published unsigned? The page says so, in a sentence, and still shows the charts. The admin was warned before publishing. An unsigned document is a summary you're taking on the publisher's word, which is exactly what every other survey tool gives you by default.

Does the signature reveal anything about respondents? No. The document contains counts, cohort labels and floors. Groups below the floor aren't in it, and no written answer ever is.

How to verify a published document, or the consultant's view in Give the board results they can verify.