On Sat, Oct 24, 2009 at 6:42 PM, Trevor Talbot <quension@mac.com> wrote:
On Oct 23, 2009, at 6:10 AM, James Hess wrote:
On Fri, Oct 23, 2009 at 3:04 AM, Trevor Talbot <quension@mac.com> wrote: .. Also, it's worth noting that +i (invisibility) wasn't made and hasn't been made mandatory, ever... No, but it has been made default. I suspect that on networks with default anonymous hostmasking the percentage of people who choose not to mask is similarly low. Without a practical reason for avoiding it, [...]
Do you think +i should be made mandatory now? Perhaps it should be. Spambots may be confused when they join a channel and see someone who is mode +i; after the spambot parts the channel, the user who switched to -i might receive two malware URLs instead of just one, as the bot crawls /who, and erroneously creates a second entry in its state table. One spam message is bad enough... ..
Basically, any client that follows the spirit of IRC by translating, automating and otherwise turning the low-level interactions with the server into something as user-friendly as possible. Most mainstream clients maintained today keep significant amounts of state: modes, clients in a
I thought you were perhaps suggesting there is a broad category of IRC clients called "modern stateful clients" that would all have essential functionality broken by masking or toggling masking.. but I don't believe this to be true. IRC clients do keep track of some stateful information from IRC, but it is mostly only channels that they keep track of: channels, the list of channel members' nicknames, and their operator status. Requesting host information requires an expensive /userhost command, a lot of extra work. Hostmasks are not part of the state information other members of the channel get for free. That is: hostnames aren't advertised of existing users when you join a channel. Major networks that do allow toggling of masking status may have influenced the design of IRC clients over the years.
One example is commonly implemented forms of flood detection. Eggdrop's sentinel.tcl, among others, uses a host-based hashtable to detect and respond to certain types of clones. If a client's host can silently change, that mechanism breaks.
This is a specialized type of script that also cannot do its job if masking is optional. Toggling doesn't make a difference: it's a fact, that the bad fellow conducting the clone flooding, could make some of the clones masked, and some unmasked, in order to evade detection using a hash table, unless masking is mandatory. To be a good reason to fix masking status: the example should show a disadvantage of toggling specifically, that does not apply when clients can opt-out /in by reconnecting.
You missed the qualifier, "with no indication". If a client quits, parts, or otherwise changes its presence in the channel and vanishes from view, the user is notified that something has changed and it might not be ignored anymore when it returns. If any client can change its host without notification, the user sees an unreliable and broken feature instead.
This is an example, but it's a really really weak one. Users should be educated to use /silence I believe users of IRC most commonly /ignore by nickname, that is they set an ignore for nickname!*@* Without regard to hostname. Because it is the default behavior of practically all IRC clients to just ignore the nickname, unless a host or other criteria has been specified. Such ignores are already easily avoided by the bad user signing an additional client onto IRC or changing nicknames, while not on a common channel. Again, if masking is optional, the user being ignored may reconnect without the /ignor'ing user knowing. The only way they can know about a /reconnect, in the first place, is if they share common channels. The users who know to /ignore by hostmask, should also be the ones who know about the /userhost or /whois command, and can see that the hostmask has changed.
don't make it mandatory. What then makes you suppose pre-masking assumptions are significant?
I agree it is the most common method of user control, but I am challenging the implicit assumption that it is even a *good* method of providing masking, let alone the best compromise currently available for most uses.
What I'm saying is, that since networks have already implemented it for many years, modern IRC clients' designs are influenced, so that the assumptions are deadweight. I'd actually be more concerned about old versions of IRC clients, but the only relevant example shown so far where they might break has been /ignore. The type of example I'd really be interested in is: "/ban nick 3, is broken with mask toggling in the current version of client Xyz" not vague suggestions a feature might be broken, but a real indicator. Where client Xyz is some software program used by at least 1% of IRC users or channels on the network; e.g. mIRC would count, some IRC client released in 1990 that 20 people in the world use would not.
Several networks that implement realtime mask toggling have found it necessary to also provide quit/reconnect simulation, which is a strong indicator that the assumption of a hostname not silently changing is
Examples? Which networks, and what made them feel it necessary? Do they still have that and still consider it necessary today? -- -J