S3ntiment

We don't build a respondent database. Email addresses aren't stored anywhere, and no table exists that connects an answer to a person. What can't be stolen in a break-in is exactly that connection, because it was never made.

A stolen survey answer is worth almost nothing on its own; what makes a breach damaging is the connection attached to it, that this answer belongs to this person. Most survey platforms record that connection somewhere, in a participant list or an email field or a respondent ID, and then secure it as well as they can. That works until it doesn't, and it's precisely that dependency we were unwilling to accept.

The chain determines the risk, not your security

An organisation hands customer data to a research agency, that agency works with software from a vendor, and the vendor keeps everything on its own servers. Whoever gets hit in a break-in is therefore rarely the one who made the mistake. Survey software also rarely sits at the top of anyone's security priorities, and that's exactly what makes it an attractive target for anyone after personal data.

Afterwards came the question that should have been asked beforehand: why was a research agency holding data traceable to individuals at all? Had that connection not existed, nothing would have happened. That's the premise S3ntiment is built on.

We need your address once, then never again

Sending invitations requires a list of addresses, and we use one, once, to send the invitation. After that it ends: the address isn't stored with the survey but converted into an anonymous key.

The maths only runs one way

You prove that you control your email address, and a cryptographic key is derived from it using a technique called an oblivious pseudorandom function. That derivation only works in one direction: the same address always produces the same key, so you can find your answers again as long as you can reach your mail, while the address can't be recovered from the key. What we store is that key, and nothing else.

Recognisable over time, never identifiable

That same key produces the same result on every visit, and functions as an account with no name attached. Respondents can find their own answers, change them or delete them, and can use the same key to take part in a later survey, so developments over time remain visible. What you get is what a respondent ID normally gives you, recognition and continuity and a series rather than isolated snapshots, without anything anywhere recording who that respondent is.

Delete the list. Nothing breaks.

Because the key doesn't lead back to the address, the original list serves no purpose after sending. You can delete it, or keep it where it belongs, with the organiser and outside the survey platform entirely. The survey works either way, and the patterns in the data remain just as usable; only the route back to a person doesn't exist. A break-in at our end therefore yields answers without people, and a break-in at the organiser's end yields at most a list of addresses that says nothing about what was answered. The two halves are never brought together in one place.

There is no version of this where we can look

Every respondent has their own key, and beyond that nothing exists: no second key that opens all the answers at once, no administrator account with wider rights, no back door for exceptional cases. That isn't a house rule we've imposed on ourselves, but a consequence of where the data sits. We don't run on our own servers, but on Nillion, a decentralised network in which independent parties each do part of the work and no one runs the whole. There is therefore no party that can be pressured: a legal order to hand over respondent data is one that nobody can comply with, not S3ntiment and not the organiser. The code that enforces this is open source and independently verifiable, so you don't have to take our word for it.

Compliance you don't have to organise

That architecture has a side effect you don't have to organise. The GDPR requires data minimisation, security and breach notification, and at S3ntiment the first follows directly from the setup: there is no personal data to process, to secure or to leak. Not because the law is being circumvented, but because nothing remains for the law to act on.