Privnote Alternative: Client-Side Encrypted Secret Sharing
Same workflow, different encryption architecture.
How Privnote works
Paste a note, get a link, recipient reads it, note self-destructs. The workflow is simple and familiar. But between those steps, the secret travels to Privnote's servers as plain text over HTTPS. The server encrypts it for storage with an undisclosed algorithm. When the recipient opens the link, the server decrypts and sends it back.
The server has the secret in readable form for the entire round trip. That's server-side encryption. It protects data from outsiders, but not from the server itself. For a deeper look at this distinction, see client-side vs server-side encryption.
The closed-source problem
Privnote's code is closed source. There's no way to verify what happens to your secret on the server. The encryption algorithm isn't documented. When a security tool asks you to trust its claims without any way to check, that's a policy promise, not a technical guarantee.
The phishing clone problem
Because Privnote's interface is simple, anyone can build a site that looks identical. Fake clones have been documented that modify the contents of notes before delivery, or log the plaintext. If the recipient doesn't verify the domain carefully, they could be reading a tampered version of what you sent.
With Secret.Broker, the ciphertext is bound to the secret.broker domain through authenticated encryption. If someone copied the encrypted payload to a different domain, decryption would fail because the domain mismatch breaks the authentication.
Client-side encryption
Your browser encrypts the secret with XChaCha20-Poly1305 before anything goes to the server. The encryption key is in the URL fragment, the part after the #, which browsers never include in server requests. The server stores encrypted data it can't decrypt. It handles storage and deletion, but the plaintext never passes through it.
The protocol page documents the full encryption stack.
Feature comparison
- Privnote: server-side, closed-source, text only, 1 view limit, ad-supported
- Secret.Broker: client-side XChaCha20-Poly1305, file attachments up to 20 MB, view limits 1-25, expiry 15 min to 30 days, paranoid mode, no ads, no account
Both tools create self-destructing messages. The difference is where encryption happens and what the server can see. For a broader comparison across tools, see the alternatives comparison.
Also compare: vs OneTimeSecret and vs Password Pusher.
Common questions
Is Privnote safe?
Privnote uses server-side encryption with an undisclosed algorithm. The code is closed-source so encryption claims can't be verified. HTTPS protects data in transit, but the server processes your secret in plain text. For casual notes it works. For passwords or API keys, a tool with client-side encryption means the server never handles your secret in readable form.
Is Privnote encrypted?
Privnote uses server-side encryption, meaning your secret is encrypted after it reaches their server. The encryption algorithm isn't publicly documented. With client-side encryption, your browser encrypts before anything is sent, so the server only ever stores ciphertext it can't read.
Can someone intercept a Privnote?
With any server-side encryption tool, the server processes your secret in plain text. If the server is compromised, secrets could be exposed. Privnote also has a documented phishing clone problem. With client-side encryption, even a compromised server only gets ciphertext without the key.
What's the difference between Privnote and Secret.Broker?
Privnote uses server-side encryption with closed-source code. Secret.Broker encrypts in your browser with XChaCha20-Poly1305 before anything reaches the server. The decryption key stays in the URL fragment and never touches the server. Secret.Broker also supports file attachments up to 20 MB, configurable view limits, and paranoid mode for split-key delivery.