Zero-knowledge architecture
Three kinds of sensitive data our architecture is designed not to keep in plaintext at rest.
The following is a description of what our architecture makes technically impossible to produce at rest.
Your recordings in plaintext
Recordings are encrypted with AES-256-GCM before they leave your device. The key is generated on your device and stored in the iOS Keychain or Android Keystore.
The key never leaves your device. We receive only ciphertext. We have no means to decrypt it.
Your trusted contacts' phone numbers
Contact phone numbers are not stored in plaintext at rest. They are encrypted to your public key on your device before they are stored. Your private key never leaves your device.
During live delivery, a decrypted send list exists transiently in server memory, then is wiped. At rest, we can produce only encrypted blobs that reveal nothing without your private key.
A link between your account and an incident
Anchor requires no account and stores no name, email, or phone number for core use. Incident identifiers stored in our database are HMAC-SHA256 values keyed to a secret we hold.
Even with the incident UUID from your device, an adversary cannot verify which row in our database corresponds to it without the HMAC key.
Honest inventory
What we actually store
Honesty about what we store is a trust signal, not a weakness. Here is the full picture.
What we store
- Encrypted recording chunks (ciphertext only - we cannot decrypt)
- Device push tokens for safety alerts (not linked to your identity)
- HMAC-keyed incident identifiers (not reversible without our key)
- Vault access link metadata (expiry time, whether accessed)
What we do not store
- Your name, email address, or account credentials (no account required)
- Your phone number or contact list in plaintext
- Your location
- Any identifier that links your device to your identity
- Analytics, session data, or usage patterns
What happens on your device
Recordings stored in your app sandbox
Recordings are saved inside the app's private sandbox, not in your Photos library. They are not visible to other apps and do not appear in iCloud or Google Photos unless you explicitly choose to save them.
Per-incident encryption keys
Each recording uses a unique encryption key. A key for one incident does not protect another. If one key were ever compromised, it would not expose any other recording.
Quick exit
One tap returns you to a neutral screen without deleting your recordings. Your evidence is preserved, and your screen shows nothing sensitive.
No location in video metadata
Location is not embedded in recording metadata by default. Your GPS coordinates do not travel with your evidence unless you explicitly enable that.
How vault backup works
Vault backup exists for one reason: if your phone is taken before you can share your recording, the evidence is already safe. Your recording is always saved locally first. The vault is the backup.
Vault backup is best-effort. When you are online, encrypted chunks upload automatically as you record. When you are offline, they queue and upload when you reconnect.
We use Cloudflare R2 for storage. Cloudflare receives only encrypted chunks. They cannot decrypt them either.
Default retention: 24 hours
Encrypted vault backups are automatically deleted from Anchor's servers 24 hours after your recording ends. A future upgrade option may allow extending this to 7 days per incident. Your local recording is unaffected.
Legal demands
If we receive a legal demand
Here is exactly what a legal demand targeting Anchor can and cannot produce. The architecture determines this, not our policies.
We will publish a transparency report if we receive a legal demand that we are permitted to disclose.
This website follows the same privacy-first standard
The same privacy standard that governs the app governs this website.
- No analytics SDKs (no Google Analytics, no Mixpanel, no Amplitude)
- No advertising pixels or attribution trackers
- No third-party scripts
- No session replay tools
- No cookies beyond what the web server requires to serve the page
Privacy impact assessments, on record
We run a formal privacy impact assessment (PIA) process for every change that touches data storage, encryption, or identity. Each review is documented and logged internally. Our PIA records cover a full data map of every store in the backend, a subpoena simulation showing what each store produces under compulsion, and a threat model. No new data store can be merged without a completed review.
Questions or concerns
If you are a security researcher, journalist, NGO evaluator, or attorney who wants to verify the architecture in depth, reach out directly.
security@goanchor.appGeneral information only, not legal advice. Anchor is not a substitute for emergency services.