Reference
Threat model
Security depends on who the attacker is, which secrets they obtain and when, and which traffic they can observe or suppress. This page makes those conditions explicit.
Assets and trust boundaries
The protected assets include conversation content, endpoint identity keys, live session state and local history. Relationship metadata, availability and authentic first contact are separate goals with different residual risks. Verifying a signing key establishes possession under cryptographic assumptions; binding that key to a person requires a trusted introduction or independent safety-number comparison.
The service, network, relay and peer are separate observers. Apple also participates through device security, notifications and optional cloud captions. See the observer ledger for fields rather than a blanket “zero metadata” statement.
Attacker cases
| Attacker | Mechanism | Remaining exposure |
|---|---|---|
| Passive network observer | TLS, inner transport, E2E messages and frame encryption | IP addresses, connection timing, traffic sizes, call-shaped flows and endpoint reachability. Padding reduces precision; it does not make traffic indistinguishable. |
| Malicious service operator | Peer signatures, pinned identities, authenticated ciphertext and capability-controlled routes | Directory substitution at unverified first contact, routing edges, denial of service, correlation and future changes to logging. No service can promise delivery through an operator dropping every packet. |
| Malicious front or relay | Inner transport protects bytes forwarded to the backend; media has endpoint frame encryption | Addresses, timing and traffic shape; selective interruption. A privately shared relay can still be discovered by scanning or other observation. |
| Snapshot of endpoint state | Key evolution, erasure attempts and newly generated secret inputs | Compromised current and retained keys. Healing requires the attacker to lose continuing access and the protocol to incorporate fresh, unexposed material. |
| Lost or seized phone | iOS data protection and separately configurable history factors | Protection varies with lock state, factors and extraction capability. Operational state is intentionally more available than protected history. |
| Malicious contact | Input validation, authentication, blocking and local controls | The contact already has plaintext and can record or redistribute it. Expiry and unsend cannot undo that. |
| Active quantum-capable attacker | ML-KEM and ML-DSA participate in versioned hybrid mechanisms | Named computational assumptions, identity bootstrapping, implementation and composition remain essential. Primitive selection is not a full-system theorem. |
Compromise timing changes the question
Forward secrecy asks about older messages after a later compromise. Post-compromise security asks about later messages after an earlier compromise ends. Those are different directions in time. Retained skipped keys intentionally extend exposure to some past positions; a fresh encapsulation to a private key already stolen does not by itself restore post-quantum secrecy.
A live attacker controlling an unlocked endpoint may read the screen, capture audio and export keys. Auris does not claim to protect plaintext from the endpoint that is actively using it.
Settings change particular exposures
Relay-only calling changes which network parties see the peer’s address. Invite-only discovery gates lookup but leaves the account’s directory row at the service. History protection changes key release; the app screen lock alone does not seal all background state. Lockdown omits anonymous-queue wake tokens, but ordinary account registration still carries available push tokens in the reviewed source.
Read the exact preset table, notification behavior and storage policies before relying on a setting for a particular threat.
Assurance boundary
The beta has implementation tests, executable models and narrow research results. It has no independent product audit, no complete traffic-analysis bound and no proof of the entire stack. The claims ledger records those limits; the version record identifies what this September 5 review actually checked.
Reviewed · Review scope and versions