THREAT MODEL · TELLS

tells · threat model

What we defend against — and the four classes of threat we do not pretend to.

Effective date: 2 May 2026 · Version 1.0 · Pair with Data flow + Privacy Policy

The honest line. A privacy claim is only credible if it names the threats it addresses, the threats it doesn't, and the controls that map to each. This page does that. It is the public counterpart to our internal security checklist.

1. Threats addressed

Each row below is a defined adversarial scenario plus the specific control tells implements to mitigate it. Controls are auditable — see the tells-encryption-spec repo for the underlying primitives.

Threat	Mitigation
Database leak (SQL injection / direct dump)	All sensitive fields are encrypted at rest with AES-256-GCM. The master key is held outside the database (env var only). A leaked dump alone is opaque ciphertext.
Server compromise (root access via vulnerability)	Master key lives in a separate environment-variable scope from the DB process. An attacker needs both the DB and the running process's environment to read user content.
Insider threat (malicious developer)	Production DB access is audited. Engineers do not read raw user content — encrypted fields are opaque without per-user HKDF-derived keys + AAD context. Code review is required for any path that decrypts user payloads.
Sub-processor compromise (tells AI v1.0 inference layer leak)	Enterprise data terms with the inference sub-processor (named in the sub-processor list) apply: customer data is not used for model training, no cross-tenant retention. Per-user rate limits prevent enumeration.
Backup theft	Backups are encrypted with a key separate from the production master key. Compromise of one key does not compromise the other.
Crisis-response data subpoena	Default 90-day hard-purge means most data is not subpoenable. Encryption-at-rest means law enforcement would need both the database and the key custodian to compel disclosure.
GDPR Article 17 erasure requests	One-click "delete my account" flow performs cryptographic deletion: the per-user HKDF salt (the user UUID itself) is destroyed, rendering any retained ciphertext unrecoverable. An audit-log entry records the deletion timestamp + a non-reversible proof fingerprint.
Cross-user data leakage	Primary keys are UUIDs (no enumeration). Per-user encryption keys are HKDF-derived from the user UUID. AAD (Additional Authenticated Data) binds every ciphertext to `(user_id, tracked_person_id, created_at)` — re-pointing a row to another user fails the GCM auth check.

2. Threats explicitly NOT addressed

We do not claim to defend against the following. If your threat model includes any of them, tells is not the right tool.

Out of scope for v1

Government-level adversaries (NSA-class actors). Nation-state offensive cyber capabilities exceed what a small studio can credibly defend against. We do not market tells to journalists, dissidents, or activists who require that level of guarantee.
Compromise of the inference sub-processor at provider level. If the sub-processor's infrastructure (named in /legal/sub-processors.html) is breached, content sent for analysis during that window is exposed. Our control here is selection and contractual: enterprise data terms apply.
Side-channel attacks on inference-layer response timing. A network-level adversary observing request/response timing patterns may infer coarse properties of analyses. We do not defend against this class.
Hardware-level extraction of the master key from the VPS. Physical access to the server, RAM forensics, or hypervisor compromise of the hosting provider would yield the master key. We rely on the hosting provider's physical and hypervisor security.

3. Encryption summary

The encryption primitives used to mitigate the threats above:

Algorithm: AES-256-GCM (authenticated encryption).
Key derivation: per-user 32-byte key via HKDF-SHA256 from the master encryption key + user UUID (salt).
Master key: stored in MASTER_ENCRYPTION_KEY env var only. Never in the database. Never in the repository. Rotatable on a 90-day schedule via a re-encryption job.
AAD: every ciphertext binds user_id + tracked_person_id + created_at. Tampering with any of these fails the auth check on read.
Nonce: 12 bytes random per encryption operation (never reused under the same key).

4. Audit path

Within 90 days of public launch we engage an external freelance security auditor to verify each claim above against the running implementation. The audit report will be published at tells.voiddo.com/legal/audit-2026.html. Subsequent annual audits maintain the trust signal.

5. Reporting

If you find an issue not addressed by this model, contact support@voiddo.com. We acknowledge within 48 hours and disclose any material change to this page within 14 days.