The Problem With Sharing Sensitive Information
You need to send a password, API key, or sensitive note to someone. Email leaves a copy in your sent folder, their inbox, and potentially on mail servers in between. Slack and Teams log everything indefinitely. SMS is plaintext. Even "secure" messaging apps store message history.
One-time secret tools solve this by creating a link that can only be opened once — after which the secret is permanently deleted. But how that deletion is implemented, and crucially, who can read the secret before it's deleted, varies significantly between tools.
The Three Tools Compared
We'll look at three of the most widely used options: Privnote, Password Pusher, and OneSecret. All three offer self-destructing links. The differences lie in encryption architecture.
| Feature | Privnote | Password Pusher | OneSecret |
|---|---|---|---|
| Encryption type | Server-side | Server-side | Client-side |
| Server can read secrets | Yes | Yes | No |
| Decryption key stored server-side | Yes | Yes | Never |
| No account required | Yes | Yes | Yes |
| View limits | Yes (1 view) | Yes (configurable) | Yes (configurable) |
| Expiry time | Yes | Yes | Yes |
| Optional password protection | No | Yes | Required |
| Tracking / analytics | Yes | Optional | None |
The Key Difference: Where Encryption Happens
This is the most important factor and it's worth understanding clearly.
Server-side encryption (Privnote, Password Pusher)
With server-side encryption, you send your plaintext secret to the server. The server then encrypts it and stores the encrypted version — along with the key needed to decrypt it. This means:
- The server operator has technical access to read your secret
- A data breach could expose your secrets if the key store is compromised
- Law enforcement requests or subpoenas could compel disclosure
- You are trusting the operator's security practices entirely
To be clear: Privnote and Password Pusher are both reputable tools and are far safer than sending passwords in plaintext. But their architecture requires trust in the server.
Client-side encryption (OneSecret)
With client-side encryption, your browser encrypts the secret before it leaves your device. The decryption key is embedded in the URL fragment (the part after the #), which browsers never send to the server. This means:
- The server stores only unintelligible ciphertext
- The server operator genuinely cannot read your secret
- A breach of the server exposes nothing useful
- Even a court order can't produce a key the server never had
This architectural difference — not a policy difference — is what "zero knowledge" actually means.
What About Privnote's Phishing Problem?
It's worth noting that Privnote has historically been targeted by phishing sites (e.g. "privnotes.com") that intercept secrets before they self-destruct. Because Privnote's server can read the plaintext, a convincing clone can silently read and re-encrypt your secret before forwarding the link. With client-side encryption this attack is significantly harder — a malicious server can serve a modified JavaScript payload, but this is detectable and requires a more sophisticated attacker.
Which Should You Use?
For most personal use: any of these tools is dramatically better than emailing a password. If you already use Privnote and it works for you, it's a reasonable choice.
For anything sensitive: client-side encryption matters. If you're sharing credentials for a production system, a financial account, or anything that would cause real harm if exposed, you want a tool where the server is architecturally incapable of reading your data — not just one that promises it won't.
For teams with compliance requirements: the zero-knowledge model also simplifies your threat model. If the server never holds the key, it's not in scope for many breach disclosure requirements.
No account required. Your secret is encrypted in your browser before it ever leaves your device. Create a secret link →
Frequently Asked Questions
Is Privnote safe to use?
Privnote is a legitimate, well-established service and is much safer than sharing passwords in email or chat. The limitation is architectural: the server holds the decryption key, which means Privnote staff and any attacker who compromises the server can technically read your secrets. For low-sensitivity use this is generally acceptable. For high-sensitivity data, client-side encryption is preferable.
What does "client-side encryption" mean?
It means your data is encrypted on your own device (in your browser) before it's sent anywhere. The server receives only the already-encrypted ciphertext. Without the decryption key — which stays in your URL and is never sent to the server — the stored data is useless to anyone who intercepts or accesses it.
Can OneSecret read my secrets?
No. The decryption key lives only in the URL fragment (#key). Browsers don't include the fragment in HTTP requests, so it never reaches our server. We store only the encrypted ciphertext, which is unreadable without the key.
What happens if someone intercepts the link?
If someone obtains the full URL (including the fragment) before the intended recipient opens it, they can read the secret. This is true of all one-time secret tools. The mitigation is to send the link over a channel you trust, and seperate password with username from being in the one secret for high-sensitivity.
Is Password Pusher open source?
Yes, Password Pusher is open source and can be self-hosted, which is a significant advantage for teams who want full control. If self-hosting, you control the server and the encryption model becomes less relevant since you own the infrastructure.