We are a small SaaS vendor and fighting spam is, like, 20% of the technical work that we do. Bad actors register trial accounts and then reverse engineer your front-end and forge millions of requests. Just 2 days ago we had a very similar issue [1]
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.
Do I have a minority opinion for believing that spam, even coordinated, ddos-level, business-destroying professional-grade stuff is not a severe enough problem to send men with guns to a place to lock a human being into a cage?
I don't want the government prosecuting people for speech, even mass, automated speech. There are much better solutions than resorting to violence.
Yes, "spammers should not be punished by the government for destroying businesses" is bound to be a minority opinion, even if some among us are sympathetic.
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.
I didn't claim they shouldn't be punished; I claimed that spamming is not sufficiently damaging for a reasonable response to it to include violence, which is what arrest/prosecution necessarily entails.
It all hinges on whether or not you can protect the populace and effectively prevent spammers from causing harm. If you can't protect people, you will lose their faith.
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.
Quite the opposite: I've an opt-in email list of thousands that I've never sent a single mail to because I haven't yet crafted a draft email that I consider to be sufficiently valuable to warrant appearing in someone's mailbox and requesting a few seconds of their time. I've also run my own mailserver since 1997, and have lost dozens of days in my life over the decades to battling spam.
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.
Thats about initiatives. Many daily drivers break some laws, like speeding or not using turn signals. Does that make traffic frontier territory? :)
Try something serious, like operating black drug market or treatening high level politician (in internet): you going to be surprised, how well different countries co-operate. For example operation involving 30 countries: https://www.europol.europa.eu/newsroom/news/%E2%80%98avalanc...
I work for an e-mail provider.
This is very painful part of our work. Part of our services are free and ad supported. We are disabling, queueing thousands of mailboxes per day. Captchas and user scoring does not help that much. There are very cheap services were people manually will solve recaptchas/hcaptchas. Even required phone numbers (normal users are pissed when we ask for a phone number to use account fully but we don't have much choice...). There are phone number farms which are used for account verification also
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]
Maybe introduce a Moderator role to the multi-user projects?
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.
So these 'bad actors' are they just out to find a way to DoS your service or do they have some other motive for forging millions of requests. (I get that email sending is a target - that has been the case since forever - but I'm asking about 'what else'?)
Yes, they sure do have a motive - to send spam via a 3rd party service.
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).
It varies: generating inconvenience(for fun or hate towards a particular service), spreading scam URLs(leveraging existing trust relationships), SEO and improving discoverability of their projects (porn, streaming of pirated content, etc) and many more.
That won't work as the same bad actors typically dabble in CC fraud as well. They will typically already have thousands of CC numbers at their disposal.
Is the African and island nation traffic that significant and fraudulent?
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.
not sure what you are trying to say here. Simply blocking all sources of traffic which we don't do business with has been beneficial in stopping spam and frauds.
it doesn't have to be days, most credit card fraud is found within hours. You can also allow partial use of the application during the vetting period, just exclude the parts that are being abused. Though you should probably aim to build a product that people want to sign up for, and are willing to wait for.
google "residential proxies for sale" - there is a whole huge grey market in selling proxies from peoples' actual residential internet connections, usually to be driven by bots or people in click-farms somewhere in a low labor cost location.
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.
I don't need to Google them. "Residential proxies for sale" is one of the most common Facebook ads I see. There was one on my screen just five minutes ago. It's staggering that the industry is so blatant.
Exactly, and this is why "in theory" Google reCaptcha, the that is just a checkbox, is a needed solution. If they only used it to just stop spam and not also to track legitimate users...
Lots of VPNs route through hosting providers. Some hosting providers are more prevalent with spammers than others. But in the end you can only really use it as a scoring measure. It's not nearly binary enough to straight filter using it.
I'd rather not use the service if it has hCaptcha OR ReCaptcha.
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).
It seems to have gotten better but I still haven't forgiven ReCaptcha for regularly making me spend ages retrying the unending and excruciatingly slow loading tests.
At least hCaptcha has a decent chance of letting me through if I answer correctly.
It's interesting that the nickname of the spammer is "fixspam gitlab". It seems that their intention is to force gitlab to introduce anti-spam measures.
Could be... I've seen this before - people annoyed by continuous low effort spam and the service not fixing it, deciding to show what a targeted attack will look like to force a response. (Not saying that GL doesn't care)
I run my own instance of Gitlab which basically means that I handle spam manually. It is a pain.
Gitlab recently added a band-aid of a feature to require admin approval for new sign-ups, which comes with its own obvious problems. But even the UI for that is clunky-- you have to click a button to reveal some options, find the option to delete the spammer, type (read: paste) the users handle as a failsafe, after which Gitlab takes you back to the main user view requiring you to click again on the unverified users tab.
Last time I talked about this problem someone from Gitlab claimed they were working on a feature to send an email with a simple link to click to approve/deny a user. That feature still has not shipped.
They did fix an unrelated catastrophic bug of keeping around artifacts on each branch even if you set an expiry. On a gitlab instance with even moderate development rate and moderate-sized artifacts this fills up the hard-disk with artifacts that the admin must manually delete (or manually create their own script to delete them, which is still a pain). However, their fix was to add a checkbox that defaults to the buggy behavior. Per project. So for every new user's project I have to manually tell them to turn this anti-feature off to keep from filling up the hard-drive with artifact spam. Or else write a damned script to go in and turn off this feature periodically.
The community edition of Gitlab feels a lot like the early Gnome 3 touch-screen stuff. Great in theory, but one quickly gets the sense that no one is dogfooding-- if they did these kinds of problems wouldn't exist.
Why isn't there an email provider that allows you to 1) whitelist the content and 2) manually register the to and from addresses and 3) specify how many emails you estimate you will be sending?
At first glance, #1 seems tricky. But, I could see this as an opportunity to bring my users back to the site by providing very specific content teasers.
#2 feels possible in certain circumstances. If you can register the addresses when the user registers, you could avoid problems like changing addresses.
#3 seems like it would be problematic for the email provider who probably doesn't want to build a feature that reduces the ability to bill you. But I would pay for it.
If you had all this, couldn't this prevent the problems described here and incentivize the spammers to find a different, easier target?
what is the motivation behind attacks like this? Like is whoever put in the effort to do this just trying to annoy Gitlab's customers? What do they gain from that?
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/