1

I have a specific use case for orbit-db but I am a bit fuzzy about a certain security implication.

I'm developing a web app where a user logs in through a Tronweb wallet account.
People can post questions, whereas other people can answer them and get paid for it.
In order to do so, I add the public key of the respondent to the question and save it to Orbit db.

Now it is my understanding that default access to any orbit-db instance is given to the app (identity) that creates it per default, or you can add custom access controllers. Let's say, if I want to create a db to manage tags, I could create an identity based on my own tronlink account and require a login to create those tags. Nobody else would be able to access that db.

Now what I am a bit fuzzy about is what happens when:

An OP creates a question, and a respondent registers an answer.
When the OP accepts the answer, and payment through the Tronlink plugin will be executed.
But since OrbitDB can run without a server (i.e. p2p based on a local IPFS node), what prevents anybody to set a breakpoint in the client-side Javascript code, get a handle to the db instance, and execute an update call to update the respondent's address locally in that question document, after which it will be synced to other nodes?
I store the public key of the respondent in orbitdb, but the transaction is still confirmed by the OP through Tronlink wallet plugin of course. But still, you cannot assume all users to check it every time.

Since there is no server involved, I don't see how you can prevent corruption of the db client-side by unwanted parties.
Could you enlighten? Let me know if my question is not clear.

html_programmer
  • 18,126
  • 18
  • 85
  • 158

1 Answers1

0

what prevents anybody to set a breakpoint in the client-side Javascript code, get a handle to the db instance, and execute an update call to update the respondent's address locally in that question document

Nothing.

after which it will be synced to other nodes?

This is what makes OrbitDB secure. Each document that is synced to a new node, needs to pass through the validator function of this node. So, honest (the ones that have a correct AccessController) nodes will filter out malicious changes.

What that means? A node can be "corrupted" but it can't "corrupt" other nodes in the network.

Christos Panagiotakopoulos
  • 793
  • 4
  • 15
  • Hm perhaps I'm missing something. But if you get a handle to the db, you get effectively the db instance created by your script in the first place. By default there is only one identity, the script that creates the db when it gets executed on opening the db. Every user of the website would run their own IPFS node in the browser (correct?). I mean, there is no 'real' validation that the user is updating his/her own post, they could virtually update any post in the db through the breakpoint, under the identity of the script that creates the db. Let me know if you see this differently. – html_programmer Sep 15 '21 at 17:42
  • I mean you can't say that a docstore update is permitted, while at the same time saying it is not... the access controllers merely appears to allow identities to administer a database, just like the original script does. It doesn't appear you can really implement any kind of authorization saying: only you can update the post because you are the one who created it before. It works with a server because you aren't supposed to be able to break into it; on the client however it seems perfectly possible. But do tell me if you think this is wrong and why. – html_programmer Sep 15 '21 at 17:49
  • Of course, anyone can perform any kind of wrongdoing inside Orbit. They can manipulate every piece of data inside it, and make any change without any authorization. But this change will only stay on their computers. It will not propagate into the rest of the network because no other *honest* node will accept it. That's what you are missing. So, although a malicious client can perform illegitimate operations, no other non-malicious client will see those operations. – Christos Panagiotakopoulos Sep 16 '21 at 15:08
  • But I *want* the user to be able to update certain documents they own and propagate this change to other nodes. Just only the ones that belong to them, **not** the other. From what I see, it's not possible to safely make an update to a document that one user created, without it including that this user can update *any* document. – html_programmer Sep 16 '21 at 19:59
  • It's not clear to me; currently I decided to go with a standard Java backend for my app and use a regular database. It doesn't feel like the risk is worth it. I'm still going to use a crypto wallet at the client for transactions. – html_programmer Sep 16 '21 at 20:04