The Overview and Goals chapter explained what Rhizo is and how the app is organized.
This chapter talks about security and threats: what needs protecting, why security matters, and lists potential threats to the app and its data, either from intentional attacks or honest mistakes (e.g., losing a device).
It outlines what we can and can’t protect against, while the Open Questions chapter looks at the best ways to mitigate remaining risks.
Why Rhizo is serious about security and encryption
Some software vendors claim their apps use “military grade encryption”, which sounds impressive to those who don’t know any better but means little unless backed up by evidence. It could mean something as basic as only providing TLS.
Others will even go as far as claim end-to-end encryption, but consider their server as one of the ends where protection stops. That still leaves your information in plain text (unencrypted) on the server, meaning it can be accessed by anyone with access to the database that stores it.
We believe that in today’s world can means it will be accessed by someone, with or without your informed consent; either to train data models, mined for marketing purposes, or worse. This, combined with the belief that privacy is required for democracy is one of the main reasons why we created Rhizo.
In developing Rhizo, we talked to people and groups from all walks of life who feel they can no longer trust services with their data, and think twice (or more) about what they sign up for. For some, the threat of data or devices falling into the wrong hands is not theoretical.
What needs protecting
We protect communication and knowledge, as well as the metadata around it.
Organizing and running a group democratically involves hashing out things that groups want to keep private.
For a group organizing platform, that means:
- Membership data: organization size, individual identities, locations, join/leave dates, etc.
- Deliberation: discussions, votes, polls, decisions, meeting notes, strategic plans.
- Generated knowledge: documents, outputs, anything the group produces.
- Financial data: who pays for membership, how much, where funds move.
- Communications and their output: a conversation is communication in the moment, but the moment it’s stored and searchable it becomes knowledge and needs protecting.
This list is not comprehensive and used only to illustrate the kind of data important to our users.
Threat model
A threat is anything that could potentially harm the app’s functionality, or the data it holds and exchanges.
A threat model is a structured representation of potential threats and vulnerabilities that could affect Rhizo and its users.
People and organizations we talked to while developing Rhizo need to protect from a variety of factors:
| Actor | What they might want and can do |
|---|---|
| Corporate surveillance | Reading discussions never meant for an employer (e.g. unfair practices). |
| Opposing legal counsel | Uncover group strategy before the group is ready to reveal it. |
| Members (non-adversarial) | Lost/stolen devices, forgotten passwords, accidental destruction of devices (e.g., water damage). |
| Internal bad actors or infiltrators | Legitimate access used to exfiltrate data, impersonate members, or steer/sabotage the group from inside. |
| State actors | Mass state surveillance of lawful activity; physical device seizure and forensic extraction; arrest and coercion to unlock devices. |
| Any of the above | Physical destruction of infrastructure (e.g. the hardware that runs the server). |
Mitigation strategies
Coming soon.
Work in progress
This section is still work in progres and will later describe primary mitigation stragegies.
Core security principles
Every technical design choice we make relates to either our user experience goals or the threat model described above.
One of our big user experience goals is for Rhizo to be usable and reliable for people of all technical backgrounds. This means decisions related to end-to-end encryption should not get in people’s way. End-to-end encrypted apps are fundamentally different. But ideally, users shouldn’t notice or be too disrupted by these aspects more than necessary compared to other apps they’re used to.
There are 3 core security principles:
- The application and server should be easy to set up and use in a way that won’t compromise security.
- Everything that leaves the client and/or is stored on the disk must be encrypted.
- We do not store any data that isn’t strictly necessary for the application to perform its function.