echodrop.net

Redacted Server Logs Enabled

About How it works Contact

Write once / Read once – one-time notes

Javascript not enabled.

TRUST NO ONE! Use at your own risk.
While significant efforts have been made to secure this application, no
guarantee is given, express or implied, as to its security or suitabilty for your use.

"доверяй, но проверяй" isn't just a cute saying.
It's how you stay alive.

EchoDrop is an encrypted, ad-free, private, key separated zero-knowledge write-once read-once messaging facility which provides multiple encryption layers, no identifiable logging, no cookies, and a simple interface. It supports both javascript and non-javascript enabled client.

For more detailed information, follow the About link.

Message (max 2048 characters) Notification email (optional)

Send notification to this email on message access. No email is sent if message expires.

Notification subject (max 128)

Valid after (UTC) ^?Valid after Valid after ×

The note cannot be opened before this date and time. All times are UTC.

Anyone who uses the retrieval link too early and continues past the warning receives a generic 404 Not Found. The server does not indicate that a message exists or will exist later.

If you also enable Burn on early access, that same Continue click destroys the note. Warn the recipient.

All times are UTC.

Expires after (days from valid-after)

365 days max

Burn on early access ^?Burn on early access Burn on early access ×

This feature will silently burn the note if an attempt is made to read the note before it is valid.

Warn the recipient accordingly.

The note is burned only if they proceed past the Continue prompt. Opening the link without continuing does not destroy it.

Require checksum ^?Require checksum Require checksum ×

This feature will generate a 6 character checksum which the recipient will be required to enter. Before the message is displayed the checksum will be verified. If it does not match the message will be silently burned.

This checksum should be provided to the recipient via a different mechanism than used to send the URL or token.

Messages are encrypted at rest. The retrieval token is never stored on the server.

About

About echodrop.net

EchoDrop is a write-once, read-once messenger: you write a note, you get one link, the recipient reads it once, then the note is gone. There are no accounts, no ads, and no cookies. The service is designed so the operator cannot read a note without the secret that lives in the link.

The retrieval link contains a secret that is never stored on the server. Without that secret, ciphertext on disk cannot be opened—even if a server key is obtained.

Zero-knowledge approach

The only secret that can open a note is the token in the retrieval link. That token is never written to disk.
Filenames are one-way derivations of the token. A directory listing does not reveal links, nonces, or tokens.
Schedule (valid after and expiration) lives inside the encrypted payload, not in a sidecar file.
Notification addresses and notification subjects are stored only inside the encrypted payload.
The link uses a URL fragment for the token so browsers do not send it to the web server. Without JavaScript, paste the token into the form; it is submitted in the POST body, not the query string.

Message protection

Input is length-limited, sanitized, encoded, and padded before it is encrypted. Stored files are padded to a fixed size bucket so length is not visible from the directory.
Authenticated encryption binds a per-message random token to server key material. Tampering is detected and treated as “not found.”
Plaintext is never written to disk. Only ciphertext is stored.
After a successful read, buffers are wiped and the file is overwritten with random data, then removed.
Notes that are already expired when opened are destroyed the same way and still presented as “not found.”
There is no scheduler that must know expiration times so there is no external metadata associated with the message.

Security design and hardening

Fail secure. Permission and path checks run on every request. A failed check stops the application.
Key ring. Server side encryption keys are rotated and retired. Retired keys are kept only until notes that could still use them are past their maximum lifetime, then erased.
Read once. The retrieve page does not decrypt on first view (so automated link scanners do not consume the note). Opening it requires an explicit confirmation. Concurrent openers are serialized so only one request can succeed.
Uniform failure. Missing, expired, not-yet-valid, and forged tokens all produce a generic 404. Retrieve attempts take a minimum amount of time so a fast miss cannot be used to prove a note is absent.
Optional sender controls. Burn on early access destroys a scheduled note if the recipient continues before it is valid. A 6-character checksum, sent by a separate channel, is required when that option is on; a mismatch after Continue silently burns the note. If a checksum wasn't requested at creation time, any checksum input on retrieval is silently ignored. This prevents burning a note due to accidental input.
Logging is off by default. Application diagnostic and usage lines are written only when debug mode is enabled. Debug mode is visually obvious and requires an extra acknowledgement before a note is consumed.
Web server logs. The site tries to detect whether the vhost still writes access or error logs, and shows that status in the header. Site owner can disable those logs at the vhost level.
Abuse controls. Multiple methods of abuse detection and prevention are in place.
Least privilege. Keys, ciphertext, and logs sit outside the web root and are denied by the web server configuration.

What is and is not logged

With debug off, the application does not record that a note was created, expired, or read.
Each request performs a security-assessment and logs that result. No message content, tokens, or addresses are logged.
If you opt in to email notification, a mail server may log the outbound message when the note is actually read, not when it expires.