Why Atheme no longer works with InspIRCd when m_invisible is loaded

As of a couple of days ago, we put some checks in designed to block casual usage of the m_invisible module in InspIRCd on Atheme-running networks.  As certain InspIRCd contributors view this is a troll, I would like to explain why we are in fact quite serious about this.  The remainder of this post will be split up into two sections, explaining why m_invisible is morally unacceptable, and why m_invisible is impossible to enforce in Atheme anyway without complicating the code base extensively.  The remainder of the post after that will include a point-by-point rebuttal of some of the more amusing things that contributor has said in the last day.

The moral argument for removing m_invisible from InspIRCd

The module in InspIRCd named m_invisible.so allows you to join channels invisibly and spy on the users.  Granted, there are plenty of other methods that allow this, however m_invisible makes it accessible to the average user who is unaware of the other options.  In other words, this means that it makes this wholesale spying capability available to at least 80 percent of InspIRCd’s userbase.

Consider for a moment, a situation where users trust their network staff, but the network staff have recently done something to make them upset, so the owner of the network joins the channel and starts watching people vent.  Since he is watching them vent about whatever it is that he has done, he gets angry and starts placing autokills against his users.  While it is the administrator’s service, and he has every legal right to do so, it is not an ethical or moral thing to allow happen.

Another scenario, which has recently happened, is that an IRC server was infiltrated by the Chinese secret police.  Many users on this IRC server were monitored without consent using m_invisible, resulting in at least two people being apprehended due to participating in dissent activities.  If you don’t know how the Chinese secret police operate, I’ll summarize it: those people are most likely dead now.  While this scenario is not directly the fault of m_invisible and the surveillance could have been implemented in other ways, m_invisible was the simplest way to implement it, which brings me to another point, if you have to enable this module on your network, make sure you trust your staff entirely.

I brought this last point up with Brain, the project leader of InspIRCd after he flamed me on MSN due to the changes I implemented.  He did not seem to be affected by the fact that there are now two people most likely dead over events that happened during IRC surveillance, and accused me of being the “moral police”.

Moral police or not, those people died because of the fact that InspIRCd made it possible to easily spy on them.  While it is possible that they would have died anyway, the method that was used to intercept their communications was provided as a module in InspIRCd.

Ultimately, to us, we view this as a moral question.  Because Atheme is a middleware used on many InspIRCd networks, we felt that we had the need to stand up and say “we don’t want our software used in this specific configuration.”   Regardless of whether or not you agree with our position, it is our right to politely ask our users to comply with that.  There is nothing in the license forbidding the usage of Atheme in this specific configuration, so if you want to remove the checks, then that is your own business, but at least make sure the staff you have on your network are respectable.

Why m_invisible will never work correctly with Atheme

Now on to the technical reasons of why Atheme no longer works in this configuration: it is impossible to support the configuration properly without changes that the developers are unwilling to make due to code correctness and the moral issues outlined above.  As an example, if you place the *!*@* mask on +V in the channel ACL, it will auto-voice the invisible user when they join.  If you feel the network you are on is spying on you, but you cannot leave, we recommend that you place *!*@* on autovoice, which will expose the invisible users.  You can also kick the users if you can guess their nickname.

The technical reason is grounds enough to disable support for m_invisible in Atheme.


13:34 <~Brain> hes doing it the same reason hes always stirred up trouble, to get publicity for atheme and charybdis.

The IRC community generally knows that I don’t actively market Atheme or Charybdis, and allow them to stand on their own merits without the necessity of spamming, doing SEO or anything else.  Atheme’s popularity stems from our reputation of code correctness and realistic feature support.

13:32 <~Brain> Taros: then i say that your view of irc is very closed minded and restricted only to the public-network views that youve seen, havent you ever seen a closed support network? they log *everything* for accountability.

Professional support desks typically use Kayako LiveResponse, which is not built on top of IRC at all.  InspIRCd plus an IRC client does not come anywhere near the capabilities of Kayako, period, so it seems unlikely that anyone would use it for this purpose.

11:14 <~Brain> hmm, i could fork it.

There are plenty of other Atheme forks out there, so good luck!

Tags: , , ,

2 Responses to “Why Atheme no longer works with InspIRCd when m_invisible is loaded”

  1. Atheme / InspIRCd m_invisible brouhaha | IRC-Junkie.org – IRC News says:

    [...] module, referred to as “morally unacceptable” and “not … ethical” by nenolod, has legitimate uses such as “private networks inside offices, with special uses, those do [...]

  2. Auronia IRC News » Blog Archiv » Atheme und das InspIRCd Modul “m_invisible” says:

    [...] geladen ist oder nicht. Falls es das ist, dann verweigert Atheme den Link. Das Modul wird von nenolod als moralisch inakzeptabel oder unethisch [...]