On Oct 25, 2009, at 2:36 PM, James Hess wrote:
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?
An interesting thought exercise. If I were implementing an ircd right now, I would see making +i mandatory as a way to avoid dealing with that particular visibility check in various parts of my code. Two uses for -i that come to mind at the moment are in making opers visible to users, and for antispam automatons to trap certain spambots. However, both seem a bit weak: oper visibility can be addressed in a myriad of other ways on the server, and I believe the number of spambots currently caught with that method is sufficiently low to be irrelevant. Still, since the only advantage appears to be to me as a server implementor, with no benefit to clients or users, I would probably conclude that it's easiest to just maintain the status quo. I would, of course, be open to additional arguments either way.
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.
Have you somehow missed the number of clients that have been using WHO <channel> on join all this time? mIRC, xchat, irssi, Klient, KVirc, ...
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.
Which is why the UHNAMES extension was introduced in Unreal and inspircd. Note that both ircds also provide hostmasking with realtime toggling and rejoin simulation.
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.
The same script already has additional checks for joins, parts, and quits, and weights its evaluation of flood levels accordingly. It is not broken on implementations that simulate rejoins during hostmask toggling, as the results simply appear to be multiple independent flooders, and it can deal with those.
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
Well, aside from SILENCE not blocking channel messages as was the example here, not existing on all networks, being severely limited in number of entries, being primarily designed for clients to use automatically when appropriate and therefore missing a bunch of user- desired features such as persistence across sessions, fine-grained ignore types, exclusion entries and integration with the UI like query window ignore canceling, and the fact that in a discussion about backward compatibility you're proposing everyone else be magically compelled to change behavior instead, I suppose I can see the rationale in educating users to use SILENCE ;)
I agree [a usermode to change hostmasking status] 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.
Then why are many networks explicitly reinforcing those assumptions with workarounds and extensions, and what incentive do clients have to change in the face of that?
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.
So far in this thread there have been several examples given of disadvantages that exist for both realtime toggling of hostmasking, and for making hostmasking optional at all. However weak they may seem to be, many of them affect end users indefinitely, and therefore qualify as lasting issues with masking. The question seeking advantages to realtime hostmask toggling remains unanswered. The question seeking advantages to optional hostmasking has only one response so far, which is to decrease disruption during a transition period. I don't see how downplaying the provided issues is useful when there hasn't been a significant advantage given in the first place. I find it particularly interesting that despite the number of current implementations of optional hostmasking, no one has posted an example of someone needing to turn it off to accomplish something. I suppose I could add one for the sake of argument. There exist fserves that are behind firewalls, and therefore require you to run a dcc server in order to retrieve files from them. They work by having you disable masking so that they can retrieve your real address and connect to it. It is then important to be able to disable hostmasking, and rather convenient to be able to do it in realtime, especially since this is usually on a network that applies anonymous masking by default. My primary counter-argument would be that this use is only for a situation that doesn't apply to DALnet: channels set up for the purpose of filesharing. A secondary point would be that the onward march of technology is making these types of fserves increasingly scarce. [Obligatory repeat disclaimer: I'm speaking only for myself; what happens with hostmasking on DALnet is not up to me.] -- Quension