Can anyone access my recordings other than me?

No. Your recordings are encrypted with AES-256-GCM on your device before they are saved or uploaded. The encryption key is stored in your device's secure storage (iOS Keychain or Android Keystore) and never leaves your device. Anchor's servers receive only ciphertext and have no means to decrypt it.

What happens to my recordings if my phone is seized?

Your recordings are encrypted on-device. Seizing the phone does not give access to the plaintext recording without the encryption key, which is in platform secure storage controlled by the OS. If you had already recorded and the vault backup began, encrypted chunks may be preserved on the server in ciphertext the server cannot decrypt.

What can Anchor produce if served with a legal demand?

We can produce: encrypted recording ciphertext (undecryptable without your key), keyed incident identifiers, device push tokens, and vault link metadata. We cannot produce: recordings in plaintext, your contact list in plaintext, your identity, or your location. The architecture determines this, not our policies.

How do I report a security vulnerability?

Email security@goanchor.app. Please contact us before publishing so we can review and respond. This app is used by people in high-stakes situations and responsible disclosure is meaningful here.

Safe, secure, and private.

Everything in Anchor is designed to keep your evidence protected. Your recordings are encrypted before they leave your device. We never see the key.

Encrypted on deviceAES-256-GCM before save or upload

Zero-knowledge serverWe receive ciphertext only

App-only trusted accessNo web link, no code in SMS

How we protect your evidence

Three architectural truths. The design makes the outcome.

Encryption on your device

Recordings are encrypted with AES-256-GCM before save or upload. The key stays in your device secure storage (Keychain or Keystore). We receive ciphertext only. We cannot decrypt it.

Plaintext never leaves your control.

Server stores only ciphertext

No server-held decryption keys for recordings or contact data. Compromise of our storage does not yield plaintext.

We do not have your keys.

Trusted contacts: app-only

No web link, no code in a message. The recipient proves device key control to access evidence. We do not send decryptable links; we do not store the keys that would make them work.

Evidence only in the app.

What exists in server reach and what we do not have

Clear boundaries. We hold only what we cannot decrypt or use to identify you.

What exists in server reach

Encrypted blobs
Keyed identifiers
Push tokens
Limited metadata

What we do not have

Plaintext recordings
Plaintext contact numbers or lists
Invite secrets
Recovery keys
Plaintext evidence keys

Trusted contacts: app-only, key-bound

Evidence stays in the app. No web link, no code in a message.

Invite

Invite via link and QR only.

The server never stores the invite secret.

Bind

The recipient proves device key control.

No web viewer; no 6-digit code in the confidentiality boundary.

Access

Evidence viewing is in-app only.

No vault link or code sent in SMS.

Recovery and revocation

You hold the keys. We hold only what we cannot open.

Recovery

Recovery uses a key you hold. We store only an encrypted envelope. We cannot decrypt it.

Revocation

Revocation stops future access (new envelopes, URL refresh). We cannot claw back already-exported plaintext. We say so clearly.

Legal demand and compulsion

If we are compelled to hand over data, the architecture determines what exists.

Can produce

Encrypted recording ciphertext (undecryptable without your key)
Keyed incident identifiers
Device push tokens
Vault link metadata

Cannot produce

Recordings in plaintext
Trusted contact phone numbers in plaintext
Contact list in plaintext
Invite secret
Recovery key or plaintext evidence key

The architecture makes this impossible, not policy.

See the full breakdown on our privacy page

What we defend against

Our architecture is built to resist these threats. No policy promises: the design makes the outcome.

Server compromise

No decryption keys on server; ciphertext-only.

Compromise does not yield plaintext.

IDOR / BOLA

Upload token binds to incident; identity must match.

Only the incident owner gets upload and access.

Token guessing

Strong random token; timing-safe comparison.

Guessing is not feasible.

Trusted Contact impersonation

Recipient proves device key control; no web viewer.

Evidence only in the app.

Invite hijack

Invite secret in link fragment only; server never stores it.

Accept fails without the fragment.

Operational controls

How we run the system: logging, notifications, access.

Logging: We do not log incident IDs, signed URLs, tokens, key material, phone numbers, or decrypted bytes.
Notifications: No content hints in SMS or push (no "video", "recording", or similar).
Access: Identity-bound; sessions are short-lived.

Common questions

Privacy and security

No. Your recordings are encrypted with AES-256-GCM on your device before they are uploaded. The encryption key is generated on your device and stored in your device's secure enclave, iOS Keychain or Android Keystore. The key never leaves your device.

Anchor receives only ciphertext, meaning encrypted data we have no means to decrypt. This is a technical constraint, not a policy promise. The architecture makes it impossible for us to read your recordings.

See our Privacy and Security page for the full architecture.

Under a valid legal demand, we can produce only what we have. What we have is encrypted recording chunks we cannot decrypt, HMAC-keyed incident identifiers we cannot reverse to your identity, device push tokens, and vault access link metadata.

We cannot produce your recordings in plaintext, your contact list or phone numbers, your identity, or your location. The architecture determines this. It is a technical limitation, not a policy choice.

This describes what our architecture makes technically impossible. It is not a guarantee about every legal process or outcome.

See the full architecture .

No. Anchor contains no analytics SDKs, no advertising identifiers, no session replay tools, no attribution trackers, and no third-party tracking of any kind, in the app or on this website.

The same privacy standard that governs the app governs this site.

No. Anchor does not access, harvest, or import your device contact list. You manually enter the information for your trusted contacts within the app.

Contact phone numbers are encrypted to your public key on your device before they are stored. We cannot decrypt them.

Encrypted vault backup data is automatically deleted from Anchor's servers 24 hours after your recording ends. This happens automatically. You do not need to request it.

Your local recording on your device is not affected by vault deletion and remains until you choose to delete it.

Anchor generates a unique encryption key for each recording. A key for one incident does not protect any other recording.

If one key were ever compromised, it would expose only that recording, not your entire history. Keys are stored in your device's secure enclave, iOS Keychain or Android Keystore, and never leave your device.

This is not a policy preference. This is a constraint of the architecture.

Read the full privacy architecture