A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 124 users / day
- 1.05K users / week
- 1.3K users / month
- 4.58K users / 6 months
- 1 subscriber
- 3.85K Posts
- 97.1K Comments
- Modlog
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.
TLDR: this is way more broken than I initially realized
So, when i wrote “downloaders send the filename to the server prior to the server sending them the javascript” in my first comment, I hadn’t looked closely enough - I had just uploaded a file and saw that the download link included the filename in the query part of the URL (the part between the ? and the #). This is the first thing that a user sends when downloading, before the server serves the javascript, so, the server clearly can decide to serve malicious javascript or not based on the filename (as well as the user’s IP).
However, looking again now, I see it is actually much worse - you are sending the password in the URL query too! So, there is no need to ever serve malicious javascript because currently the password is always being sent to the server.
As I said before, the way other similar sites do this is by including the key in the URL fragment which is not sent to the server (unless the javascript decides to send it). I stopped reading when I saw the filename was sent to the server and didn’t realize you were actually including the password as a query parameter too!
😱
The rest of this reply was written when I was under the mistaken assumption that the user needed to type in the password.
Do you acknowledge it anywhere other than in your reply to me here?
This post encouraging people to rely on your service says “That means even I, the creator, can’t decrypt or access the files.” To acknowledge the limitations of browser-based e2ee I think you would actually need to say something like “That means even I, the creator, can’t decrypt or access the files (unless I serve a modified version of the code to some users sometimes, which I technically could very easily do and it is extremely unlikely that it would ever be detected because there is no mechanism in browsers to ensure that the javascript people are running is always the same code that auditors could/would ever audit).”
The text on your website also does not acknowledge the flawed paradigm in any way.
This page says "Even if someone compromised the server, they’d find only encrypted files with no keys attached — which makes the data unreadable and meaningless to attackers. To acknowledge the problem here this sentence would need to say approximately the same as what I posted above, except replacing “unless I serve” with “unless the person who compromised it serves”. That page goes on to say that “Journalists and whistleblowers sharing sensitive information securely” are among the people who this service is intended for.
Do you think it is actually well understood by most people who would consider relying on the confidentiality provided by your service?
Again, I’m sorry to be discouraging here, but: I think you should
drastically re-frame what you’re offering to inform people that it is best-effort and the confidentiality provided is not actually something to be relied upon alone.The front page currently says it offers “End-to-end encryption for complete security”. If someone wants/needs to encrypt files so that a website operator cannot see the contents, then doing so using software ephemerally delivered from that same website is not sufficient: they should encrypt the file first using a non-web-based tool.update: actually you should take the site down, at least until you make it stop sending the key to the server.