Platform security
Encrypted chat
The participant, encryption, device, recovery, media, and threat boundaries you must understand before relying on chat.
Security
Review account, session, and platform controls around chat.
Notifications
Understand persistent notifications and chat unread state.
What end-to-end encryption means here
PE Community creates chat key material in the browser. A direct message is encrypted with a key derived from the sender’s private key and recipient’s public key. A group message is encrypted separately for every current participant, including the sender. Decryption happens in an authorized participant browser that holds the required private key.
Plaintext and private keys remain in participant browsers while the service authorizes access and stores or transports ciphertext with permitted metadata.
Current cryptographic construction
Message keys use ECDH on P-256 to derive AES-GCM-256 keys, with a fresh 12-byte nonce for each encryption. Attachment bytes use a fresh AES-GCM-256 file key and nonce. Group delivery stores a recipient-specific encrypted envelope. This is a browser E2EE model, not the Signal protocol or a ratcheting protocol.
What the service stores and can observe
| Visible to the service | Not intentionally sent in plaintext |
|---|---|
| Conversation identifiers, type, title, participants, roles, and membership changes | Message body and locally derived reply text |
| Sender, timestamps, read/delivery state, ciphertext size, reactions, stars, reports, and deletion state | Participant private keys and recovery password |
| Public keys, key versions, fingerprints, device labels/status, and presence metadata | Decrypted attachment bytes, previews, file key, filename, MIME type, and original size |
| Encrypted attachment blob, encrypted size, media category, quota, lifecycle, sender, and conversation | Decrypted message or attachment search index |
Browser and device key model
The current private identity is stored in IndexedDB for the account and community within that browser profile; older local private identities are retained in a local key ring after rotation. An opaque device identifier and descriptive device metadata are stored separately. Browser profiles, private browsing sessions, and different computers do not share this storage automatically.
Back up your encrypted-chat keys
Use the chat recovery control to export an encrypted JSON backup after initial key setup and before any device or browser change. The backup contains the current private key encrypted locally with AES-GCM-256. A key derived from the recovery password uses PBKDF2-SHA-256 with a random salt and 210,000 iterations. The recovery password and unencrypted private key are not sent to the service.
- Store the backup somewhere protected and separate from the browser.
- Use a strong, unique recovery password and store it separately from the backup file.
- Create a fresh backup after an intentional key rotation because an earlier file contains only the key exported at that time.
The current private key is encrypted locally into a user-held backup, then restored locally and matched to a retained, non-revoked public key before the new browser is authorized.
Recovery password responsibility
The chat recovery password is separate from the account password, MFA, and password-reset process. Administrators cannot retrieve it. If the browser keys, usable backup, or recovery password needed for historical messages are all lost, PE Community cannot decrypt that history for the user.
Restore on a new browser or device
When Chat detects an existing server identity without the matching local private key, it presents Restore encrypted chat. Choose the backup file, enter its recovery password, import it, and authorize the restored browser as a device. Decryption of the file and reconstruction of its public key happen locally; the service verifies that the public key matches a retained, non-revoked key version.
- Restore does not add the user to conversations they do not belong to.
- Restore cannot recover key versions absent from the backup and local history.
- A backup for a revoked key is rejected.
Device management and revocation
Members can list, rename, and revoke their own authorized devices. Authorized operators can inspect and revoke community devices without gaining decryption access. The default active-device limit is three and can be configured from one to eight; lowering it does not revoke devices automatically.
A browser generates or restores key material locally, registers only its public identity and device record, and remains eligible until that device is revoked.
Direct and group conversations
Direct chat is between two active community members and respects participant blocking. Group chat has a title, one owner, and at least two selected members in addition to the creator. The owner can rename the group, add active members, remove non-owners, and transfer ownership; non-owners can leave, while an owner must transfer ownership first.
Participant changes and key distribution
Each new group message is encrypted for the active participant set at send time. Adding a participant lets that member receive future envelopes but does not re-encrypt old messages for them. Leaving or removal ends future conversation, key, attachment, message, and realtime access. Membership changes do not automatically rotate every participant key, and chat does not provide forward secrecy.
Message and conversation features
- Realtime text, typing, presence, delivery/read state, unread counts, replies, and local decrypted search.
- Editing and delete-for-everyone for the sender within 15 minutes; delete-for-me at any visible message.
- Six allowed reactions with one reaction per user per message, plus private per-user starred messages.
- Per-user clear chat and delete conversation; neither changes the other participant’s view.
- Mute settings, pinned conversation organization in the browser, direct-user blocking, and participant-authored message reporting.
Encrypted attachments and media
The browser accepts current image, video, PDF, text, SVG, Word, and Excel types and rejects unsupported or plaintext files over 8 MiB before encryption. It encrypts the bytes before upload. Filename, MIME type, original size, file key, and file nonce travel inside the encrypted message payload; the service stores the encrypted blob and operational metadata only. The server-side encrypted-object limit defaults to 10 MiB and a community media quota may also apply.
- Downloads require current conversation participation; decryption and previews happen locally.
- No server-side plaintext thumbnail, preview, text extraction, filename, or MIME index is generated.
- Normal media can be opened and downloaded after local decryption. Direct-chat view-once images use a server-recorded one-time recipient open and do not expose download; group view-once media is not supported.
Encrypted-media governance
Authorized operators can view encrypted-byte totals, category usage, lifecycle state, uploader, conversation identifiers, and deletion operations. They can request asynchronous encrypted-object deletion and reconciliation without seeing plaintext. Deleting an encrypted object does not necessarily delete its surrounding message or conversation.
What E2EE does not protect against
- A compromised browser, operating system, extension, or device that can access decrypted content or local keys.
- A recipient copying, forwarding, photographing, or screenshotting content.
- Exported decrypted files, weakly protected backups, or storing the backup beside its recovery password.
- Service-visible metadata such as participants, timestamps, sizes, reactions, device registration, presence, and delivery state.
- Loss of private keys or recovery material, lack of forward secrecy, and content already decrypted before revocation or participant removal.
Safe user practices
- Create and verify a key backup before changing or clearing a browser, profile, computer, or operating system.
- Use a unique recovery password and never send the backup and password together.
- Keep devices, browsers, and extensions updated; avoid shared browser profiles and private browsing for persistent chat use.
- Review authorized devices, revoke lost devices promptly, and understand that revocation is not remote wipe.
- Treat every recipient as able to retain plaintext after decryption.