What Secure Rooms do NOT protect against

Secure Rooms provide strong encryption, but they do not make every risk disappear. Here is what the feature deliberately does not do.

Compromised frontend build

Encryption runs in your browser, in code served by the platform. If the platform (or an attacker who compromised it) served a malicious build, it could steal keys. We mitigate this but cannot eliminate it: the cryptography lives in a public repository (https://github.com/wpartscom/secure-rooms-crypto) with a reproducible build, published sha256sums and Subresource Integrity, and the "Security" page shows the build hash of the loaded library so you can verify it. Residual risk remains.

No per-message forward secrecy

Keys rotate per epoch (member joins, member removals, manual rotation), not per message. If a room key of some epoch is compromised, all messages of that epoch are compromised. Protocols with per-message forward secrecy (Double Ratchet, MLS) are not part of the current version.

Metadata is visible to the server

The server sees who is in a room with whom, when messages are sent, and the sizes of messages and files. There is no server-side full-text search and there cannot be - search works only within your locally decrypted cache.

Participants can save and share content

Screenshots, copying and forwarding of decrypted content by a legitimate participant cannot be technically prevented. A removed member keeps whatever history is cached on their device. Choose room participants accordingly.

Notifications contain no content

Email and Telegram notifications about Secure Rooms never include message text, room names or file names - only the room code (e.g. A7F3Q2) and the number of unread messages. This is a deliberate design choice, so do not be surprised that the notifications look terse.