Launching today
Burn After
Single-use file links that disappear after opening
23 followers
Single-use file links that disappear after opening
23 followers
Burn After lets you send sensitive files using single-use links that expire after first access. No recipient account required. Useful for tax documents, IDs, contracts, PDFs, or anything you’d rather not leave sitting in someone’s inbox forever. Upload a file, share the link, and once it’s opened, the link expires and the file is removed shortly after.
Congrats on the launch! The problem is real and underserved. One question, what happens on the server side between upload and the link being opened, is the deletion verifiable?
@prateek_kumar28 Great question.
Today, files are stored in a private S3 bucket and deleted server-side after first access or expiration. Once a link is opened, access is immediately revoked and the file is deleted shortly after.
The sender can also see file status in the UI, including when deletion has completed. That said, deletion is not independently cryptographically verifiable in v1. Today, trust comes from the system design and visibility into the file lifecycle rather than cryptographic proof.
Longer term, I’m interested in stronger guarantees, potentially including client-side encryption / zero-knowledge approaches where the server never has usable access to the file contents.
I have a quick question, @ezrafree. For the single-use links, what happens if the download gets interrupted mid-transfer? Does the link still expire, or can the user retry safely?
@taimur_haider1 Great question. The honest answer is: today Burn After is security-first, not retry-friendly.
The link is marked as used when the download is initiated, before redirecting to the short-lived file URL. So if the transfer is interrupted after that point, the original single-use link is already burned and can’t be retried.
That tradeoff is intentional for now: for sensitive files, I’d rather avoid leaving a link reusable after access has begun, even if that makes interrupted downloads less forgiving.
That said, I do think there may be room for a safer middle ground later, something like a very short in-progress window or confirmation-based burn flow. Still thinking through that balance.
Single-use expiring file links is a clean and simple idea. No account required for the recipient is the right call — adds friction kills adoption. I've needed something like this for sending credentials and signed contracts. Curious if there's a TTL option for links that are never opened.
@asim_saeed1 Appreciate this, Asim. And good news: this actually already exists 😄
When creating a link, you choose an expiration time (24 hours by default). If the file is never downloaded before that expiration, the link stops working and the file is automatically deleted.
Recipient friction was definitely something I wanted to minimize, which is why there’s no account required on the receiving side.
Really appreciate the feedback though. Credentials and signed contracts are exactly the sort of use cases I had in mind when building Burn After.