Wouldn't a time stamped log directly to cservice allow cservice to take action against people abusing hidden host?
I note that X tracks my real ip/host, and has a valid e-mail address for me. I also note that cservice tracks IP's well enough that single users possessing multiple username's have to be very careful about who they authenticate as/what IP they authenticate from when supporting new channel registration. It seems that all the tools are in place to have cservice do a quick review of complaints/logs, and take action as they, the provider of the hidden host, deem necessary. They could remove the usernames of those abusing, 'blacklist' e-mail addresses of abusers/abusers domain's, etc. I believe all of this is already happening for user/channel registration. Although not ideal, it seems a small step to have cservice report to ISP's/admins if the complaints indicate that would be the proper course of action. As to getting opers involved in the process, I am not sure that would be successful. A good oper is always hard to find. I think that the Undernet has long had a reputation of having opers that are friendly and helpful. I believe that many of them would gladly take up this challenge on behalf of the users and the welfare of the Undernet in general. Unfortunately, considering the number of opers available to help at any moment, the number of potential abuses you want to investigate, and the average length of an 'incident', I'm not sure that it is realistic to place this load at the feet of the opers in real time. Based on those two factors, I would ask why couldn't cservice handle such complaints on their own? As to the original thread, I would say that I don't think that hosts should be un-hidden for any regular users, under any circumstances. Do not punish/hinder the people who follow the rules because some choose to do otherwise. Abusers have always had bots & bnc's on compromised hosts at their disposal to hide their own real IP's/ISP's. They can chain through multiple accounts making identifying them and banning them virtually impossible… hidden host or not. As many have already pointed out, having good channel ops who can't be easily flooded off /nuked is the best way to stop/discourage many of these abuses. Making the real host information more accessible is a step backwards, and a step in the wrong direction. For those of you who think that the hidden host situation is any worse than the bot/bnc situation was or is, I have to ask how often your reports to abuse@ made a significant difference in curbing a flooders activity or positively identifying the abuser? As a channel op who has tried to ban users with scores of bot's/bnc's running on dozens of hacked/unsecured hosts the situation has been dodgy at best. In the case of hidden host, at least the people we are reporting to have an interest in maintaining a secure/stable Undernet. There is a much better chance that cservice will use all available information to help keep abusers off Undernet. When ISP's/admin of a compromised box receive such complaints, their first thought is of protecting/securing their own resources, not helping me/Undernet identify the actual perpetrators. Sorry to be so long winded. -stephen
From: stoney` <[EMAIL PROTECTED]> Subject: Re: [Coder-Com] suggestion of a WHOIS modification Date: Fri, 03 Jan 2003 00:18:58 -0500 Well technically since cservice issues usernames that allow users to mode +x, they need to be notified when there's credible evidence of abuse. Unfortunately, the only way to confirm abuse is by having an IRCop check user@hosts of clones and then report it to cservice (messy isn't it). We currently have #zt for channel takeovers, and #cservice for X and registered channel issues but since #cservice ops aren't necessary IRCops, and #zt has it's hands full with other lameness, I do think we need a channel where IRCops are willing to validate hidden host abuses. Comments? stoney`
_________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
