Security & encryption model
AChat's security comes from optional, client-side end-to-end encryption: a password derives an AES-GCM key in your browser (via PBKDF2) that the server never sees. This page is the honest threat model — what is protected, and just as importantly, what is not.
What is protected (passworded chats)
- Message bodies are AES-GCM ciphertext; the server stores only
{ ciphertext, iv }. - File metadata (name, FilesHub URL) is encrypted client-side.
- The key never leaves your device — it is derived in-memory from your password + a per-chat salt and is never uploaded or persisted to a server.
- Password correctness is checked offline via a stored verifier, so the server is never asked to validate the password.
What is not protected (read this carefully)
| Not protected | Why it matters |
|---|---|
| File bytes at rest | Files on FilesHub are not encrypted; only their URL/metadata is. A holder of the raw URL can fetch the file. |
| Open (no-password) chats | Everything is plaintext; anyone with the chat ID can read all messages and files. |
| Grouping/metadata fields | kind, title, topic, thread counts, and reservation fields stay plaintext even on passworded chats. |
| Identity vs. infrastructure | Standard Firebase telemetry (IP address, user agent) is processed. AChat hides you from other participants, not from a subpoena. |
| Lost passwords | No recovery, no backdoor. A lost password means the chat is permanently unreadable. |
Threat model in plain terms
AChat is designed to protect a passworded chat's message contents from:
- Other people who do not have the password.
- A casual observer of the database (they see only ciphertext for passworded chats).
AChat is not designed to protect against:
- A determined adversary who has the password (they can read everything).
- Exposure of file bytes via a leaked FilesHub URL.
- Legal/infrastructure-level identification via IP/UA telemetry.
- Anything in an open chat (no encryption at all).
App-level hardening
Beyond message encryption, the web app ships standard production hardening:
- A strict Content-Security-Policy, plus HSTS,
X-Content-Type-Options, a restrictiveReferrer-Policy, and aPermissions-Policythat denies unused device APIs. - Optional Firebase App Check (reCAPTCHA v3) support — currently off by default, and documented as such rather than claimed as enforced.
- The Android app requests a minimal permission set — INTERNET, VIBRATE, and, only if you opt in to push, notifications (
POST_NOTIFICATIONS) — with no camera, microphone, location, contacts, or storage permission, and no advertising ID.
Practical guidance
- For anything sensitive: generated chat ID + strong password, shared out-of-band.
- Treat files as semi-public; do not upload secrets.
- Treat communities and open chats as fully public.
A note on admin oversight
A built-in administrator role can enumerate chats and read open ones for moderation. It does not weaken this model: passworded chats stay end-to-end encrypted, there is no key escrow, and every admin action is logged. See Admin oversight.