This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] Privacy requirements
- Previous message (by thread): [anti-abuse-wg] Privacy requirements
- Next message (by thread): [anti-abuse-wg] Privacy requirements
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mark Foster
blakjak at gmail.com
Wed Dec 28 11:21:55 CET 2011
I realise this is a week old, but it's a holiday so perhaps that excuses my delayed contribution? On Wed, Dec 21, 2011 at 7:32 AM, Frank Gadegast < ripe-anti-spam-wg at powerweb.de> wrote: > I would love to hide all personal email addresses behind > >> a randomly changing address<randomcode>@abuse.ripe.net >>> >> >> Uh, that sounds like programming the "search" button to step aside >> from the cursor whenever users try to click on it :-) >> > > Yes, sounds like security by obscurity, but why not ? > > I like to make sure, that this should not apply to abuse contacts, > wich are to my opinion the only contacts that really need to be > available for automated system. > > Or does anybody see a reason, that a non-abuse but personal contact > should be visible by whois or in whatever else automated way ? > I cant think of an example here. > > whois could show the netrange, netname, routing and all > other technical objects, surely the new abuse-c with all > its data, could name the other contacts, but then simply > point to a webpage for the details of the other contacts. > > Ensuring that abuse-c details are the ones that're available unobscured highlights the very reason the issue is problematic... abuse@ needs to be the service which is _not_ filtered, and to be effective, needs real people to pay prompt attention. Half the reason organisations of a certain age or size are often seen to turn a blind eye to feedback received via that alias, is due to the sheer volume of crud directed at it. Surely leaving abuse-c details as the ones that aren't obscured is just going to magnify the affect? I like the idea of @abuse.ripe.net aliases but frankly, that'll just submit the MX records to an insane amount of abuse. Better that organisations be required to manage their own contact details appropriately enough for public listing; role based, write-off aliases which can be superceded over time if necessary, perhaps. Fact is, if you're eligible to get an IP Range direct from an RIR (as opposed to getting an ISP CIDR range, and thus being proxied through them in terms of any complaints about your conduct) you're morally (if not by policy) obliged to provide legitimate contact information. Cost of doing business, and it's not that onerous IMHO. > > And names, postal, fon and fax address of personal objects >>> could be hidden behind a webpage with captcha code or thelike, >>> maybe the abuse finder tool could be enhanced here. >>> >> >> Yes, personal data has to be protected. Perhaps not names. Perhaps >> login is easier than captcha for some users. >> > > A login for everybody that simply wants to know to whom > a network belongs ? > Thats maybe too much security and it should better not be > possible to track, wich user is requesting wich information. > That would again be personal data, thats needs to be protected > inside the systems of RIPE NCC, better leave that one out. > > If I only had to maintain a small number of Logins and I was using them regularly, i wouldn't have a problem with this.... however this will only discourage Joe-Public from actually tracking down abuse and reporting it - as the opportunity cost of taking the time to register in order to report an offense will be that much higher. Just look at how successful the mail service providers who've reverted to requiring web-form-submission complaints are finding it.... The drop in noise is no doubt coincidental to a drop in legitimate complaints from victims who now find it's easier to simply trash spam coming from Yahoo, than it is to submit complaints (that are, from the users perspective, largely ineffective, people see the abuse at dept's of most large organisations as a black hole manned by something vaguely better than trained monkeys...) Oh, is that my cynical nature coming through? whoops... My $0.02: - Compulsary abuse-c information in whois, supported. - Validation and reverification of contact information, supported. - Revoking (?) peoples IP ranges if they can't keep their contact information accurate? supported. - This is only going to get worse with IPv6. It's so big there will be large swathes of 'throw away' space and an even larger tendency for people to judge an entire netblock by the behavior of a small subset. I firmly believe that the RIRs and ISP's and Network Operators at all levels need to keep the lines of communication open, we should be able to recognise our need to mutually support eachother and to be able to deal with abuse (not just spam, either) originating from within our midst. Networks who can't take some responsibility for their customers, shouldn't expect anywhere near the same degree of professional courtesy. Mark. PS: In New Zealand where I am, It's been widely discussed that identifying an IP address holder only identifies the 'Account Holder', not the individual who's carried out an offense. So the Account Holder gets to have the responsibility associated with this. (Awareness of this point came as a by product of anti-piracy legislation introduced in the last year or two.) If the ISP won't disclose Account Holder information (under the terms of the law) they lose their 'safe harbour' provisions and essentially take that responsibility on themselves. Just throwing that out there as a possibly useful data point. -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20111228/e9495d0f/attachment.html>
- Previous message (by thread): [anti-abuse-wg] Privacy requirements
- Next message (by thread): [anti-abuse-wg] Privacy requirements
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]