Threat model
What we designed against.
Anchor is built for people who may face serious consequences if their evidence is lost, accessed, or identified. These are the four threats the architecture addresses.
Threat
Phone seized during or after recording
Recordings are encrypted on the device before saving. The encryption key lives in platform secure storage controlled by the OS, not in the app's data directory. Seizing the device does not by itself grant access to the plaintext recording.
Threat
Server compromised or subject to legal demand
The server holds only ciphertext it cannot decrypt. No plaintext recording, no contact list, no user identity is stored at rest. A legal demand targeting the server can produce encrypted data, not recordings in plaintext.
Threat
Network interception during vault upload
Recording chunks are encrypted on the device before they leave it. Interception on the network produces ciphertext with no corresponding decryption capability on the server or in transit.
Threat
Unauthorized access to the device
Encryption keys are stored in the platform's secure storage (iOS Keychain, Android Keystore). Access to those stores is controlled by the OS and requires device authentication. Keys are not stored in the app's accessible data directory.
Recording pipeline
On-device recording and encryption
Encryption is the first step, not the last. A recording is never written to storage in plaintext at any point in its lifecycle.
Encrypted before saving
Every recording is encrypted with AES-256-GCM on the device before it is written to disk. Plaintext never touches the device's storage.
Per-incident keys, never reused
A fresh encryption key is generated for each recording. Keys are never reused across incidents. If one key were ever compromised, it would not expose any other recording.
Keys in platform secure storage
Encryption keys are stored in the iOS Keychain on Apple devices and the Android Keystore on Android. Access to those stores is controlled by the operating system. Keys are not stored in the app's accessible data directory.
Keys never leave the device
The key is generated on-device and stays there. The vault server receives only ciphertext. It has no access to your key and no means to decrypt your recordings.
Recordings stay in the 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 save them there.
Vault backup
Encrypted backup, end to end
Vault backup exists so that if your phone is taken before you can share your recording, the evidence may still be preserved. Your local recording is always the primary copy. The vault is the backup.
Encrypted before upload
When a connection is available, encrypted recording chunks begin uploading automatically as you record. Encryption happens on the device before the chunks leave it. The server receives only ciphertext.
The server cannot decrypt your recordings
Your encryption key never leaves your device. The storage server holds ciphertext and has no decryption capability. This is true for Anchor and for the underlying storage provider.
Best-effort, not guaranteed
If you are offline when recording, chunks queue locally and upload when a connection becomes available. If the phone is taken before any chunks upload, there is nothing in the vault yet. The local device recording is always the first and most important copy.
24-hour auto-delete
Encrypted backups are automatically deleted from Anchor's servers 24 hours after your recording ends by default. Your local recording is unaffected by this deletion.
The local recording is the primary copy.
Vault backup is best-effort. Framing it as anything else would be misleading. We built this to help you, not to overpromise.
Contact design
Zero-knowledge trusted contacts
Trusted contact phone numbers are sensitive. The server is not designed to store them in readable plaintext at rest.
Not stored in plaintext at rest
Contact phone numbers are encrypted to your public key on your device before they are stored. Your private key never leaves your device. The server holds only ciphertext it cannot decrypt.
Transient during delivery, then wiped
During the delivery of a safety alert, a decrypted contact list exists in server memory only for the duration of that send. Once the send completes, it is wiped. It is not written to persistent storage.
No account, no identity
Anchor requires no account for core use. We store no name, email address, or phone number linked to your identity. There is no profile to hand over.
Incident identifiers use a keyed hash
Incident identifiers stored on the server are keyed hashes. They are not reversible without a secret held server-side. An adversary with only the incident UUID from your device cannot confirm which server record corresponds to it.
Safety alerts
Alert delivery
Safety alerts notify trusted contacts when you need help. The design prioritizes reliable delivery while protecting both parties.
App notifications are always first
Safety alerts are sent as app (push) notifications first. This path does not depend on phone numbers or SMS carriers.
SMS is secondary and requires explicit opt-in from both sides
SMS delivery is optional and only activates when the user enables it and the trusted contact explicitly opts in. No SMS is sent to anyone who has not opted in.
Alert content never reveals what it is
The content of every alert - whether push notification or SMS - never hints at the nature of the underlying material. This is a safety property: a message that can be intercepted or seen on a lock screen must not reveal sensitive context.
Legal demands
What a legal demand can and cannot reach
The architecture determines this. Not our policies. Not our intentions. Here is the summary - the full breakdown is on our privacy page.
Can produce
- Encrypted recording ciphertext (undecryptable without your key)
- Keyed incident identifiers (not reversible without server secret)
- Device push tokens
- Vault link metadata (expiry, access status)
Cannot produce
- Recordings in plaintext
- Trusted contact phone numbers in plaintext
- User identity in the form of account data, because Anchor does not require an account for core use
- Location
Design decisions
Deliberate choices
Security is often about what you choose not to build. These decisions were made deliberately and are not subject to later “opt-in” or feature flags.
We deliberately chose not to build
- Analytics or attribution SDKs
- Advertising or cross-app identifiers
- Session replay tools
- An account system (no name, email, or password required)
- Contact list harvesting
- Location embedded in recording metadata by default
- Biometric recognition of any kind
We deliberately built
- Quick exit: one tap to a neutral screen, recording preserved
- Per-incident key isolation: one key per recording, no reuse
- Offline-first core: essential features work without internet
- English and Spanish parity on all core screens
- No trace of recording in the Photos library unless you choose it
Security research
Responsible disclosure
If you find a security vulnerability in Anchor, please contact us before publishing. We take reports seriously and will respond promptly.
This app is used by people in high-stakes situations. Responsible disclosure is meaningful here.
security@goanchor.appPrivacy architecture
Want the full privacy breakdown?
Our privacy page covers the complete legal demand table, honest data inventory, on-device protections, and what this website does and does not collect.
Read the full privacy architecture