Interview With Jarkko Oikarinen – The Inventor Of IRC

Today we’ve got something very special:

An Interview with the creator of IRC himself, Mr. Jarkko Oikarinen.

We’ve asked Mr. Oikarinen a few questions about his invention as well as himself – without much further ado lets get straight to the interview.

First, please introduce yourself to our readers (even though you really shouldn’t have to )

My name is Jarkko Oikarinen. I am the developer of original IRC server and client and was actively developing IRC from it’s inception in summer 1988 until somewhere around 1992.

Since then I’ve been working in many areas in software industry, including multiuser games, software for advanced neurosurgery, medical imaging software, 3D computer graphics (which was my PhD research area), mobile applications and operating systems.

Most recently I have sort of went back to my roots and become involved in the development of a different kind of multiuser “chat”, Google Hangouts.

Out of what necessity did you invent IRC?

In 1988 I was working as a summer intern in University of Oulu (in Finland), and I was the sysop on a BBS (bulletin board system) called OuluBox. That was one of the few BBS systems where one could connect to over both phone lines (using modem) and Internet.

I decided to improve the multiuser chat system for OuluBox and IRC was the result of that effort.

The name ‘Internet Relay Chat’ was definitely more ambitious than the original intention.

How much time did it take to come up with the first versions of the protocol, daemon and client?

The first versions took maybe 1-2 months, depending on how you count. At that time I was doing all kinds of small networked programs, games etc, parts of which was easily reusable here.

Do you still use IRC? If so, for what and if not, why?

I use IRC very rarely nowadays.

Main reason for not using it is simply lack of time. Also in the early times I was in fact spending more time developing IRC than using it… it’s like many other things for me, I am more interested in developing new solutions than actually using them myself for very long.

Did you ever imagine IRC would be as popular as it is now (or was)?

Definitely not.. there were several other chat programs also at that time, but IRC’s distributed design made it different from others.

The timing for IRC was perfect in that it was introduced when Internet was just about to link together all continents.

What’s your view on the development of your invention, be it technical or its use?

It actually looks like there has not been that radical development on the chat systems during the last decade. I find that surprising given all the areas where improvements could be made.

If you had to write the protocol today, would you do it differently now?

Yes, of course… obvious examples are usage of proper cryptography and making of the IRC spanning tree more fault tolerant.

I would also think of scaling, so that the size of an individual IRC network could be larger than what it can be now in practise.

IRC in the early days must’ve been like the Wild Wild West – how did you experience it?

It was very exciting and unique; it felt like much smaller world, almost everyone knew everyone else, there were many happenings where IRC users met each other in real life.

I presume much of the similar atmosphere exists even now within individual IRC networks, but I have only later really understood how unique the early days of IRC were. I also had the opportunity of getting many IRC friends around the world, many of which I still keep some contact with.

The Great Split – What role and position did you have?

I assume you refer to the eris split. I was of the opinion that anonymous servers should not be allowed in the irc network. That opinion was based on the IRC protocol limitations; it allows anonymously attacking the irc in such a way that the discussions could be eavesdropped.

The IRC security model depended on the server administrators being reliable, and anonymous access would allow anyone to have the same access rights than the administrators.

On the other hand, I support the concept of having multiple smaller independent irc networks, there is no need to have just one big network.

If you had to modernize IRC for it to be able to compete with all the social networks, what would you do?

I think the key words are security (the servers should not rely on each other so much), privacy (cryptographic guarantee for conversation privacy) and multimedia (audio, video).

But I’m not sure if IRC would be the same thing after these changes…

If you wanted to see one thing implemented in IRC, what would that be?

It’s hard to pick just one thing, but the area which I worked as one last thing (but never got to finish it) was the network of networks concept.

It would link the independent networks together but allow individual networks keep their identity and control, while simultaneously allowing users to easily browse all channels in all networks.

What kind of influence do you still have on IRC?

I have not been actively participating in IRC development for a long time, and am not planning to do that either; I just don’t have the time.

Non-paid projects such as IRC have more people who like to tell how features should be done instead of actually completing the features themselves. It’s so much more fun to design software than actually go through all implementation necessary.

Therefore the direction is truly influenced by people who actively develop the software who actually make the decisions on what they choose to implement. That is also how it should be, as far as I am concerned.

What’s your take on projects that try to unify IRC networks once again, such as the Janus interlinking service?

I have not studied that very much, but by initial look it looks like something similar to the network of networks concept. There probably are a few different approaches, but I would try to keep the network linking loose so that the individual networks can develop their servers and add new features independently, without necessarily requiring those features to be added to all other networks.

My ideology would concentrate on providing value to users and allow them to explore the whole IRC metanetwork from their clients.

Is the original source of the IRCd still around somewhere for folks to look at?

I don’t think the very original source is available anymore. I tried to search it a few years back, but was not able to find it anywhere on my local backup disks.

Is RFC1459 supposed to be all inclusive or, as per your intentions, is it allowed to be extended as long as it is fully supported?

RFC1459 was written to document the existing protocol at that time. Progress needs new features and extensions.

If some server implementations would no longer be compliant with RFC1459, I would prefer those servers to not be called IRC, unless those changes are very widely accepted in IRC community.

Progress needs to happen, so we shouldn’t stick with the old designs, but fragmentation should also be avoided.

In closing, what would you like to tell our readers?

One thing that I would like to remind that even though social chatting over computer is much fun, don’t take it too seriously so that it would jeopardise your studies, work, and/or real life social interaction.

A big thank you goes to Jarkko Oikarinen for taking the time to answer the questions so thoroughly!

Mibbit has been compromised

On August 14 a cracker group claiming to be “hackers” named HTP broke into Mibbit, the popular web chat client for IRC. According to their temporarily “rescue” blog the break-in only affected their IRC network, their primary blog and their Wiki. NickServ passwords in clear text were released later the same day by the HTP, as well as personal information regarding several staff members. Both their IRC O-line passwords as well as their NickServ passwords, home addresses and phone numbers were published to the public via a range of file hosting services, and Pastebin.

Something perhaps even more concerning is that the group has revealed not only channel logs, but logs of private messages. It appears like Mibbit has been logging what people have said in PM to each other over their network. According to official statements, this was only a test. Some people have heard that Mibbit has been logging all messages going through their systems. Mibbit has never logged anything, unless a user wants to enable logging. The leaked message logs were captured by a staff member, and not by Mibbit’s system, according to official statements. While this is fully legal, the level of ethicality has been questioned.

The web IRC client that can be used to connect to almost any other network, which is what made them famous, has not been affected. It is operating normally.

All NickServ passwords were stored in plain text, and that raised a concern for those who are interested and engaged in enforcing security. According to staff member pottsi password hashing was not done because that would “means sendpass and getpass would not work”. Another staff member, Joshua, claimed that password hashing was not done because it was too much work to convert all passwords. This has however proven to be incorrect, at least if they used a plain copy of Anope. In Anope’s module database, there is a module called enc_switchover. It’s fairly easy to migrate from one encryption method, or none, to another, using that module. In addition to that, the Anope module ns_resetpass will allow users to reset their passwords despite encryption taking place.

Many people, especially IRC administrators, are now questioning Mibbit’s reliability and some are considering to block access from the web service, just like one of the largest networks, freenode, did a couple of years ago. This is mainly due to the question whether they log messages there too, which would go against many networks’ policies.

The Mibbit team is now working very hard to bring all services back up again. At the time of writing, ChanServ and NickServ on their network is down and staff members are forced to use /samode if they need to get op. They advice everyone who had a NickServ account registered in April or earlier, this year, to change password.

Researchers develop "HoneyBot", Social Engineer IRC Users automatically

Researchers of the TU Wien (Vienna University of Technology, Austria) achieved a stunning – and at the same time scary – 76,1% click rate on possibly malicious links in conversations that took place on IRC using an automated social-engineering software dubbed “HoneyBot”.

Their new approach to automated social engineering (“ASE”) does not rely on artificial conversations from an AI but instead used the bot to relay messages between humans, effectively avoiding detection according to what is commonly referred to as “Turing Test” in which humans assess if they can tell apart that they are talking to a human or a computer program of sorts. Previous generations of such bots used an AI called “Artificial Intelligence Markup” to engage in conversations with a much lower success rate: Users where able to spot 80% of the bots after exchanging only 3 messages with them.

HoneyBot acts as a “Man-in-the-middle” and relays messages between two unsuspecting users which seem to have perfectly normal conversation going on:

bot → Alice: Hi!
Alice → bot: hello
bot → Carl: hello
Carl → bot: hi there, how are you?
bot → Alice: hi there, how are you?
Alice → bot: …

But that’s not all – the bot is capable of influencing the ongoing conversation by “dropping, inserting, or modifying messages” and the researchers assert that “if links (or questions) are inserted into such a conversation, they will seem to originate from a human user” and therefore the click-probability will be “higher than in artificial conversation approaches”.

The really sophisticated bot is able to determine the gender of the persons it is talking to and makes on-the-fly adjustments to all relayed messages so “Hello, i’m a guy” becomes “Hello, i’m a lady” when its gender-detection algorithm determined that the conversational partner likely is male. Insertion of links also has some level of sophistication – instead of just dumping a link into the conversation and hoping for a click, the bot has 3 options for doing so:

Insert a random link: Along with a generic message a link is sent to the other user if they have been engaged in a conversation for a minimum number of messages

Keywords: Reply with links to keywords such as “ASL?”

Replacement link: Questions already containing links to sites such as YouTube are replaced with own links and therefore look most natural since the question was composed by a human. Also, the bot can inject probing questions to steer the conversation into a certain direction.

Trying to be as stealthy and sneaky as possible, the bot never contacts users with “administrative privileges” but replys to private messages by such, although it will never inserts links or questions into those conversations. Additionally, a random delay is used when “typing” messages to make detection even harder.

Aware that what they have created is a whole can of worms when used unethically, the researchers made sure that personally identifiable data such as eMail and IM addresses are never relayed and links sent in conversations are filtered if they’re not going to be replaced by HoneyBot.

The channels monitored by the bot where 2 dating and one generic chat channel of which neither the channels nor the network have been named in the research paper.

HoneyBot Monitoring Statistics

When talking about the ethics, the researchers conclude that they’re well within the guidelines set forth by the IRB (Institutional Review Board) based on similar researches and also got a nod from the legal department of the university. They chose to not inform users before the experiment since this would most likely have influenced the results as “users that are aware of participating in a study are likely to be more cautious than usual” and say that they “carried out the study only with users that responded to our messages and thereby accepted talking to the bot (i.e., stranger)” and emphasize that there were no “ongoing conversations intruded” by them. Also they note that all data collected “although largely anonymous” has been deleted after the “evaluation phase”.

With 3 seperate bots – a “periodic spam” bot, a private-message spam bot and a keyword spam bot – they evaluated the likelyhood of users clicking on links, the results can be seen in the below table:

HoneyBot Monitoring Statistics - Clicked Links

Altogether, only 1.7% of the online users could be enticed into clicking a link by those 3 “classic” bot types and the bot only got to post 8 links on the Chat channel before it was banned by a channel op.

Enter HoneyBot:

The longest conversation HoneyBot had took a staggering 2 and a half hours with 325 messages transmitted and it achieved a median chat time of “longer than 30 minutes”.

Out of the 3 possible URLs the bot has sent – broken down in IP, TinyURL and a MySpace link – TinyURL links where the most clicked about which the researchers rightfully say is counter-intuitive since “TinyURLs can hide arbitrary URLs whereas a MySpace link always leads to a profile”.

HoneyBot - Clicked Links Breakdown

Furthermore, the MySpace links the bot sent out had to be reassembled by the user because a space character was inserted into the URL and the researchers said they’re “surprised that this reassembly has happened at all”.

It should not go unmentioned that the same type of research was conducted on Facebook where they created one male and one female profile and tried to befriend users of the opposite sex. The new friends, if successful in bootstrapping a conversation, then tried to make them click on the same links as the IRC bot. And even though 4 out of 10 people clicked them, the researchers believe that the attack could have been way more successful if they went as far as cloning profiles, befriend users from those and relay messages from cloned to authentic profiles.

As can be seen from the Facebook example, this kind of attack is not limited to IRC exclusively but can be adopted to a whole host of so-called Social-networking sites and systems.

Mitigation of these social engineering threats is not easy and there is no fast and hard measure that can prevent all of them, however raising awareness is one way to make users more alert to it and is what the researchers tried to achieve: “We hope that this paper will contribute to this process.”

In Soviet Russia Vienna bots social engineer you!

Atheme / InspIRCd m_invisible brouhaha

Those who closely follow either projects development will have noticed a few “odd” looking commits to their sourcecode in the past few days.

The commits all concerned InspIRCds m_invisible module which provides similar functionality as the old mode +I in UnrealIRCd 3.1.x.

Quoting the InspIRCd wiki page about m_invisible the module

adds support for quiet (invisible) opers. A quiet oper is invisible to normal users on channels. This can be used for surveillence of botnet channels, statistics bots, etc. Note that other opers CAN see invisible opers; +Q only hides the oper from non-opers.

The brawl emerged when Atheme developer nenolod commited a few changes to the services packages that would make such a join visible to channel members by announcing that “Channel security has been compromised” because an invisible user has joined.

This commit was followed up by danieldg of the InspIRCd developer team who moved the module out of the main – and therefore by default included – modules into the seperate “inspircd-extras” repository, but only in the 2.0 beta and 2.1 pre-alpha branches.

The initial commits to Atheme have since been reverted but there now are checks for m_invisible being loaded and the services package now refuses to link if it spots the module being present.

The 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 need logging and accountability, most of them even disable private messages entirely” said developer Brain when asked about his views of this whole situation. They wrote it because “users asked for the module” and his opinion is that it “should be kept, and we’re keeping it, in third party”.

Brain says to him “it’s all about choice, the choice to run the modules or not to, we aren’t going to tell people whats right and wrong” and that “people are sensible enough and educated enough to decide for themselves”.

What’s your opinion about this? Do you use m_invisible on your network? And if so, do you tell your users that such a module is loaded? Guns don’t kill, people do?

HowTo: IRC anonymously with TOR

On networks that don’t hide your IP or hostname automatically on connect, your IP is exposed for everyone to see and possibly abuse.

Also there are many reasons you might not want to show everyone from what point of the world you are connecting from and/or want to add a little more anonymonity to your online activities.

You can do so by connecting to IRC via TOR – dubbed “The Onion Router” – how exactly that works and is set up is shown in a small tutorial video we’ve put online.

In this video we’ve used a virtual machine running Ubuntu “Karmic Koala” and the IRC-client XChat for our setup – but the same principles apply to any other client or operating systems, although the steps you need to take will differ.

Watching the video in HD for better readability of the on-screen instructions etc. is recommended.

Questions? Comments? Let us know

www.IRC-Junkie.org – IRC News

All about Internet Relay Chat

Category Archives: Privacy

Interview With Jarkko Oikarinen – The Inventor Of IRC

Mibbit has been compromised

Researchers develop "HoneyBot", Social Engineer IRC Users automatically

Atheme / InspIRCd m_invisible brouhaha

HowTo: IRC anonymously with TOR