Zncdefense

====== ZNC Bad ======

- ZNC requires one connection per network. If a user wants to connect to 10 networks at once (freenode, ircnow, dal, efnet, etc), it requires him to set up 10 independent connections on his IRC client. This is almost impossible with mobile apps and very confusing for GUI apps. Practical experience has shown that <30% of bouncer users know how to do this. If you rely on ZNC, you will lose >70% of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it.
- EDIT: While this remains true for mobile apps (and at least to a degree for cli) it depends upon the
specific client whether the GUI makes this task easier or harder. Source for the "practical
experience"? There are PLENTY of people using ZNC today
- ZNC has invented the most confusing way of logging in. If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. Nowhere have I ever seen such a weird and confusing way of changing networks. Nobody understands this until he has spent 1-2 hours of troubleshooting.
- EDIT: this system is actually not hard but rather simple as it allows uniquely distinguishing which
network(s) to connect to. The fact that also the network name must be spelled in the same case
sensitivty (i.e. ircnow vs IRCNow would be seen as different networks) is indeed confusing though.
The reason given was that it is part of the server password (PASS) and thus case-sensitive (since
passwords are). This aspect could indeed use improvement (also username has the same issue)
Nobody is an absolute statement and following the instructions on the ZNC wiki shows in
elaborated ways that it is handled this way.
- ZNC is not designed for casual users. It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. You have jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.
- EDIT: True when using the IRC /msg *module_name_here version that requires an easier interface.
Although most just use the webadmin panel which is very self-explanatory and when clicking a
module it opens the respective wiki site with simple instructions and examples on how to use it.
- ZNC relies on a web panel. There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.
- EDIT: It has themes that can apparently be used without recompiling, example:
https://github.com/catlinman/hivecom-znc . True that the UNIX philosophy is not followed, yet in
the point above it was stated that the IRC configuration is too difficult for regular users, thus the
webpanel exists so that casual users can easily change options as well. In most cases, ZNC is self-
hosted making (the only) user also the sysadmin (most bouncer providers closed down).
- ZNC is written in C++, an ugly and inelegant language.
- EDIT: While it is written in C++ indeed, this appears to be rather subjective language bias,
labeling it "ugly" and "inelegant". Real-life benchmarks needed for verification.
- ZNC throttles users when you first start up ZNC and connect everyone. However, the throttling is done in a very stupid manner -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!
- EDIT: True, although when a shared service is in play, most likely many networks will be
common/the same, thus a throttle is necessary as otherwise too many users connect to the same
network at the same time. 1000 users all connecting to freenode at once from the same address
would VERY likely get removed from the network. Improvement necessary though indeed for fully
unique networks.
- If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90% of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.
- EDIT: True. It appears despite making changes to how SSL verification operates, there is still no
way to bypass the abovementioned issue which requires significant improvement.
- This same error also occurs when our bouncers are GLINEd. Again, ZNC stupidly tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.
- EDIT: Lack of own experience due to never self-hosting but true with verified benchmarks.
- ZNC chose to adopt IRCv3, a terrible protocol because it adds nothing of value to users but introduces a lot of bugs. We have documented that older versions of mIRC (from around v7.33 to 7.41) are unable to connect because either mIRC or ZNC improperly implement IRCv3 capability negotiation. This bug has also been observed with some other Mac and Android IRC clients. What is worse is that nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation. We are able to reproduce this bug.
- EDIT: Personal bias against IRCv3 as it has improved the IRC experience (see account-notify
chghost extended-join multi-prefix userhost-in-names for some of the more useful specifications).
While the connection issues remain true, this can be bypassed by simply updating clients to a
current version, also most mobile clients are lackluster in quite some aspects. If users refuse to
upgrade mIRC because they wish to use a pirated version instead, this should infact NOT be
supported by IRCNow, as otherwise it is seen as acceptable to use pirated software. Mobile clients
infact need a significant repolishing.
- ZNC has no way of supporting both IPv4 and IPv6 simultaneously while preferring IPv6 when available. If you want to prefer IPv6, you are forced to drop support for IPv4 (you are therefore unable to connect to IPv4-only networks). If you choose to support both IPv4 and IPv6, znc usually chooses IPv4 by default, rather than using IPv6 by default. This is a design flaw. The default should be IPv6, then fallback to IPv4.
- EDIT: First part badly worded as the 2nd part does state one can choose to support both. True
that IPv6 should be the default, this is indeed a flaw requiring fixes.
- ZNC nickserv module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv module should instead adapt to each IRC network so that users do not have to memorize the idiosyncrasies of every single network's services. For example, for ngircd, the proper command is /squery nickserv identify <password>; for DALnet, the proper command is /msg nickserv@services.dal.net identify <password>. This really does not need to be an optional module; it needs to be integrated into the bouncer.
- EDIT: Out of the majorly used IRCds, ONLY ngIRCd lacks services aliases due to the developer
(FALSELY) assuming they should be implemented client-sided. DALnet's ns cs etc are all server-
sided aliases which can be observed by studying Bahamut's reference.conf. Only ngIRCd sticks out
of the crowd negatively thus that IRCd should be fixed, uniquely adapting to over 60+ IRCd's in
unfeasable for ANYONE. (citation of IRCd's: someone counted them once apparently heh)
- ZNC does not offer users any way to download their chat logs. It has a chat log module which stores the chat logs on the server hard disk -- but how is a user supposed to fetch these logs? Unless you give every single user on your bouncer ssh access, you are forced to manually email them. A hideous solution.
- EDIT: True. This requires a better system indeed.
- Requesting a ZNC account using a web registration form or a bouncer bot is an ugly hack. Users should be able to register an account instantly upon first connection.
- EDIT: "First" connect would have to be fingerprinted quite strongly to not get duplicates,
something not all providers would have the resources/capabilites etc to do. Good idea nontheless
though.
- ZNC bundles the shell module by default, a module which makes it easy to exploit a 0day to get shell access to the entire server. It is impossible to delete this module. I complained about this to #znc on freenode and was told by that this was the least of my worries. This goes to show that znc developers do not care enough about security.
- EDIT: True although not loaded by default, the sysadmin(s) would have to willingly load it.
- ZNC's Partyline module is buggy when users are connected to multiple networks. Often, messages repeat 2x or more, and sometimes it causes the users to join strange channels without requesting it. This otherwise useful module has been dropped starting v1.8, so we will need to switch to psyBNC to keep it.
- EDIT: Likely true (lack of self-testing). Perhaps the source could be obtained and cleaned up?
- There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC.
- EDIT Likely true (lack of self-testing). Debug being available via a /msg *status should be available
for example
- ZNC's blockuser module may be buggy. I have not verified this with certainty, but I suspect that if you send a reconnect message to the *controlpanel, it may connect sometimes even if a user is blocked.
- EDIT: Possibly true, requires further testing
- Chrooting ZNC is a horrible, ugly hack.
- EDIT: Possibly true (lack of knowledge and experience with chroots to give a qualified statement)
- A commonly requested feature is to be able to use ZNC for both mobile phone client and PC IRC client. Here's the ZNC wiki explaining how you have multiple clients. Did you understand that? Neither did I. This setup is too complex and confusing for normal people to follow.
- EDIT: Personal bias as the author themselves stated they (alone) cannot foolow the guide. The
given pastebin gives simple copy-paste instructions to follow. Also this guide is only needed if
both devies are used AT THE SAME TIME.
- ZNC developers most likely have no interest in fixing any of the above design flaws. And even if they did, you'd be at the mercy of their development team, which may take years before they fix it. You are better off forking the code yourself.
- EDIT: True it is up to the dev team, but that is the case with any software in the end. Possibly true
if they do not perceive the above points as flaws.
- ZNC modules often fall into the category of 1) useless or 2) proprietary software. For example, the ZNC Push Notifications module is proprietary software. There is no open source push notifications for ZNC, but this feature is essential for a proper mobile IRC client.
- EDIT: True regarding 2) but no quote given for 1)

ZNC is only 50% of the way there to a good bouncer. We chose it because it is more polished than psyBNC currently. psyBNC is only 30% of the way to a good bouncer. However, the problem is that znc is going on the wrong path, and will never straighten its course because of the above mentioned design flaws and a stubborn development team. psyBNC, however, is abandonware so we can mold it to fit our own goals.

====== psyBNC Good ======

  - Written in C, a UNIX hacker's best friend.
  - EDIT: True.
  - psyBNC can multiplex multiple network connections onto a single connection, so that users only have to connect to psyBNC once to access all networks. If a user chooses to connect to 200 networks using psyBNC, his IRC client only has to connect once to psyBNC. This is a lot more intuitive than logging in 200 times.
  - EDIT: What if the user only wishes to connect to 1,2,3 networks and not all at once? this could 
   also lead to significant client lag or even crashes connecting to 200 networks (with many channels 
    in each) at once.
  - Instead of chroot, we can use OpenBSD's pledge and unveil for greater security.
  - EDIT: Most likely true (lack of knowledge/experience to give a qualified statement)