Five months ago, I posted the beta of BurnShot here. It was a simple tool to share self-destructing images.
The top comment immediately pointed out the elephant in the room: "Web based! Receiver can take a screenshot very easily."
They were 100% right. My immediate instinct as a builder was to try and fix it. I looked into CSS hacks, disabling right-clicks, and listening for print-screen keystrokes. But I quickly realized that doing so would be selling snake oil. You cannot reliably implement OS-level screenshot restrictions through a standard web browser. And even if you could, you can never defeat the "analog hole"—someone simply holding up a second phone to snap a picture of their screen.
That single comment forced me to step back and act like a Product Manager. I had to ask: If I can't stop the recipient from saving the image, what is the actual point of this product?
It made me completely redefine BurnShot's threat model.
If you are sending data to a malicious actor you don't trust, don't use BurnShot. Nothing can protect you.
BurnShot is actually built for hygienic sharing with trusted (or semi-trusted) parties. For example in Strategy & Transaction Advisory, I constantly see professionals sharing sensitive M&A evaluations, tax computations, or proprietary trading charts over WhatsApp or Slack. You trust the recipient to read it, but you don't trust the infrastructure. You don't want that sensitive file sitting in their iCloud backup, lingering in your chat history for years, or residing in a central database waiting for a breach.
Once I accepted that I couldn't control the recipient's device, I realized I had to absolutely control the transit and the server.
So, I ripped out the backend and built BurnShot v2.0: A mathematically verifiable, Zero-Knowledge architecture.
Here is what changed under the hood:
- We embraced the web, but killed the server visibility: Payloads are now encrypted entirely locally in the browser using the Web Crypto API (AES-256-GCM).
- The URL Hash Trick: The decryption key is generated locally and appended to the URL as a fragment (#key). Because browsers fundamentally do not send URL hashes to the server, my database only ever receives and stores garbled binary blobs. Even I cannot see your images.
- Atomic Detonation: To prevent "last-view" race conditions (e.g., two people clicking a 1-view link at the exact same millisecond), I wrote custom Postgres RPCs to handle the view-count increments atomically.
- Async Cleanup Failsafe: When a payload hits its view limit or expiry time, the DB immediately revokes access, and an async worker permanently wipes the binary blob from the storage edge.
BurnShot is now live at its permanent home: https://burnshot.app The core product will always remain free, supported only by privacy-respecting, context-based affiliate partners (no trackers, no cookies).
I built this to solve a real problem, but it also served as a masterclass for me in product pivoting, architecture design, and user-centric execution.
I’d love for the HN community to pop open the Network tab, inspect the cryptography, and let me know what you think of the v2 pivot!
0 comments
—
Show HN: BurnShot v2.0 – Zero-Knowledge ephemeral sharing · HackerTrans
The top comment immediately pointed out the elephant in the room: "Web based! Receiver can take a screenshot very easily."
They were 100% right. My immediate instinct as a builder was to try and fix it. I looked into CSS hacks, disabling right-clicks, and listening for print-screen keystrokes. But I quickly realized that doing so would be selling snake oil. You cannot reliably implement OS-level screenshot restrictions through a standard web browser. And even if you could, you can never defeat the "analog hole"—someone simply holding up a second phone to snap a picture of their screen.
That single comment forced me to step back and act like a Product Manager. I had to ask: If I can't stop the recipient from saving the image, what is the actual point of this product?
It made me completely redefine BurnShot's threat model.
If you are sending data to a malicious actor you don't trust, don't use BurnShot. Nothing can protect you.
BurnShot is actually built for hygienic sharing with trusted (or semi-trusted) parties. For example in Strategy & Transaction Advisory, I constantly see professionals sharing sensitive M&A evaluations, tax computations, or proprietary trading charts over WhatsApp or Slack. You trust the recipient to read it, but you don't trust the infrastructure. You don't want that sensitive file sitting in their iCloud backup, lingering in your chat history for years, or residing in a central database waiting for a breach.
Once I accepted that I couldn't control the recipient's device, I realized I had to absolutely control the transit and the server.
So, I ripped out the backend and built BurnShot v2.0: A mathematically verifiable, Zero-Knowledge architecture.
Here is what changed under the hood:
- We embraced the web, but killed the server visibility: Payloads are now encrypted entirely locally in the browser using the Web Crypto API (AES-256-GCM).
- The URL Hash Trick: The decryption key is generated locally and appended to the URL as a fragment (#key). Because browsers fundamentally do not send URL hashes to the server, my database only ever receives and stores garbled binary blobs. Even I cannot see your images.
- Atomic Detonation: To prevent "last-view" race conditions (e.g., two people clicking a 1-view link at the exact same millisecond), I wrote custom Postgres RPCs to handle the view-count increments atomically.
- Async Cleanup Failsafe: When a payload hits its view limit or expiry time, the DB immediately revokes access, and an async worker permanently wipes the binary blob from the storage edge.
BurnShot is now live at its permanent home: https://burnshot.app The core product will always remain free, supported only by privacy-respecting, context-based affiliate partners (no trackers, no cookies).
I built this to solve a real problem, but it also served as a masterclass for me in product pivoting, architecture design, and user-centric execution.
I’d love for the HN community to pop open the Network tab, inspect the cryptography, and let me know what you think of the v2 pivot!