Orbit-db: Flood protection

[MirceaKitsune]

I've been thinking about how to prevent abuse in an environment that's fully decentralized. Particularly how to avoid people spamming a public database with fake entries in order to fill it up and bury legitimate posts. My application may be designed to use the DB in an organized way, but nothing would stop a bad actor from creating a script that inputs a flood of entries.

Although this doesn't help a lot, one mitigation would be flood protection per IP / IPFS client. I was wondering if this is something Orbit could ever support, granted such verification is possible. When creating a database, the owner could specify a timer in seconds... when above 0 no given device may make changes more frequently than that number.

[hazae41]

You could use a blacklist and a custom access controller where you overwrite "canAppend()" in order to not append a message if the user is in the blacklist.

The blacklist could be just a local array, or another orbit-db database.
An user would be added to the blacklist if its behaviour is not okay.

By using a local blacklist, the user would be shadow banned accross multiple peers, and by runoff effect: banned from the whole network (since nobody would add his shit to the database).

By using an orbitdb blacklist, it would be either:

• private: a pool of moderators (by using an access controller on the blacklist itself) decides which user goes into the blacklist, but anyone can check if an user is blacklisted.
• public: a consensus is established between peers when an user needs to be added to the blacklist, but you would end up needing flood protection to the blacklist itself lol.

I think the first option (local) is the easiest and more secure since the flooder itself doesn't know he's blacklisted.

[aphelionz]

Great question @MirceaKitsune and great answer @hazae41. Overall just remember that _any_ logic can be inside a function like canAppend so you could even blacklist by time - one write per 10s or something.

[hazae41]

Maybe orbitdb could add native support for local blacklist?

[MirceaKitsune]

I should learn more about custom access controllers. I was under the impression that if a database is public, anyone can add anything to it. It would definitely be useful to have scripted rules about when someone can edit a database... but would this even be possible to program in a fully decentralized environment?

[aphelionz]

Absolutely possible. It's possible to create both a custom access controller and a custom identity provider. You can see examples of the former here, for example: https://github.com/orbitdb/orbit-db-access-controllers/blob/master/src/orbitdb-access-controller.js

[mohe2015]

Isn't it possible for a user to just generate a new peer id?

You could use a blacklist and a custom access controller where you overwrite "canAppend()" in order to not append a message if the user is in the blacklist.

[hazae41]

Think of a replicated database like a truth: Alice can change her truth, add/remove some facts, but Bob's truth still remains the same, until Bob believes in Alice facts.
So anyone can lie, but the general truth remains the same.

Isn't it possible for a user to just generate a new peer id?

You could use a blacklist and a custom access controller where you overwrite "canAppend()" in order to not append a message if the user is in the blacklist.

He can, but:

• he doesn't know he's blacklisted
• if he does, he will be banned another time (instantly or not, depending on how strict your rules are)

[reasv]

How would you determine if someone is spamming? You can't determine the actual time a post was created, that can be faked easily.
If you implement a timer then there is a problem because whenever you sync existing entries when opening an existing db you will get all entries at once in a short time.
Also blacklisting can be overcome by generating a new identity for each post

[reasv]

I've thought a lot about rate limiting and I just don't believe it is solvable without a centralized rate limiting server or a blockchain/smart contract.
I would love to be proven wrong

[mohe2015]

I think the only (decentralized) way would be something like a Web of Trust which is currently infeasible

[reasv]

I wish this was easily solvable because any public write db is currently trivially DoSable

[hazae41]

I think this could help
https://pdfs.semanticscholar.org/0120/1a9d77687d5e97419ad2b9a4eaf3981a5012.pdf

[mohe2015]

@hazae41 As far as I understand that paper the problem today is that captchas can be solved faster by computers than by humans and for a spammer it would be enough to solve only 1% or so. So I don't think the idea in the paper would work. I still think a web of trust would be the best way but as the paper shows its hard to scale.

[hazae41]

hCaptcha https://www.hcaptcha.com/ works with an AI and an Ethereum token. This is centralized but this is a good compromise.

[aphelionz]

@hazae41 Thank you for sharing that paper!

[hazae41]

@hazae41 Thank you for sharing that paper!

If I remember well, this paper was refenced by Juan Benet https://www.semanticscholar.org/paper/IPFS-Content-Addressed%2C-Versioned%2C-P2P-File-System-Benet/02f1d9f5ec925dee3f5d483585f6beab0660aa0f

[lazyweirdo]

You can always require proof of work to add entries, i have in mind something like coinhive captcha, maybe with custom dificulty, to make it very low if everything goes fine ... if people try to flood the system, well, they are going to be mining for you