View Issue Details

IDProjectCategoryView StatusLast Update
0006285unrealircdpublic2023-09-17 12:00
Reporteracidvegas Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Summary0006285: More ways to control reputation
DescriptionI noticed #define REPUTATION_SCORE_CAP 10000 is the hardcoded cap for reputation. I think this should be a configurable feature as it is not hard to idle on a network long enough to get 10000 reputation, even with clones. Would also allow for more customization on making a security group for "long time chatters".

Another idea is the ability to reduce a clients reputation over time if they have not sent any data to the server in x amount of time. After that x amount of time, the reputation can go down by x amount every z(days,hours,etc).
TagsNo tags attached.
3rd party modules

Activities

acidvegas

2023-06-21 03:15

reporter   ~0022919

Allow giving only +1 reputation for authentication seems petty. Maybe the ability to control more options, like if connecting from ssl +50 rep, if authenticaed, +100 rep, etc.

BlackBishop

2023-07-03 09:20

reporter   ~0022938

Trying to test some functionality for unknown-users today got me to a point where I wanted to delete the reputation for an IP and found out I can't.

syzop

2023-09-09 12:03

administrator   ~0023029

10000 takes 17 days of (24/7) connect time if it is a registered user, or about a month if you are not a registered user. I think that is plenty, really :). What is there to gain if it needs to be like 30 days instead of 17? The benefits are completely marginal IMHO. It's like.. after a certain threshold there is not much to gain anymore.

The reducing of reputation is an idea but it comes with a bit of a problem: "what is traffic" ? Private messages? Public messages? Don't you think bad people would just privmsg each other or random channels just to get around this? I think so, and then it is only just real users at which the reputation would become low. And for what... ? They are not the threat, and reputation is used to differentiate mostly between good and bad people. The bad people would still maintain their rep.

What has been suggested before is resetting reputation to 0 upon a kill or gline. I think it was Jobe who suggested that. The idea is not itself bad, but what if you accidentally kill half your network? Then you just got rid of almost all reputation without an easy way to restore. And while itself it does not sound like a bad idea, what is there to gain actually? The person is killed/*lined, so why care about the reputation still?

syzop

2023-09-09 12:27

administrator   ~0023030

And yeah for testing we could add/do something of course. I test myself as well via third/fakereputation (not ircop only, really only for testing).

Valware

2023-09-09 18:44

reporter   ~0023032

I think it would be a good idea to have a configuration setting which allowed you to configure what the network deems to be reputable behaiour; perhaps set reputation reduction values to each kick/kill/gline, maybe have a way so the admin can define reputation addition values in the same way.
Additionally/Alternatively, how about some more commands so that those with a certain operclass priv can change/clear reputation.

I can see with why someone might want to create a bot or other tool to manage a users reputation based on what the (individual) network deems to be reputable behaviour instead of automated by the server, but that would still need regular clearups of old entries... In such a case, you could just make a bot to handle a separate reputation system, but then you lose out on things like extbans and other security measures which may (or may not) be improved by fine-tuning it to the network case.

I can also think of

I can see the argument that being connected doesn't itself constitute reputable behaviour, but at the same time it is very quick and easy and pretty much does *just work* when it comes to, for example, stopping a botnet using open proxies (with zero reputation) (one could argue there are different ways of achieving the same effect). Still, in such cases, limiting by reputation here is a very easy counter-measure and works considerably well, in most cases.

I can still see a usefulness in giving more control about reputation to the oper, while still keeping it as-is for default behaviour since it *does* work well.

acidvegas

2023-09-13 00:33

reporter   ~0023035

"What is there to gain if it needs to be like 30 days instead of 17?"
Because, more features & controls = better. Look at how successful weechat is as an IRC client. It's because you can configure EVERYTHING.
Because some people might want to declare someone as "reputable" for longer times than what YOU think is enough.
Not everyone runs their IRC the way you expect them to.

syzop

2023-09-16 09:30

administrator   ~0023037

Last edited: 2023-09-17 08:22

(Shortened to be on-topic again) I'm renaming this issue to "More ways to control reputation", which as a consequence will also give the option to reduce. I don't know if it will be in 6.0.2 stable already since we are in RC stage for that, but it will be worked on.

Also thinking of some ways to improve the default, like I don't think it is good to increase reputation of users who are in no channels. I'm thinking of a requirement to be in a channel, or even better: requirement to be in a channel with a minimum set of channel members, and then making that configurable. Like... needing to be in any channel that has 5 members of more, for example (and only then you get reputation increased). The reason for the minimal member count is that otherwise bots just join their own bot channel (which they may or may still do, but then it becomes more visible to ircops). Of course you want that channel member amount tweakable, since such a requirement will vary by network. Some networks will have all kinds of small networks where people tend to be only in those, and (more often) you will have the usual case where people are in at least one big(ger) channel. Still, maybe leave some users like bots that are only in some smaller channel but not in a larger, but... hopefully they will be in large enough channels... well.. that would be something you could play with tweaking i guess. (Feedback welcome on this idea)

As for the big feature, I'm thinking along the lines of using mask/crule for selectors and then applying actions:

set {
        reputation-score {
                timer {
                    adjust {
                            mask { identified yes; }
                            score 1;
                    }
                    adjust {
                            mask *; // or just omit mask altogether
                            score 1;
                    }
                    // do not increase reputation score if this matches... or.. what do we do?
                    prevent {
                            rule "!inchannel_min_users(2)";
                    }
                }
        }
}

It's wrapped in a timer subitem because those are evaluated every 5 minutes, like now.

Then we can have a different (sub)block for other "actions", to allow decreasing or resetting on KILL and things like that:
set {
        reputation-score {
                kill {
                        adjust {
                                ...reset reputation score to something...
                        }
                }
        }
}


The above is a mockup/idea. Obviously the name of the config directives can/will be changed, and the syntax will probably be more like +1 and support like set to =1 and/or similar to what we have in the new action::set in 6.1.2 and the like.

syzop

2023-09-17 10:12

administrator   ~0023038

Last edited: 2023-09-17 10:15

Doing some initial work on this.

We already have set::reputation it seems, so stick with that, and not set::reputation-score.

I just committed a change so via actions you can set reputation scores, so that is possible via spamfilter and other places where actions are used.

Also added the ability to decrease reputation in server to server traffic, this is something that was previously not supported and will not work properly on servers before 6.1.2. That's because of the "highest score" wins principle in the syncing code, which is meant to keep scores the same and specifically for the case where new servers are linking in and don't have a score entry (or lower entry)... blablablablal anyway you can now decrease scores :D

So for the new settings block i am thinking:
set {
        reputation {
                timer {
                    adjust {
                            mask { identified yes; }
                            action { set REPUTATION++; }
                    }
                    adjust {
                            mask *; // or just omit mask altogether
                            action { set REPUTATION++; }
                    }
                    // do not increase reputation score if this matches... or.. what do we do?
                    prevent {
                            rule "!inchannel_min_users(2)";
                    }
                }
        }
}


Then we still have that other idea, of like doing something on-KILL and other commands.

Because of the various names/block-items in the reputation block already i don't think we should just use "kill" but prepend it with something.
I'm thinking "victim kill" or "target kill". I don't think something like "action kill" or "command kill" is a good idea because then it may not be clear if it is the issuer or the victim being affected. I mean, it is obvious for the kill case, but if all this functionality gets expanded then it may no longer be clear for other commands so it is better to think ahead of this (like i dunnow, privmsg, though that is not a great example). I'm going for "target" here since that is the more general term, with "victim" being a subset of it. We also use "target" in the JSON-RPC and logging variables so it is already known from there.

set {
        reputation {
                target kill {
                        adjust {
                                action { set REPUTATION=0; }
                        }
                }
        }
}

syzop

2023-09-17 10:13

administrator   ~0023039

Oh yeah and you can now set reputation via REPUTATION <nick|ip> <value>
The same caveat when lowering scores applies, the one that is mentioned above.

syzop

2023-09-17 11:53

administrator   ~0023040

Last edited: 2023-09-17 12:00

Commit https://github.com/unrealircd/unrealircd/commit/b234e13358eb3cda5ab2cf489c7121f475caf410
commit b234e13358eb3cda5ab2cf489c7121f475caf410 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD)
Author: Bram Matthys <[email protected]>
Date:   Sun Sep 17 11:41:31 2023 +0200

    Don't bump reputation scores anymore for users who are in no channels or
    when they are only in channel(s) with very low member counts.
    
    This because some typical bot/drone behavior is not to join any channels.
    This kinda forces them to expose themselves a bit more (and if they don't,
    they don't get more reputation).
    
    The downside is for the unusual case where a legit chatter would be on
    the network but not joining any channels, but that is rare. In any case,
    this setting can be adjusted if that is typical or more normal behavior
    on your network :D.
    
    * The [reputation score](https://www.unrealircd.org/docs/Reputation_score)
      of connected users (actually IP's) is increased every 5 minutes. We still
      do this, but only for users who are at least in one channel that has 3
      or more members. This setting is tweakable via
      [set::reputation::score-bump-timer-minimum-channel-members](https://www.unrealircd.org/docs/Set_block#set::reputation).
      Setting this to 0 means to bump scores also for people who are in no
      channels at all, which was the behavior in previous UnrealIRCd versions.


And this is the latest version of the idea:
set {
        reputation {
                // XXX In some future version:
                score-bump-timer {
                    adjust {
                            mask { identified yes; }
                            action { set REPUTATION++; }
                    }
                    adjust {
                            mask *; // or just omit mask altogether
                            action { set REPUTATION++; }
                    }
                    // do not increase reputation score if this matches:
                    except {
                            rule "!inchannel_min_users(2)";
                    }
                }

                // and in the meantime, at least offer this one simplified:
                score-bump-timer-minimum-channel-members 3;

                // XXX In some future version:
                // if the user is the target of something, then
                // we can adjust reputation:
                target kill {
                        adjust {
                                action { set REPUTATION=0; }
                        }
                }
        }
}

Issue History

Date Modified Username Field Change
2023-06-21 03:11 acidvegas New Issue
2023-06-21 03:15 acidvegas Note Added: 0022919
2023-07-03 09:20 BlackBishop Note Added: 0022938
2023-09-09 12:03 syzop Note Added: 0023029
2023-09-09 12:03 syzop Assigned To => syzop
2023-09-09 12:03 syzop Status new => feedback
2023-09-09 12:27 syzop Note Added: 0023030
2023-09-09 18:44 Valware Note Added: 0023032
2023-09-13 00:33 acidvegas Note Added: 0023035
2023-09-16 09:30 syzop Status feedback => acknowledged
2023-09-16 09:30 syzop Summary Control reputation cap & options to reduce reputation => More ways to control reputation
2023-09-16 09:30 syzop Note Added: 0023037
2023-09-16 09:32 syzop Note Edited: 0023037
2023-09-16 09:38 syzop Note Edited: 0023037
2023-09-16 09:52 syzop Note Edited: 0023037
2023-09-17 08:22 syzop Note Edited: 0023037
2023-09-17 10:12 syzop Note Added: 0023038
2023-09-17 10:13 syzop Note Added: 0023039
2023-09-17 10:15 syzop Note Edited: 0023038
2023-09-17 10:15 syzop Note Edited: 0023038
2023-09-17 11:53 syzop Note Added: 0023040
2023-09-17 11:56 syzop Note Edited: 0023040
2023-09-17 11:56 syzop Note Edited: 0023040
2023-09-17 11:59 syzop Priority low => normal
2023-09-17 12:00 syzop Note Edited: 0023040