Thanks for the detailed and thoughtful reply — I really appreciate the time you took to lay this out.
I know Aaron Swartz — big fan.
You're right about many of these points. The biggest challenge with any web-based cryptography project is trust in code delivery, especially when it's dynamically served. That’s a fundamental limitation of browser-delivered JavaScript, and I fully acknowledge it.
You're also absolutely right that true zero-knowledge isn't just about encryption — it's about removing trust assumptions. The server still being able to serve malicious JS is a valid and well-known concern. That’s why I’ve made the code open-source and encourage self-hosting for anyone who doesn’t trust DeadDrop or me.
To clarify a few things:
-No JavaScript is sent after the file metadata is submitted — only the encrypted metadata and the file are transferred after the password is verified locally. I’m also planning to encrypt metadata (including filenames) to limit what the server can see.
-DeadDrop uses salted encryption. I'm using a proper key derivation function (PBKDF2) with a salt, which makes brute-force attacks significantly harder.
You’re right that unless users host the project themselves, they have to trust me — just like users of Signal technically have to trust their app stores and client builds. So, trust is a fundamental principal for a service like this and I promise the code that is delivered on the browser is same as on the github. However, if you don't trust my instance, you can review, fork, and self-host it easily.
I’m not claiming DeadDrop is flawless — just that it’s a sincere attempt to build a privacy-first, zero-knowledge file-sharing tool. I am truly grateful for your feedback, thanks again.