Why Privacylink cannot read the message content
This page describes how Privacylink combines client-side encryption, a split key and mailbox verification to release confidential content in a controlled way.
The browser encrypts before storage
When a message is created, the browser generates a random key locally. The message body is encrypted immediately in the browser with AES-GCM.
The server therefore receives ciphertext, technical metadata and a nonce, but not the readable confidential content.
The full key is not on the server
The key is split into two parts. One part is stored on the server together with the encrypted payload.
The other part is placed in the URL fragment after #. That fragment is not part of the HTTP request and is not sent to Privacylink.
The sender shares the link
Privacylink does not send the confidential content itself and does not automatically send the full link to the recipient.
The sender chooses the channel and shares the full link, including the fragment. A separate channel such as WhatsApp, Signal or Teams can reduce risk because the email conversation and access link are not kept in the same place.
Release follows mailbox verification
The recipient opens the link, confirms the email address and enters a temporary verification code.
The server then returns the encrypted payload and its key share. The browser combines both parts locally, decrypts the message and the content is then removed from the database.
What this model does not solve
- A recipient can still copy or record the content after opening it.
- The sender remains responsible for sharing the full link carefully.
- Metadata such as subject, email addresses and status information remains necessary for operation, security and accountability.
Also read the privacy and use information
The technical design reduces certain risks, but it does not eliminate every risk. The privacy and use page describes data processing, retention periods and intended use.