We are still in the early days of the internet. It is a frontier territory where crime is rampant.
I don't want the government prosecuting people for speech, even mass, automated speech. There are much better solutions than resorting to violence.
Protocols and system designs which make abuse impractical and thus prevent spam before it starts are surely desirable, although they often come with their own tradeoffs (user friction, privacy, false positives, maintenance costs, etc.). If spammers can be deterred by improving along other axes all the better. But the general problem of spam is that computing resources allow for massive amplification of malicious actions, and that's never going away — it will be an arms race between spammers and their victims forever.
As someone who battles spam on the small business front lines, I hate it. It fills me with fear and a sense of loss-of-control, that spammers may be commandeering our systems at any moment, possibly causing us to lose money, time, and reputation, cutting us off from vital services.
It takes hard work for me to overcome that and to recognize the humanity of spammers. Even now, I'm wondering, "Is sneak a spammer?" Rationally I don't believe it, but that's the kind of resentment that builds when people are left unprotected.
I hate spam; I just hate violence more.
I don't consider solutions to problems that involve violence to be solutions. Violence is, after all, the last refuge of the incompetent.
GitLabSec team-member here, ^ this 100%.
Our Trust and Safety team works really hard to keep up with spam. For those interested in how they do so, you can read more here[1]. We are also working on making our spam detection engine more effective at mitigating high-volume spam incidents such as this.
For current, working product improvements to detect and mitigate spam you and others can check out MRs labeled "spam fighting"[2]. We've had quite a few internal conversations about strategies and best-practices. For more information on how to contact our Trust & Safety Team, including tips on how to deal with abuse in your own instance or steps to suggest spam/abuse related features, see our handbook[3]
[1] https://about.gitlab.com/blog/2020/10/29/how-we-work-to-dete...
[2] https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=...
[3] https://about.gitlab.com/handbook/engineering/security/secur....
That would require the project's moderator to clear the newly posted issues (whatever is possibly a spamming route there) before they propagate. As this is an additional friction point, some bad actors may be intercepted there (say, trying to clear a million issues at once or other equally ridiculous actions).
Of course, by itself it won't stop someone from clearing a single issue to a million of "users". But may still help in id'ing such actors.
Like in this case (GitLab) - create a fake "issue" with spammy links in it and then "notify" thousands of users.
In our case - we are a helpdesk ticketing app, so bad actors sign up for a trial, then add "users" to their account and then, say, create "tickets" on users' behalf (customizing the email template by inserting spammy links).
India, Midde East, Turkey, Russia, China, South East Asia (except Singapore), All of Eastern Europe, Africa and island nations.
It immediately reduced the amount of fraud and spam. Sure you might miss out on the <1% of your revenues but its a tradeoff I'm okay with.
Having worked in the South African tech scene and for a UK company, every spam/dos detection I've seen has been from everywhere you mention except Africa and island nations.
or is this another one of your alt nick you periodically sign in from?
here's the trade-off. Make you decision.
Also, you could try to detect headless browsers like Headless Chrome.
If you want to appear to be a legitimate comcast, charter, centurylink, frontier end user on a last mile broadband connection in a house somewhere in the US48 states, that's a standard service that fraudulent organizations make use of now.
Usually using software that people have been tricked into installing on their computers.
hCaptcha has bad UX, their dataset is way harder to decipher and commonly takes me three or four tries to get around on Cloudflare, if it doesn't keep failing with a server error which I've had happen on multiple, distinct occasions.
At least for Google, I was done in one turn when lucky, if I had no other choice (e.g. banking).
At least hCaptcha has a decent chance of letting me through if I answer correctly.
We have all sorts of protection: rate limiting, crippling non-paid accounts, detecting if a trial signup comes from a VPN/Tor (+5 to "suspicious" score!) etc... But they still manage to find ways. It's a never-ending battle. And the saddest part is - all this hard work is completely invisible to our existing paying customers :(
If your app has an email-sending module of some sort it WILL be abused. Even a trivial "reset password" form is a target.
My support goes to the GitLab team. Good luck and no hard feelings.
[1] https://www.jitbit.com/news/5354-spammer-attack-post-mortem/