Garbling sensitive questions

Garbling protects the answers to sensitive yes/no questions (harassment, theft, illegal work). For a set share of respondents, chosen at random, a "No" is recorded as "Yes". A recorded Yes therefore never proves that a person said Yes, yet the share answering Yes can still be estimated for the whole sample and for groups. A recorded No is always a true No. Garbling is set up per form, on the workspace's Garbling page (managers and owners see it; only an owner changes it).

How it works

Each respondent is assigned (or not) for each garbled question. When a submission arrives, Joripo applies one rule: an assigned respondent's No is recorded as Yes; a Yes stays Yes; a missing answer stays missing. Being assigned is not the same as being changed: only an assigned No changes. The rate r (for example 1/5) is the share assigned.

The assignment is made on the server from a secret seed, sealed, and never shown on any page, export or log. Only a key custodian (an explicit permission, given on the Garbling page) can open the vault.

IID or block

• IID garbling: each answer is assigned on its own, with probability r: the same chance for everyone, independent of everyone else. The share assigned varies by chance, overall and in every subgroup. It needs no roster and no blocks; blocks you choose only group the report ("subgroups for reporting only").
• Block garbling: exactly the share r is assigned within each block of the variables you choose (for example factory and gender), so no block ends up with nobody or everybody assigned by chance. Choose when the assignment is made:
• From a roster before fieldwork: each block gets a quota of its roster size times r, rounded by the rule you choose (round up, round half up, round down, or exact total, which keeps the overall total at r of the roster).
• In interview order: exactly k of every L interviews in each block are assigned, as submissions arrive (for a rate of 1/5, 2 of every 10). This needs no roster; the block values can come from the form's own questions. It automates the "k of every L consecutive reports" protocol.

Small blocks protect little: in a block where nobody is assigned, every recorded Yes is true. The plan warns about blocks smaller than the minimum block size, and the report never shows their assignment share.

Answer capture

• Direct (recommended): the enumerator asks and records the question as usual. Joripo garbles the answer when the submission arrives, so nothing about garbling is on the phone. You tick the questions to garble and check how their answers are read: which choice means Yes, which No, and which are nonresponse ("Missing", such as refused or don't know: kept as answered, never garbled). Joripo suggests a coding from the choice list; you must confirm it ("I have checked this coding") before freezing.
• Token sheet: the enumerator types a code from a sheet the form pulls in (pulldata); Joripo decodes the code and garbles it on arrival. Add question adds a garbled question: pick the question the code is typed into, and Joripo fills in its yes- and no-token calculates, its re-entry field and its slot from the form's token pattern (you can change any of them). Fill in all … questions the form garbles adds every one at once. The enumerator sheet and the roster columns it carries are picked from what the form pulls with pulldata. Token sheets are made per respondent, so this design always needs a roster. Its question list offers only number and text fields (the box the code is typed into): to garble yes/no questions the enumerator answers normally, choose Direct.

A new scheme starts on IID garbling with direct capture, which needs no roster, so the form's yes/no questions are listed to tick straight away. A form already built for a token sheet (calculates pulling <slot>_yes_token and <slot>_no_token) starts on block garbling with token sheets instead, its garbled questions filled in from the pattern.

With direct capture, any other field that uses the raw answer (in a relevance, a calculation, a constraint or a label) would reveal it: the form check reports it as an error.

Assignment across outcomes

• Separate (recommended): an independent assignment for each garbled question. A recorded No to one question says nothing about the others.
• Shared: one assignment per respondent, applied to every question. Anyone with a recorded No to any question is then provably unassigned, so their recorded Yeses are true.

Respondents and blocks

The respondent ID field identifies a person across submissions (a re-sent or repeated interview keeps its assignment). With IID garbling and direct capture you may choose instanceID: each submission is then its own respondent.

The roster lists the people the scheme covers, with their ID and block columns, and is stored encrypted. It is required for block garbling from a roster and for token sheets, and optional otherwise. Block variables are picked from a list: the roster's columns (with how many different values each has) once it is uploaded; before that, or in interview order without a roster, the form's questions. The order you add them numbers the blocks. An empty block value is refused, excluded (no assignment, answers left blank and flagged) or made its own "(missing)" block, as you choose.

Before a roster is uploaded, its ID column is picked from the column the form's pulldata looks the respondent ID up by, or from the form's fields (Another name… for any other). The ID pattern is optional: every roster ID must match it. Joripo fills it in from the ID field's own regex() constraint, or from the roster's IDs once it is uploaded (only their shape, such as ^F[0-9]{3}_R[FM][0-9]{4}$, never an ID); you can also pick a ready-made one or write your own.

Without a roster

• IID garbling with direct capture needs nothing in advance. Each respondent is assigned with probability r when their submission arrives. The respondent ID is a field of the form, or instanceID if every submission is its own respondent.
• Block garbling in interview order with direct capture needs no roster either. Each respondent's block comes from the form's questions (for example factory and gender), and in every block exactly k of each L interviews are assigned as they arrive.
• Block garbling from a roster and token sheets cannot work without one: a quota is a share of a known list, and tokens are made per person in advance.

Protection

• Hard (recommended): the original answers are never stored. Not even a key custodian can learn what a respondent said.
• Faithful: the original answers are kept encrypted so that a key custodian can decode them, as the pilot's decode script did. Destroying the key deletes them.

Fields removed at ingestion are deleted from every stored submission as it arrives. Pick them from the form's fields; a name ending in * removes every field that starts with it, and Joripo offers one for fields that share a prefix (rand* for rand1, rand2, ...).

Review, test and freeze

While the scheme is a draft, Review before freezing lists what is still missing, the form check, the block plan (for each block: its size n, the target r × n, the quota, the share it gives and the deviation from r), the coding of every garbled question and the totals. Test the design before fieldwork: a test run uses its own seed and changes nothing in the scheme. Freeze fixes the design; from then on every submission of the form is garbled as it arrives.

The report

The report shows the design, the plan against what was achieved, and for each question the share recorded Yes and two estimates of the share answering Yes, with standard errors:

• the naive estimate, (m − r) / (1 − r), which assumes exactly the rate r was assigned;
• the known-share estimate, (m − f) / (1 − f), which uses the share f actually assigned among the respondents (the same as the share of Yes among the unassigned).

Every estimate assumes that the assignment is independent of the true answer (it is, by construction), that nobody falsely reports Yes, and that the coding is right. It is an estimated share answering Yes, not a true prevalence. While a scheme is frozen, numbers that depend on who was assigned are shown only to key custodians: comparing two reports around one submission would otherwise reveal that person's assignment. They are shown to everyone once the scheme is closed.