Recipient approval: when the link alone is not enough
Recipient approval (Trust-Key) is an optional protection for especially sensitive messages. When enabled, an intercepted or forwarded link cannot open the message — only after you approve the recipient device once. It is off by default.
What zero-knowledge gives you
- Intercepted or forwarded links are worthless
- Only the device you approved can decrypt the second key half (ECDH P-256)
- Server never sees plaintext, private keys or the second half
- Once a device is trusted, future messages open automatically
The problem recipient approval solves
Every link-based system shares one weakness: whoever holds the link holds the secret. Forward it to the wrong thread, leave it in a shared document, or have it intercepted, and the content is readable by someone you never intended.
Recipient approval splits the key in two. One half rides in the link as usual. The other half is released only after you approve the request, and it is encrypted for the specific device that asked. A link that reaches the wrong person is therefore inert on its own.
The trade-off is that the exchange is no longer fire-and-forget: you have to be present to approve. Availability also shifts, since anyone with the link can consume the single read attempt even without being able to decrypt it. Confidentiality, however, holds.
Frequently asked questions
Does recipient approval protect against intercepted links?
Yes, for confidentiality. The key is split in two; one half is in the link, the other is only released encrypted for the approved device after you approve.
Is zero-knowledge preserved?
Yes. Encryption and keys stay in the browsers. The server only stores ciphertext, public recipient keys and the encrypted access package.
Related pages
Open the secure app at pcpx.one and create your encrypted link.