Hi ,

Lately, I’ve been working on a small project called deaddrop.space. I’m posting it here because I thought it might be handy to those who care about privacy and control over their data.

It’s a secure, anonymous file-sharing platform built to prioritize privacy, control, and simplicity. Unlike typical services that ask you to sign up, verify emails, or accept endless terms, DeadDrop lets you upload and share files — no accounts, no tracking, no nonsense.

Here’s how it works:

  • You upload a file, set a name, password, expiry date, and max number of downloads.
  • To share it, just provide the recipient with the name and password (or a direct link).
  • Files are encrypted in the browser using AES-256 before they ever leave your device.
  • No raw files or passwords are sent to the server — it’s zero-knowledge encryption.

That means even I, the creator, can’t decrypt or access the files.

BTW, it is open source : https://github.com/Rayid-Ashraf/deaddrop

Would love to hear what you all think — feedback and suggestions are welcome!

      • null_dot@lemmy.dbzer0.comEnglish
        0·
        8 days ago

        Good point. I should’ve read the overview more carefully.

        That being the case, my next question: Is this intended to be a CSAM sharing platform, or is it just naively a CSAM sharing platform?

        • RejZoR@lemmy.mlEnglish
          0·
          8 days ago

          I mean, how do you expect anyone to enforce that? That’s like looking into every envelope or package sent through mail…

          • tobi_tensei@lemmy.mlOP
            0·
            8 days ago

            Look, problems like CSAM can’t be solved just by shutting down the platforms used to distribute it. If one site goes down, they’ll just move to another. Problems like this can only be solved by addressing the root cause. However, on my end, i will do my best to tackle this issue.

        • tobi_tensei@lemmy.mlOP
          0·
          8 days ago

          Absolutely not. DeadDrop is built with privacy and security in mind, strictly for legitimate, ethical file sharing. It’s designed to empower users to share sensitive but legal information safely, not for any illegal activity.

          I do not support or tolerate any use of the platform for sharing harmful or illegal content like CSAM. If such misuse is detected or reported, the file will be permanently deleted and the IP address will be blocked.

            • HATEFISH@midwest.social
              0·
              8 days ago

              Do you have a suggestion on how to combat this while not snooping on a users files? Or are you just enjoying the soapbox?

              • ArcaneSlime@lemmy.dbzer0.com
                0·
                8 days ago

                They’re basically just poo-pooing the ideas of privacy and security, no more than “the government and corporations need access to everything you do because someone somewhere is doing bad things.”

                It’s the same idea as “encryption bad because terrorists,” and “gun company bad because murders,” some people blame the people doing the bad thing, and some people blame the tool used or who created it.

        • iii@mander.xyzEnglish
          0·
          8 days ago

          That’s like sending letters to your water utility to ask them how they intend to stop people from drowning.

    • tobi_tensei@lemmy.mlOP
      0·
      8 days ago

      To be honest, there is not much I can do about it. However, if anybody found any illegal content, He/she can report it to me with name and password. I will verify the file and permanently delete it if their was anything offensive or illegal.

      • null_dot@lemmy.dbzer0.comEnglish
        0·
        8 days ago

        So you’ve built a platform with an ideal use case that you’re absolutely opposed to but have no mechanism to control or even detect.

          • null_dot@lemmy.dbzer0.comEnglish
            0·
            8 days ago

            Have you considered that as the host, you’re the only person who is not anonymous?

            If someone did upload something illegal, and share it with a community, only one member of that community needs to get busted for you as the host to be identified as the “source”.

            I’m aware that in civil cases hosts are liable for the content they host, but criminally? IDK.

            Anyhow, I didn’t intend to dump on your project. I hope I’m wrong and it all goes great. I look forward to being downvoted to oblivion.

                • tobi_tensei@lemmy.mlOP
                  0·
                  8 days ago

                  I want to be very clear: I do not condone CSAM or any illegal activity. DeadDrop is simply a privacy-focused file-sharing service — like many tools that value anonymity, it can be misused, but that’s not its purpose or intent.

                  To your question: I’m not trying to “avoid jurisdiction” — I’m trying to build a service that respects privacy and anonymity, which I believe are fundamental rights. Unfortunately, any privacy tool (from Signal to Tor) can be exploited. The challenge isn’t the tool itself, but how we handle misuse without compromising basic freedoms for everyone else.

                  If we shut down every tool that could be misused, we’d also be shutting down freedom of speech, press, and secure communication. That’s not a solution — it’s just pushing the problem elsewhere.

          • *Tagger*@lemmy.world
            0·
            8 days ago

            But how would you do this if you can’t see in the files?

            Edit: Ah, I see, if they gave you the password.

            Edit 2: You might want to look at local laws. In many places, ‘checking’ to see if there is CSAM is still considered viewing CSAM.

            • tobi_tensei@lemmy.mlOP
              0·
              8 days ago

              Oh boy! Didn’t know about that. But how do other platforms like dropbox, whatsapp and telegram tackle these problems. Don’t they first have verify a content to delete or report about it.

              • Psychadelligoat@lemmy.dbzer0.comEnglish
                0·
                8 days ago

                If you’re in the US our laws would allow you to view the file to check if it does indeed violate the law, so long as you properly delete it and any potential backup of it immediately

                You’re safe from being sued or held liable for hosting it due to the nature of your platform, and the required checking of the content before removal would be allowed (you could also theoretically leave it to the police to send you takedown requests instead, then you don’t even have to subject yourself to the potentially bad material)

                You could also implement some sort of hash scanning against known-bad data, there are datasets of hashes of files you could check against and deny the uploading or auto-delete/report to authorities if you wanted

                • tobi_tensei@lemmy.mlOP
                  0·
                  8 days ago

                  Thanks for mentioning this, I really appreciate it. I will considering implementing hash scanning before encryption to help prevent illegal content.

                • catloaf@lemm.eeEnglish
                  0·
                  7 days ago

                  I would not trust legal advice from a random person on Lemmy. US laws vary by state.

              • Tangentism@lemmy.ml
                0·
                8 days ago

                In the UK, if I opened a page that had CSAM on it but closed it as soon as I realised without opening the images, the fact that my browser has cached that page (with thumbnails) means I’m in possession & could be prosecuted.

                • tobi_tensei@lemmy.mlOP
                  0·
                  8 days ago

                  So with that logic, if a person reports CSAM to police. The police first has arrest the person who reported it. Am I right?

  • Psythik@lemm.ee
    0·
    8 days ago

    10MB upload limit? What year is it? 2002?

    This would be a lot more useful with a more reasonable limit. Say, 1GB per file. I’m trying to find a service I can use to share media.

  • redxef@feddit.org
    0·
    8 days ago

    Hi, nice project. Why would I use your project over similar (open-source) projects like sharry and lufi?

    I personally would prefer to use those alternatives because their source is available and can be reviewed, I didn’t see any reference to your source code - which is fine, but a no-go for me personally.

  • Arthur Besse@lemmy.mlEnglish
    0·
    8 days ago

    Btw, DeadDrop was the original name of Aaron Swartz’ software which later became SecureDrop.

    it’s zero-knowledge encryption. That means even I, the creator, can’t decrypt or access the files.

    I’m sorry to say… this is not quite true. You (or your web host, or a MITM adversary in possession of certificate authority key) can replace the source code at any time - and can do so on a per-user basis, targeting specific IP addresses - to make it exfiltrate the secret key from the uploader or downloader.

    Anyone can audit the code you’ve published, but it is very difficult to be sure that the code one has audited is the same as the code that is being run each time one is using someone else’s website.

    This website has a rather harsh description of the problem: https://www.devever.net/~hl/webcrypto … which concludes that all web-based cryptography like this is fundamentally snake oil.

    Aside from the entire paradigm of doing end-to-end encryption using javascript that is re-delivered by a webserver at each use being fundamentally flawed, there are a few other problems with your design:

    • allowing users to choose a password and using it as the key means that most users’ keys can be easily brute-forced. (Since users need to copy+paste a URL anyway, it would make more sense to require them to transmit a high-entropy key along with it.)
    • the filenames are visible to the server
    • downloaders send the filename to the server prior to the server sending them the javascript which prompts for the password and decrypts the file. this means you have the ability to target maliciously modified versions of the javascript not only by IP but also by filename.

    There are many similar browser-based things which still have the problem of being browser-based but which do not have these three problems: they store the file under a random identifier (or a hash of the ciphertext), and include a high-entropy key in the “fragment” part of the URL (the part after the # symbol) which is by default not sent to the server but is readable by the javascript. (Note that the javascript still can send the fragment to the server, however… it’s just that by default the browser does not.)

    I hope this assessment is not too discouraging, and I wish you well on your programming journey!

    • tobi_tensei@lemmy.mlOP
      0·
      8 days ago

      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.

      • Arthur Besse@lemmy.mlEnglish
        0·
        7 days ago

        TLDR: this is way more broken than I initially realized

        To clarify a few things:

        -No JavaScript is sent after the file metadata is submitted

        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.

        That’s a fundamental limitation of browser-delivered JavaScript, and I fully acknowledge it.

        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.

        The server still being able to serve malicious JS is a valid and well-known concern.

        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. I am deleting your post now; feel free to PM me if you want to discuss this any further.

  • carg@feddit.orgEnglish
    0·
    7 days ago

    Thanks for sharing.

    I did some tests and opened two issues in your github project.

  • drspod@lemmy.ml
    0·
    8 days ago

    Joined 5 hours ago

    Who are you? Even a known and respected cryptographer would not release a tool with such confidence. First you need to request testing and code review before you announce to people that it is a “secure, anonymous file-sharing platform.”

    This is not a community for sharing your personal programming projects for feedback. If you post here, there will be non-technical users who don’t know how to evaluate the security of tools and won’t understand they are taking a huge risk by using your unknown alpha release project.

    • carg@feddit.orgEnglish
      0·
      7 days ago

      Who are you?

      This sounds really aggressive, he’s tobi_tensei, that must be enough.

      Even a known and respected cryptographer would not release a tool with such confidence

      Why not? Do you know about open source? https://en.wikipedia.org/wiki/Release_early,_release_often

      First you need to request testing and code review before you announce to people that it is a “secure, anonymous file-sharing platform.”

      I think he’s precisely asking for testing and code review, announcing the intention of the software is not wrong.

      This is not a community for sharing your personal programming projects for feedback

      Why not? It is related to privacy, it can be the seed for bigger projects, the author is sharing the code so you can evaluate and host yourself.

      What a strange way to say “thanks for sharing”.

      So, I’m going to try to say it better:

      Thanks @tobi_tensei for sharing that code in the open source, please don’t stop your initiative for people criticizing, there are more people that likes and are thankful.

    • tobi_tensei@lemmy.mlOP
      0·
      8 days ago

      Fair point — I should’ve been more careful with the wording. I’ve open-sourced the code exactly so that people can audit, test, and critique it. I don’t expect blind trust, and I’m not claiming it’s perfect, just that I built it with privacy in mind.

      If you have concerns, I’d genuinely appreciate feedback or a review. My goal is to improve it, not just promote it