Security Guide
Encryption and key protection
How TheChatApp protects realtime traffic, stored content, files, databases, exports, backups, and deployment keys at a product level.
Protection map
| Layer | What is protected | Public detail |
|---|---|---|
| Realtime app sessions | Native messaging, presence, call signaling, and app protocol payloads. | Authenticated session encryption after connection setup. Session keys are not reused as permanent workspace keys. |
| Browser and account paths | File transfer endpoints, history sync, browser meetings, identity integrations, diagnostics, portal pages, and account pages. | HTTPS in production, with normal certificate and endpoint controls. |
| Message content | Message bodies and selected related fields such as attachment metadata, edits, comments, and saved notes. | Encrypted before being written to server storage. |
| File bodies | Uploaded files and generated protected derivatives such as thumbnails. | Encrypted at rest while retaining authorized streaming and range-download behavior. |
| Databases | Server and client local databases. | Encrypted database connections with key material protected by deployment or platform key storage. |
| Exports and backups | Administrative exports and backup archives. | Encrypted before delivery or storage. Restore requires the appropriate recovery material. |
| Deployment keys | Tenant content and database keys. | Protected with KMS-backed key wrapping for server-side storage. |
Traffic and browser paths
Native clients establish encrypted realtime sessions before workspace protocol traffic is exchanged. These session keys protect live traffic and are separate from tenant storage keys.
Browser meeting pages, file transfer paths, history sync, diagnostics, identity-provider provisioning, and account pages use HTTPS in production. Native clients also remember the server identity and warn users if it unexpectedly changes.
Stored content and files
Stored message content is encrypted before it is written to the message store. This includes message bodies and selected related fields such as attachment metadata, edit history, comments, code review annotations, and saved-message notes.
Uploaded files are encrypted at rest while still supporting authorized downloads, previews, and range reads. Protected derivatives, such as thumbnails generated from uploaded media, follow the same storage-control model.
| Field type | Stored encrypted | Notes |
|---|---|---|
| Message body | Yes | Plaintext is recovered only when the service needs to serve history, search, notifications, or app features. |
| Attachment metadata | Yes | Names and metadata are protected separately from the uploaded file body. |
| File body | Yes | Stored files remain encrypted at rest while preserving authorized streaming and download behavior. |
| Indexes and routing metadata | Partly | Some metadata such as channel ids, timestamps, sender names, attachment flags, and sequence counters remains queryable so the app can route and search efficiently. |
Databases and local storage
Server database files are opened through a centralized encrypted database helper. Server-side database key material is protected with KMS-backed wrapping, and restore workflows require the appropriate KMS access or recovery material.
Desktop and mobile clients also use encrypted local database connections. The local database secret is stored behind the platform secure storage provider: Windows DPAPI, macOS Keychain, Android Keystore-backed encrypted preferences, and iOS Keychain.
KMS-backed key protection
Server-side workspace and database key material is protected with KMS-backed wrapping. This reduces the value of copied disks, tenant directories, database files, and backup archives when the attacker does not also have the required KMS access.
KMS configuration and recovery material should be treated as sensitive administrative assets. Key-related administrative changes, backup restore, recovery use, and backup key rotation are security-significant events and should be reviewed through audit logs.
Boundaries
Encryption at rest protects copied disks, tenant directories, database files, files, and backups. It is not the same claim as saying a running server can never access plaintext. The service must decrypt content in memory to deliver history, render previews, generate search or embedding data where enabled, apply retention/export workflows, and serve authorized downloads.
- Protect administrator accounts, KMS access, recovery material, and endpoint devices; encryption cannot compensate for a compromised authorized endpoint.
- KMS wrapping protects offline artifacts, but a running service still needs operational access to use keys and serve the workspace.
- Some routing and index metadata remains available to the server so the product can deliver messages, notifications, search, files, and audit workflows.