Richard Clayton wrote: > >There will be an API for the system with an option for email notifications > >just > >like abuse complaints are received in email messages now, so there will be > >no > >overhead to your staff. Regarding the reporters - this overhead can protect > >from > >flood of automatic tools abuse complaints - if the reporter cannot fill a > >form > >and solve a captcha then the abuse complaint is not important enough to him. > > I don't think you quite understand the scale at which many abuse > detection systems identify activity which needs to be dealt with (and > indeed will be dealt with in an extremely timely manner once a report > has been made). > > Solving CAPTCHAs gets old very quickly. > > >Regarding the little to no value that you wrote, through this system there > >will > >be no spam of abuse, no spam to the abuse publicly visible email address, > >there > >will be an API to LIR's internal systems for them to better track and to > >better > >handle abuse complaints, there will be tracking if abuse complaints were > >handled > >and public visibility of the percentage (of unhandled abuse complaints) of > >each > >LIR, in Ripe website. > > This paragraph make me think that you have never been the receiver of > email which has been generated as a result of filling in a web > form... > spam (and indeed abuse such as mail-bombing) is remarkably common.
CAPTCHAs are indeed the wrong tool to such form. You would want instead some kind or authentication token for reporters (ok, maybe you can request a captcha if you are not logged in, but clicking on bicycles until the data-mining captcha provider is satisfied you are not a bot is not constructive at all). Such form *could* work. One format in order to report to any LIR in RIPE. The receiver could process the structured data automatically and even take action without human intervention if the reporter reputation (or the combined reputation of everyone that did so) is high enough. > It is also extremely common for genuine reporters to fill in > incorrect or incomplete information and making forms robust against > this issue is extremely complex. It would have to be properly structured with all the needed fields for every case, and its API would need to support the multiple use cases, and integrate with (or replace) the multiple ticketing tools used out there for abuse handling. Ironically, such tool would mean imposing a much bigger requirement on the members and the way they handled abuse than every abuse-mailbox proposal we have discussed on this list. Regards -- INCIBE-CERT - CERT of the Spanish National Cybersecurity Institute https://www.incibe-cert.es/ PGP Keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ======================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ========================================================================
