Freenode Cloaks

Jump to navigation Jump to search

The cloaking method on Freenode works a bit different than other networks. This article will explain how they work.

Types of Cloak

There are 2 types of cloak that a user can possibly obtain but each one is obtained differently. These are as follows:

User and Project Cloaks

Project cloaks are offered to users that are part of one of the projects on the Freenode network. These typically take the form project/role/user, for instance 'wikimedia/someuser' (though some take other forms). They are designed to demonstrate that the user is connected to a project in some way. Different projects use cloaks for various roles and some are offered to users of a project aswell.

Normal user cloaks which can be requested from #freenode take the form unaffiliated/accountname. They indicate that the user is not affiliated with any specific project on Freenode. Bots can also be cloaked to indicate their owner and take the form of 'unaffiliated/owneraccountname/bot/botaccountname'.

Gateway Cloaks

Gateway cloaks are cloaks that are put on a the user if they are connecting from larger organisations and webchats, such as Mibbit, KiwiIRC and many bouncer providers. These hosts tend to take the form of 'gateway/shell/providername/x-*' or gateway/web/provider/ip.'

The Cloak Hierarchy

Gateway cloaks are applied when you connect to the network from a larger organisation, webchat and bouncer providers such as ourselves. However, you may already have a user or project cloak assigned to your nickname. Freenode interprets this as follows:

  • User Cloaks: If you have a user cloak (unaffiliated/accountname), this will not work and you will be assigned the gateway cloak
  • Project Cloaks: If you have a project cloak (project/role/user), this will be applied when you authenticate to NickServ or use SASL and will over-ride the gateway cloak

Notes on Spoofing/Cloaking

Because of the way gateway cloaks are assigned to users, it is sometimes possible for users to evade bans that are set. For example you issue the following:

/mode +b *!*@gateway/shell/bnc4free/x-89327

The issue with this is that the number after the 'x' always changes and does not remain the same which means that all the user has to do is reconnect to the network to evade the ban.

It is possible to ban all users of the BNC4FREE gateway using the following

/mode +b *!*@gateway/shell/bnc4free/session


/mode +b *!*@gateway/shell/bnc4free/*

but this will also ban any users using the BNC4FREE gateway cloak that have a project cloak aswell. Freenode spoofs the IP during connection to the network before applying the cloak. It looks a bit like this in a WHOIS:

[MyUser] (test@wikimedia/MyUser): My Name
[MyUser] :Miami, US
[MyUser] is using a secure connection
[MyUser] is connecting from *@gateway/shell/bnc4free/session
[MyUser] is logged in as MyUser

As we can see here, Freenode interprets the user as connecting from host "gateway/shell/bnc4free/session" but with a gateway cloak of 'wikimedia/MyUser'. Because of this they are affected by the bans set on the BNC4FREE gateway.

Freenode's services also take this into account and therefore the same principal can be applied to ChanServ flags and akicks.