Trust Model
What do you need to trust?
Every storage system has a trust model. Use this page to see what Rabbithole removes from the trust path and what you still need to trust.
File contents are encrypted in your browser before upload. Rabbithole, storage infrastructure, and node operators do not receive the readable file.
Privacy and availability are separate properties. Encryption protects file contents. Availability depends on the storage mode, cycle balance, and, for Blob Storage, retention rules of the external storage layer.
If TEE support is available on the relevant IC subnet, it can improve runtime isolation. Treat it as an additional hardening layer, not as Rabbithole's primary privacy guarantee.
You do NOT need to trust
- Rabbithole team — we never see plaintext file contents
- ICP node operators — they process encrypted blobs
- Network infrastructure — encryption happens before data touches the network
You DO need to trust
- The encryption code — it's open source, audit it yourself
- Your browser — the encryption runs in your browser's JavaScript engine
- Internet Identity — for authentication (also open source)
- ICP consensus — that the network correctly executes canister code
Threat model
First, separate the properties. Encryption protects file contents, access control decides who may request the file and key, and integrity verification helps detect byte replacement. The table below avoids a single protected/not protected label and shows the boundary instead: how protection works and what remains a separate responsibility.
Rabbithole vs Traditional Cloud
Comparison with other solutions
Rabbithole reduces trust assumptions, but it does not remove them entirely. If you find a weakness, report it.