Anonymous, Secure FileDrop Proof of Concept using BlockStack

Hi all,

Censorship on the internet is a major problem and decentralised applications are one of the only ways to fix it.

Using BlockStack, I put together proof of concept for sharing files for completely free.

  1. It is completely anonymous. No username is required
  2. You can upload files of any size
  3. When the secure drop checkmark is used, the files will be encrypted. There is no additional password. All of the keys are encoded in the URL.

Although only proof of concept, it is 100% safe and ready to be used by whistle blowers

The demo is here:

To see an example file, see here:

Feel free to copy the source code and use it however you want. I am not a UI person, so if someone wants to clean it up that would be great.

So basically if I understand your logic correctly…

You are simply providing a frontend for getting/putting files on Blockstack PBC’s AWS storage via their GaiaHub, encrypted or otherwise? It’s quite simple but I’m not sure this solves anything, really.

I also don’t see any authentication nor pivate/public keys or blockstack initialization, so I’m not entirely certain what’s going on. Do you think you could explain more your reasoning behind making this, how it works, and what it actually accomplishes? Thanks!

Thanks kindly for taking a look!

It is very simple, since the APIs BlockStack has put together are very powerful. The main accomplishment is completely anonymous, encrypted file sharing.

This is ideal for whistleblowers who want to avoid censorship and I do not think this has been demonstrated yet with BlockStack.

There is no user authentication as there are no user names. A random key is generated securely using the BlockStack APIs. The key is passed along in the URL for the people who are to receive the files

1 Like

On a personal note, I heard about BlockStack from watching the amazing interview with Edward Snowden so I thought to make a project to help whistleblowers like Ed

Hey Igor, interesting project. I have a thing for drag and drop that’s probably lingering from the '90s, so maybe I’m positively biased here :joy:.

I tried it out and wanted to do an encrypted drop, so I checked ‘encrypted drop’, dragged a file in and got this share link:

When I d/l the file in the link, it’s plain text. So I’m a bit perplexed about how the encryption part works or how to work the encryption part?


2nd cup of coffee just kicked in after re-reading your post–the key is in the URL. So it’s encrypting the file and storing it in GAIA–then when the key is passed into the request, it uses that to both lookup and decrypt the file?

I just took a dive into the code and I think I’m still confused. You’re using the Blockstack putFile method, but whose gaia hub is this being stored in if you are not requiring authentication. Don’t get me wrong, I see the value in this, but I just want to make sure I’m understanding how it works.

1 Like

Like every blockstack app, it is simply a proof of concept, so it is using default gaia hub. I think there are some not well veiled concerns here about using the default azure gaia hub for file storage, but during development phase it is the right choice for now i think – and most dapps right now are relying on the default azure storage. In the future paying with stacks to store is maybe required for whistleblowers to upload documents.

I need help with UI to make this nicer if someone is interested.

I should say instead that almost all dapp users are relying on default azure gaia. If you are wondering which user the data belongs to, the user is securely, randomly created by the page each time you load. The URL holds the secret keys for getting access to that user’s data.

1 Like

I just dropped by, because I am actually developing something similar without Blockstack, see (based on IPFS and IOTA). I just heard of Blockstack for the first time, so I will definitely look into this in more detail. Maybe we can learn from each other.

A quick note (because I also tried something similiar): never put secrets into URLs, see

That’s what I was asking, thanks!

Note that instead of URI parameters, the state is passing through fragment identifiers. Servers will not see this. However, fragment identifier remain in browsing history, something to be aware of.

One thought is about embedding the whole website in a fragment identifier actually, so that the website can be redistributed permanently as a data: uri. Making the website “final”, with a very well known singular hash, and easy to distribute, would be one way to really work against the intercept problem.

The main weakness right now is the ability of law enforcement to do an intercept of any server which would host the website. is what happened with Hushmail, where canadian authorities intercepted the website to get encryption keys to take down a carding kingpin. See the emails here There are some threads about the problem in this forum, but I think there is no good solution yet for the lawful intercept issue.

One comment about pact: are you sure IOTA is a good choice? They seem to not have clue what they are doing. What are you thinking to use for encryption?

1 Like

Thanks for the response. I’m currently using the Web Crypto API ( for the encryption, so everything is encrypted (AES256-GCM) in your browser before it’s even uploaded to IPFS. IOTA is currently only used for the logging system. The vulnerability is fixed and also didn’t lead to any real world security issue, but the current system doesn’t depend on the IOTA encryption anyway.