How garbling works

The rule

For each garbled question, every respondent is either assigned or not, at random, with a set rate r (for example 1 in 5). When a submission arrives, Joripo applies one rule:

• an assigned respondent's No is recorded as Yes;
• a Yes stays Yes;
• a missing answer, or a nonresponse such as "refused" or "don't know", stays as it is.

Being assigned is not the same as being changed: only an assigned No changes. So a recorded No is always a true No, and a recorded Yes never proves that the person said Yes. Across the sample, though, the rate is known, so the share who truly answered Yes can be estimated.

A worked example

Of 1,000 respondents, 200 truly answer Yes. With r = 1/5, about 160 of the 800 who said No are assigned and recorded as Yes, so about 360 Yes are recorded. Knowing r, the estimate (0.36 − 0.2) / (1 − 0.2) = 0.20 recovers the true share, while for any one recorded Yes there is a real chance it was a No.

What is kept secret

The assignment is made on the server from a secret seed, sealed, and never shown on any page, export or log. The garbled answers are what is stored with the submission and what everyone who can see the data sees.

• Key custodians, named per workspace by an owner (an owner, a manager or a reviewer can be one, and an owner only when named), are the only people who can open the scheme's vault: the key (who was assigned), the roster, and in faithful mode the original answers. Every grant, every look into the vault and every refused attempt is recorded.
• Report numbers that depend on who was assigned are shown only to key custodians while the scheme is running, because comparing two reports taken around one submission would reveal that respondent's assignment. Everyone else sees them once the scheme is closed.
• The server's maintainer has no way into the vault.
• The vault's encryption key is never stored: it is derived from the server's secret key together with the workspace's own key material. A copy of the database alone opens nothing.

Never change the server's SECRET_KEY once a garbling scheme exists. The vault is sealed with it; a different one makes every key, roster and kept answer unreadable, and new submissions would be stored with blank garbled answers and flagged. Joripo refuses to create a scheme on a server without a fixed secret key.

What garbling does not protect

• The interview itself. The enumerator hears the answer. Garbling protects the record, not the conversation.
• The phone, until the form is sent. With direct capture the phone holds the plain answer until the server has the form; Joripo Collect (from release 2.0) then removes it from the phone. With ODK Collect, set it to delete sent forms.
• Other fields that use the answer. Anything that reads the raw answer (a relevance, a calculation, a constraint or a label) would reveal it; the form check reports it as an error. Do not record an audio audit over the garbled questions.
• Small groups. In a block where nobody is assigned, every recorded Yes is true, and a block with a known quota reveals that at least some of its Yeses are true. Keep blocks large, or use IID garbling, when groups are small.

Garbled questions cannot be inside a repeat group, and a form has at most one active scheme. While a scheme governs a form, a new version of the form that drops one of the fields the scheme needs is refused at deploy.