Joripo- Home
- Documentation
- Security and privacy
- Known gaps and what is unverified
Security and privacy
Known gaps and what is unverified
The open security and privacy gaps, stated plainly, and the parts of Joripo that have been built and tested but not yet proven in production.
Joripo documentation · https://joripo.com/docs/security-and-privacy/known-gaps
On this page
Joripo's rule is to say what is true. This page lists what is known to be weak or not yet proven, so you can decide with it in front of you. Read it before fielding a study on real respondents.
Open gaps
| Gap | What it means | What to do |
|---|---|---|
| Encryption at rest is off until the server's data key is set | On a server without the key, collected data is stored unencrypted on its disk. | Ask whoever runs the server; check Server health. |
| Form media are not sealed | Preload CSV files and other form attachments are readable on the server's disk, because every phone receives them. | Keep preloads to the columns a form needs. |
| Phones protect unsent interviews with Android's encryption, not the app's own key | A rooted phone could expose interviews not yet sent. | Send promptly; manage phones; revoke lost ones. |
| Joripo Desktop's study folders are ordinary files | Anyone with the computer can read the copy. | Use an encrypted disk and a computer only you use. |
| Garbling: a late respondent added to a running scheme | The way late respondents extend a roster's key can, for a lone newcomer in a block, weaken deniability. How to change it is a statistical design decision still open. | Avoid adding a single late respondent to a block on their own. |
| No email for password resets or notifications | Reset requests go to the organisation's owners, who pass a new password on directly. | Agree how passwords are passed on. |
Built and tested, not yet proven in production
- The newest database paths (the sealed answers column, the database-held lockout counts, savepoints, the review index) are verified on the test database (SQLite). Production runs Postgres, and those paths have not all been run on it yet.
- Joripo Collect releases after 2.0.0 have been run on the Android emulator only, not yet on a physical phone.
- Field monitoring's SurveyCTO and Google Sheets connections are tested against copies of those services' protocols, not against live accounts.
- Backups and Review and correct were built and tested on the test database; their first run on a production server is still to be watched.
- Restoring a backup on a hosted server (rather than on a machine you control) has not been exercised.
Gaps since fixed
Some past gaps, for the record:
- Database upgrades are now named, recorded steps; a failed one stops the server from starting rather than leaving it serving a half-upgraded database.
- The case list's lock now holds across server processes, so two processes can never write it at once.
- Joripo Collect from release 2.0 removes a garbled form's answers from the phone once the server has them.
Reporting a problem
Tell your server's administrator. For Joripo itself, report it privately to the Joripo team through the contact page, not in a public place, and do not include exploit details in public.