I'm still trying to get a handle on the security aspects of gun. Say you want to create a blog/note app - that holds both private notes, drafts - and things that are to be shared to some friends.
Would you effectively have to store data encrypted in gun, and manage access via sharing encryption keys - in order to be able to both securely store data, and share it?
In the examples, it appears things like "create user" is called in client side code - which seems to imply anyone can write any data to a gun db? (by adding themselves as admin?)
Is the use-case of gun more a public, structured wiki - where all content is fundamentally untrusted - but easily updated by anyone?
So we do have an unstable API that automates key management and key sharing, but all production apps (notabug.io , etc.) today directly use our https://gun.eco/docs/SEA shim over WebCrypto.
Unfortunately, that means you have to be aware of how to apply it - thankfully, we did make a cartoon cryptography crash course on this (in link), so it is viable to get started.
Obviously, if you have any new insights, would love to hear it!
Without SEA, gun is very much like what you say. With SEA, you can protect against just anyone randomly writing to GUN. Jump in and ask more Qs on https://gitter.im/amark/gun about it, or you'll circle back around later - hopefully that is helpful directions?
Thanks. Most important statement of mine: I bet you'll enjoy the cartoon cryptography series.
Thanks for replying. I guess:
https://gun.eco/explainers/data/summary.html
sums up the situation - but there's a few things that aren't quite clear: by design, everyone can access all encrypted data? So there's some meta-data that's easy to find, such as checking if an account exist, and how much data is associated with it - and the ability to record the approximate rate that data is written to the account?
For example, if the login is an email, the app is an exercise logger - I might be able to infer that someone is out jogging by looking at the data?
"Distributed - GUN is peer-to-peer by design, meaning you have no centralized database server to maintain or that could crash. This lets you sleep through the night without worrying about database DevOps - we call it "NoDB". From there, you can build decentralized, federated, or centralized apps."
And then goes on to show how to boot an instance on heroku etc. But is a production setup documented anywhere? I'd assume one would want three server instances (to allow taking one down for upgrades) - to make sure clients can write data to a managed instance, in order to make sure data is backed up etc?
Apologies if I've overlooked an obvious documentation link.
Yes, can I follow up with you more on this later / in the chatroom[1]? I don't want to leave you hanging but won't be able to reply in detail for probably 1 week - but I do have an answer for you (I apologize the docs are slacking!).
Comments
Hi, thanks for stopping by :)
I'm still trying to get a handle on the security aspects of gun. Say you want to create a blog/note app - that holds both private notes, drafts - and things that are to be shared to some friends.
Would you effectively have to store data encrypted in gun, and manage access via sharing encryption keys - in order to be able to both securely store data, and share it?
In the examples, it appears things like "create user" is called in client side code - which seems to imply anyone can write any data to a gun db? (by adding themselves as admin?)
Is the use-case of gun more a public, structured wiki - where all content is fundamentally untrusted - but easily updated by anyone?
Right back to you! :)
That is probably because I've done a poor job communicating it, since I'm still finding time to write about it. Thank you for bringing this up!
Probably most relevant: I kinda sorta had a demo of a P2P LinkedIn working https://www.youtube.com/watch?v=ZiELAFqNSLQ .
So we do have an unstable API that automates key management and key sharing, but all production apps (notabug.io , etc.) today directly use our https://gun.eco/docs/SEA shim over WebCrypto.
Unfortunately, that means you have to be aware of how to apply it - thankfully, we did make a cartoon cryptography crash course on this (in link), so it is viable to get started.
Obviously, if you have any new insights, would love to hear it!
Without SEA, gun is very much like what you say. With SEA, you can protect against just anyone randomly writing to GUN. Jump in and ask more Qs on https://gitter.im/amark/gun about it, or you'll circle back around later - hopefully that is helpful directions?
Thanks. Most important statement of mine: I bet you'll enjoy the cartoon cryptography series.
Thanks for replying. I guess: https://gun.eco/explainers/data/summary.html sums up the situation - but there's a few things that aren't quite clear: by design, everyone can access all encrypted data? So there's some meta-data that's easy to find, such as checking if an account exist, and how much data is associated with it - and the ability to record the approximate rate that data is written to the account?
For example, if the login is an email, the app is an exercise logger - I might be able to infer that someone is out jogging by looking at the data?
Another, related, question: at https://github.com/amark/gun/blob/master/README.md we can read that:
"Distributed - GUN is peer-to-peer by design, meaning you have no centralized database server to maintain or that could crash. This lets you sleep through the night without worrying about database DevOps - we call it "NoDB". From there, you can build decentralized, federated, or centralized apps."
And then goes on to show how to boot an instance on heroku etc. But is a production setup documented anywhere? I'd assume one would want three server instances (to allow taking one down for upgrades) - to make sure clients can write data to a managed instance, in order to make sure data is backed up etc?
Apologies if I've overlooked an obvious documentation link.
Yes, can I follow up with you more on this later / in the chatroom[1]? I don't want to leave you hanging but won't be able to reply in detail for probably 1 week - but I do have an answer for you (I apologize the docs are slacking!).
Thanks / sorry!