How I built a file sharing app where the server is 100% blind to your files (and why it matters)

#security #privacy #showdev #opensource

I built FileShot — a zero-knowledge file sharing tool where all encryption and decryption happens entirely in the browser. The server never sees your decryption keys — they live only in the URL fragment.

The zero-knowledge approach

When you upload a file, it gets encrypted with AES-256-GCM in your browser before a single byte hits the network. The encryption key is generated client-side and appended to the share URL as a fragment (#key=...). URL fragments are never sent to servers by design — they exist only in the browser.

The person receiving the file gets the full URL including the fragment. Their browser extracts the key, downloads the encrypted blob, and decrypts it locally. The server is physically incapable of reading your files — not just by policy, but by architecture.

What it grew into

What started as a simple encrypted upload tool expanded into a multi-surface product:

Web app — upload, share, manage files with expiry timers, password protection, and download limits
Desktop app (Electron) — tray integration, background uploads, drag-and-drop
Chrome extension (MV3) — right-click to share any file or screenshot directly from the browser
Android APK — mobile sharing with the same zero-knowledge model
Free tools suite — PDF editor, file converter, archive builder, secure/encrypted paste — all browser-based, no server upload required

Stack

Node.js + Express backend
SQLite for metadata (file content is never stored in plaintext — only encrypted blobs)
Cloudflare Tunnel for ingress (no exposed ports on the server)
Static frontend — vanilla JS, no framework overhead, no build step
Stripe for paid plan billing
Chrome MV3 extension with offscreen document for clipboard/DOM operations

The hardest part

Getting the key exchange right. The URL fragment approach means if someone strips the fragment before sharing (e.g. when a link preview service fetches your URL), the recipient can't decrypt. It's a real UX tradeoff for zero-knowledge guarantees.

Also: Chrome MV3 service workers have no DOM access, which makes clipboard and screenshot operations interesting to wire up correctly.