Libera-Chat / cloaks

bot for automated user cloaks
MIT License
7 stars 4 forks source link

always put FORCE on VHOST ON #2

Closed jesopo closed 2 years ago

jesopo commented 2 years ago

somewhat randomly chosen reviewer to get an opinion!

glguy commented 2 years ago

Can we have a different mechanism to prevent a cloak from being applied? Do we need one?

jesopo commented 2 years ago

I couldn't think of any reasons in which that would be necessary. someone bad could make a new account to get a cloak

AbstractBeliefs commented 2 years ago

perhaps cloak-on-join if uncloaked, otherwise send a pm asking for confirmation and FORCEing on anyone who says yes?

skizzerz commented 2 years ago

So I gave some thought on reasons why we might want to withhold a cloak from someone:

  1. Can be used to evade IP-based bans in a channel
    • Ban evasion is a network policy violation and staff can see through cloaks to issue k-lines as necessary
    • The user could simply register for a different account once they realize the cloak bot isn't working for their current one
    • A channel op could set an account-based ban or akick instead of a hostmask/IP-based one
  2. It's a known alternate account of someone else
    • Is this a good reason for withholding a cloak?
  3. It's a restored mark that is no longer relevant
    • By having them manually ask for a cloak, we can evaluate and delete the mark at the same time as cloaking them

Of those, I think point 3 is the only one without a strong mitigation currently, but it is not an insurmountable problem. Are there any other reasons I've missed?

Code-wise this looks fine (very straightforward change) but it'd be good to get some sort of idea of whether or not there are any problems. As for @glguy's question, right now we can +b such users from #libera-cloak to prevent them from receiving cloaks even if the bot makes use of FORCE.