• 0 Posts
  • 33 Comments
Joined 1 year ago
cake
Cake day: May 27th, 2025

help-circle











  • 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.