Your content. Your devices. Your keys.

What is encrypted?

Links and page titles, text, file contents, file names and types, thumbnails and device names are end-to-end encrypted. Decryption happens on your enrolled devices. History search runs locally; the server cannot search your content.

Every enrolled device can decrypt your account history. Choosing a destination controls delivery and notifications, not which of your enrolled devices can read a push.

The beta uses P-256 agreement and signing keys, HKDF-SHA256 and AES-256-GCM. Keys are shared with approved devices using HPKE (RFC 9180). Clients verify signatures and authenticated encryption before using received content. File encryption detects missing, reordered or truncated chunks.

What can the service see?

Encryption protects content, but does not hide all information needed to operate the service:

• Your account email address and account and device identifiers.
• The number and platforms of your devices, their public keys and push tokens.
• Which device sent a push, its destinations, when it was sent and the ciphertext size. Sizes are not padded, so they reveal approximate content length or file size.
• Whether a push includes a file, and when devices are added, removed or recovered or recovery keys are replaced.
• Request IP addresses for abuse protection and rate limiting; these are not kept in our application logs.

Delivery receipts report success or failure without content. Individual delivery records are retained for 7 days, followed by aggregate counts. Android and browser push services receive content-free wake signals; your app then fetches and decrypts the push.

When a sending device fetches a link preview, it contacts the linked website and its image hosts. End-to-end encryption of the push does not hide that visit from those sites. Receiving a preview does not require fetching those images from their original hosts.

The privacy policy lists service providers, website analytics, the waitlist provider and retention details. This security page has no analytics scripts.

How does a device join?

An email sign-in code gives access to account sign-in; it does not grant the keys to your history. A new device also needs approval from an existing enrolled device, or your recovery key.

Pairing uses a QR code or a manual code to transfer a secret between your devices. A new phone can scan an existing device’s invite without signing in first; a new browser signs in with your account email. The phone scans in both pairing directions.

When joining from an existing device’s invite, compare the emoji on the joining device with the choices on the approving device. A mismatch cancels the join. Only approve a device you are holding. Pairing codes expire after 10 minutes and should never be shared or shown during screen sharing.

The new device verifies the signed membership history and key material before using them. Each enrolled device has authority to approve and remove other devices. Android requires local user verification for sensitive device actions. Security notices are sent by email and shown on your devices.

What does the recovery key do?

Your recovery key is generated on your device and is separate from pairing codes and emailed sign-in codes. The server stores an encrypted recovery bundle, rather than the recovery secret. Recovery opens that bundle locally.

If you lose every device, you need both your saved recovery key and access to your account email to enroll a replacement and recover history. If you lose every device and the recovery key, fwd cannot recover your encrypted history. An emailed sign-in code alone cannot decrypt it.

Keep the recovery key somewhere safe, separate from the devices you might lose. Someone with the recovery key and access to your email can recover the account. An existing enrolled device can issue a replacement key; this requires a fresh email code and local verification on Android. The old recovery key then stops working.

What happens when I remove a lost device?

Remove the lost device from another enrolled device. At the removal commit, its service sessions, sockets and push access are revoked and the encryption keys rotate for future accepted pushes. Pending sends must use the current keys before the service accepts them.

Removal cannot erase previously received keys, history or downloaded files from a lost device. Older history stays encrypted under its original keys, which that device may already hold. This is not a remote wipe.

If the recovery key may also have been exposed, replace it separately from an enrolled device. Removing a device alone does not revoke a recovery key it obtained.

How are keys protected on my devices?

Android uses the Android Keystore. Where supported on Android 12 or later, agreement keys are non-exportable Keystore keys. On older Android versions or unsupported providers, software agreement keys are encrypted at rest using a Keystore key and enter app memory when needed.

The extension stores WebCrypto device keys in IndexedDB. Its protection at rest relies on your operating system’s disk encryption. History keys must be usable by the clients to decrypt history and approve devices; not all keys remain in hardware.

Keep your operating system and browser updated, enable disk encryption and use a device lock. Malware running inside an enrolled client, or someone controlling an unlocked device, can read content and misuse that device’s authority.

What encryption does not guarantee

The service can delay or deny delivery, delete data or present different valid histories to different devices. Clients reject rollback behind checkpoints they have already verified, but the protocol does not provide global fork detection or proof that every event was delivered. A newly recovered device cannot independently prove it received the latest valid history.

Retained history has no forward secrecy: someone who obtains its keys may decrypt older ciphertext. Removing compromised authorities and rotating keys protects future accepted pushes, not content already exposed. The beta’s P-256 suite is not post-quantum cryptography.

The protocol has internal design reviews and shared TypeScript and Kotlin test vectors. No independent security audit is published. Beta invitations remain closed; this page is an explanation of the current security model, not an audit certificate.

Deletion and retained data

Deleting a push removes it from synced history as devices reconnect. Files saved to Downloads and content copied outside fwd remain with you. Encrypted history and committed files otherwise stay until you delete them or your account, subject to your storage limit.

Account deletion from an enrolled app starts cleanup immediately. An email-confirmed website deletion request disables the account and has a 72-hour hold so an existing device can cancel it. After the hold, account data is erased within 24 hours. Provider backups may retain encrypted data for up to 30 days, as explained in the privacy policy.

Report a security issue

Email hello@usefwd.io with “Security” in the subject. Include the affected component, what you found and steps to reproduce it. Do not include sign-in codes, recovery keys or private content, and do not test against other people’s accounts.

For general product questions, see the FAQ.