echodrop.net

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.