I've created a file sending/sharing website (think WeTransfer) which I believe is unique in several ways:
* End-to-end encrypted * Recipients can start their download anytime, i.e. it's not P2P WebRTC-based thing like FilePizza * (Effectively) no limit on the size of the uploaded data, i.e. it will encrypt/decrypt 100 GB just fine * (Effectively) no limit the number of files that get sent * Real-time transfers, i.e. recipients can start downloading their files even before you finish uploading them * Resumable uploads/downloads * ZIP downloads - creates ZIPs on the fly in the browser from decrypted data * Full passkey auth, i.e. can derive data encryption key from a passkey with PRF * Fast - 10 Gbps link, plus due to the chunking design, uploading 1024 files of 1 KB or a single 1 MB file take about the same amount of time * No nasty trackers
Also, it has a dark mode!
The upload process joins small files together, splits large files apart, builds ~1 MB chunks from the data, encrypts each chunk with AES-256-GCM (each with its own unique IV), and streams it out via a WebSockets channel; the download process does pretty much the same thing in reverse.
Server-side, incoming uploads get written into a bespoke binary format (something like Protobuf) supporting random access. This enables upload/download resume, selective download of one or more files, and real-time downloads.
When downloading, the website sets up a service worker and adds its URL as an iframe (a known hack to force the browser to download something produced by JavaScript). Said service worker fetches the data, decrypts it, and then creates an uncompressed ZIP archive on the fly; for that purpose, I've implemented a whole new streaming ZIP64 archiver (which I'm considering open-sourcing at some point).
I'm using OPAQUE for authentication (though serenity-kit/opaque and Facebook's opaque-ke), as this seemed to be a good way to prevent me from being able to learn anyone's "hunter2" (passwords are used for encrypting the DEK which in turn encrypts uploads' "secret keys" for authenticated users). Also, OPAQUE would prevent weak passwords from getting cracked in case of a security mess-up on my end.
The website is able to authenticate the user fully using just the passkey. If the passkey provider has support for PRF, the website won't have to ask the user for their master password as it will then be able to decrypt the DEK using the PRF; otherwise, passkeys serve as a way to do 2FA. If you'd like to try it out, use iCloud Keychain (on macOS / iOS), Windows Hello, or Android for storing a passkey.
The frontend uses Svelte 5. I'm no frontend magician like some here, but I think at least I managed to keep it fast and simple.
I figured that if our messages are now E2E-encrypted by default, and even which news articles I'm reading on my news website are protected by TLS, then the users of file sending services should enjoy some privacy too - at this point E2EE should be just basic privacy hygiene.
The whole project took way longer than I'd like to admit, mostly because I got nerd-sniped by a bunch of premature optimization, and also had to fake my way into learning how to do modern frontend.
There's a 2 GB free limit for free transfers, also a Premium subscription option with a 100 GB limit. I want this to exist for the long term, but I have to make the finances work. If you find it useful, I'd love your support! If there's interest from HN, happy to share a promo code for a free trial (no CC required).
Feedback welcome!
(Please excuse the grammatical mistakes if any, I'm not a native English speaker, and I didn't want to feed this to an LLM to make it look like AI slop.)
