Channel Verification Before Bot Can Relay Messages

[ghost]

Here's my idea: Before the Notifico can officially start relaying messages in a channel, a user with +h, +o, +a, or +q must execute a command like !notifico accept to have it relay messages or !notifico deny to have the channel be blacklisted until further notice. This can help prevent spam (I've seen someone use a plaintext webhook to do this) in many channels across the web.

Kind regards, AlphaTech

[jlu5]

I think it should check for op or above just to make sure. Good idea though!

[Dav1dde]

This would need to be extended to !notifico accept [project]. Otherwise you could still send spam to channels with notifico projects.

[ghost]

@GLolol Yes, I could agree on that. Actually, that'd probably be better!

@Dav1dde Of course, that's why I said a command like !notifico accept, great idea!

[TkTech]

I am more or less against this. Instead we should have smarter spam detection, throttling, and an option to flag projects on the UI.

Pros:

• Requiring an op to accept/deny is explicit.

Cons:

• How do we deal with chanop hijacking on netsplits?
• How do we handle halfops and other statuses on networks not following the norm? Is the 005 message sufficient?
• If we force whitelisting, how do we handle inactive sysops preventing notifications for weeks/months? There are large channels on Freenode for example that no longer have active ops.
• Should denies expire? How do we handle ops that leave and someone tries to use notifico 3 years down the road and doesn't get why it doesn't work? (We could probably deal with this in the UI?)
• How do we stop someone just hosting their own copy of notifico, or even a random bot pretending to be notifico, and getting us banned? (This has happened before). If someone wants to abuse it they will no matter what we do.
• I don't want to deal with support tickets. This will probably generate support tickets.

What I would do instead, improving on what currently exists:

• Throttle network-wide messages
• Throttle channel-specific messages across all projects
• Throttle per-project messages
• Throttle account signups per IP
• Throttle account signups overall (if we get 15x the hourly average in 10 minutes someone is clearly scripting it for example)
• Make it very clear to users with better messaging that they're being throttled. Otherwise I'll get support tickets. I hate support tickets.
• Flag projects, hooks, and channels as deleted but delay the actual deletion so admins can review abuse.
• Show the message log, currently only available through redis, on the page for public projects and hidden for private projects.
• Provide a "Flag This Project" option on project pages. Enable volunteer moderators. Manual, but I can't see a way around it. We don't get enough data to make statistical moderation viable. Similar to how cia.vc used to operate.
• Give volunteer moderators more power (flagging, suspending)
• Give admin's easier admin tools in the UI.

Thoughts?

[jlu5]

Cons:

• How do we deal with chanop hijacking on netsplits?

A lot of clients would be affected by a netsplit, not just a Notifico bot. Perhaps ops of a channel should be allowed to remove bots via !deny even after the bot is initially accepted, so the problem could be limited.

• How do we handle halfops and other statuses on networks not following the norm? Is the 005 message sufficient?

I would argue for just ops and above being able to verify something like this, since it's a lot more standardized. I'm not sure I would give trust to !accept/deny access to all halfops in a channel.

• If we force whitelisting, how do we handle inactive sysops preventing notifications for weeks/months? There are large channels on Freenode for example that no longer have active ops.

I don't like whitelisting - manual network signups (e.g. Mibbit, IRC indexers) are tedious and don't solve the problem with duplicate configs being added for one network, unless duplicate checking is separately implemented.

• Should denies expire? How do we handle ops that leave and someone tries to use notifico 3 years down the road and doesn't get why it doesn't work? (We could probably deal with this in the UI?)

If someone tries to add a bot to a channel that has previously been !denyed, it should at least warn them in the webpanel. A delay would be good, but I'm not sure how long it should be.

• How do we stop someone just hosting their own copy of notifico, or even a random bot pretending to be notifico, and getting us banned? (This has happened before). If someone wants to abuse it they will no matter what we do.

There could be instructions somewhere (as in a setup guide) that can tell admins to whitelist Notifico's IPs. Other than that, I don't know.

• I don't want to deal with support tickets. This will probably generate support tickets.

I'm with you here. :fearful:

What I would do instead, improving on what currently exists:

• Throttle network-wide messages
• Throttle channel-specific messages across all projects
• Throttle per-project messages
• Throttle account signups per IP
• Throttle account signups overall (if we get 15x the hourly average in 10 minutes someone is clearly scripting it for example)
• Make it very clear to users with better messaging that they're being throttled. Otherwise I'll get support tickets. I hate support tickets.
• Make it very clear to users with better messaging that they're being throttled. Otherwise I'll get support tickets. I hate support tickets.

Throttle them by how much? This can't be too strict without breaking announcements for bigger networks like Freenode.

• Show the message log, currently only available through redis, on the page for public projects and hidden for private projects.

Being able to see the status of Notifico bots on networks would be a big plus. :+1:

• Provide a "Flag This Project" option on project pages. Enable volunteer moderators. Manual, but I can't see a way around it. We don't get enough data to make statistical moderation viable. Similar to how cia.vc used to operate.
• Give volunteer moderators more power (flagging, suspending)
• Give admin's easier admin tools in the UI.

That's a good idea. I was thinking that perhaps network admins could sign up their networks too. IP/port combinations could be tracked by Notifico to see what network they belong to, allowing admins to monitor which projects have hooks being sent to their network, and remove offending entries accordingly.

[TkTech]

A lot of clients would be affected by a netsplit, not just a Notifico bot. Perhaps ops of a channel should be allowed to remove bots via !deny even after the bot is initially accepted, so the problem could be limited.

Just to clarify here, the problem is that one large networks with more than one server, a netsplit between two servers can result in someone being able to take +O in that channel, completely denying the notifico bot (or use other commands). When the netsplit is resolved, the networks (depending on the IRCd) have a system to collapse and agree on the original and correct permissions. This is one of the biggest reasons I hesitate to use a system that simply relies on +O, even if it is convenient. Most (decent) bots you see require a passphrase or NICKSERV authentication and temporarily authorize a NICK for the duration of its connection.

Also, if this does happen, it must happen in a PRIVMSG. Notifico will never send a non-announcement in channel nor will it ever respond to anything said in a channel.

[jlu5]

Also, if this does happen, it must happen in a PRIVMSG. Notifico will never send a non-announcement in channel nor will it ever respond to anything said in a channel.

Notifico would need a way of communicating with the person who requested it though. Otherwise, non-opers wouldn't know what the bot's nick is.

[ghost]

Perhaps there could be a way to just blacklist a certain project or user from using a channel? If you made it so an IP address could only make for say, one or two accounts max.

[Dav1dde]

Perhaps there could be a way to just blacklist a certain project or user from using a channel? If you made it so an IP address could only make for say, one or two accounts max.

I get a new IP by restarting my router or waiting until the daily reset, so this won't really work.

Another option is the whitelist the IPs who are allowed to access all endpoints. But this would require quite some effort to whitelist every Jenkins, gitlab etc. server accessing notifico, also new users might want to hook with their setup.

Notifico would need a way of communicating with the person who requested it though. Otherwise, non-opers wouldn't know what the bot's nick is.

This could be displayed on the website, which bot instance is currently serving your hook, but since bots only join after a e.g. commit triggered the hook, there might not be any bot on the network.

[TkTech]

Another option is the whitelist the IPs who are allowed to access all endpoints. But this would require quite some effort to whitelist every Jenkins, gitlab etc. server accessing notifico, also new users might want to hook with their setup.

This really can't happen, although it could be an option for self-hosting? Everything from routers to NASA weather balloons (not even kidding) shout out through notifico. Can't only allow whitelists.

This could be displayed on the website, which bot instance is currently serving your hook, but since bots only join after a e.g. commit triggered the hook, there might not be any bot on the network.

And this is intentional - when Notifico used predictable nicks, an abuser on Freenode registered hundreds of Not-001, Not-007, etc... combinations. So the space was expanded to make this neigh impossible.

We really just need better throttling and better moderation tools on the UI before we do anything else. Abusing IRC is absurdly easy, changing the bot itself won't change a thing.