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!
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
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
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?
edit:
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.
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.
I just dropped by, because I am actually developing something similar without Blockstack, see https://pact.online (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.
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 https://www.wired.com/2007/11/519856/. There are some threads about the problem in this forum, but I think there is no good solution yet for the lawful intercept issue.
Thanks for the response. I’m currently using the Web Crypto API (https://www.w3.org/TR/WebCryptoAPI/) 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.