Joined: 1 Jul 16
I recently found out the service called Stop Forum Spam (SFS) can be used to inhibit mass user account creation on BOINC project forums. I found out because somehow my email/username got lumped in with their data and can no longer sign up to any forum using SFS. The IP listed I think is from PrivateInternetAccess VPN as it's not my local ISP IP. I'm all for inhibiting spammers and other scum but putting that kind of control into an outside service is a going down a slippery slope.
1 - Email lists are sold all the time and any email could be used to spam forums. Any of us can end up on that list and we'd be locked out of any new project that decides to use this service.
2 - Getting emails/userIDs removed is controlled by 1 single person at SFS.
3 - Getting info removed from SFS is not instant. It's not the next day. It's been nearly two weeks from my 1st request. Project competitions are announced, start and end in less time then their removal response. That is IF they even do it.
4 - Supposedly someone could be blocked from signing up to a project forever w/o ever doing anything wrong.
5 - Some BOINC project admins are not very active to whitelist emails. If spammers get ahold of a BOINC email email/user list, I doubt any project admin could whitelist all of its users.
The BOINC project admin points to the SFS admin as SFs controls the data and SFS moderator points back at the project admin to have the email whitelisted. The SFS moderator said to change my online identity so I could sign up to the forum. With how BOINC references the same email/username to sync up CPIDs that's not really an option here. I can change my userID after signed up but the email is still blocked from BOINC account creation.
I'm not sure why this route for SPAM control was chosen but I'd like it to move in another direction. I've never even heard of SFS until recently. I've heard some of the projects nearly get shut down due to the excessive load and database growth. As a user I've seen project sites become sluggish due to spammers.
Lets say that SFS is not an option. Other sites/forums must control this somehow. Some of the things that come to mind that BOINC project sites do not use are:
1 - Email validation. Any fake email could be entered to sign up for a BOINC project. There's to validation email sent before the account could be used. Email creation and validation link clicking could be automated by spammers as well so there of course needs to be more.
2 - Captcha phrases/image identication. Some of these can be a pain to read. Click images of street signs, cars or type in the letters. ETc, etc. Even the SFS forum as one where chooses images of female characters and I had to study the images as they were subtle feminine differences.
3 - Google's 'I am not a robot' mouse click. Not sure how that works but if it's good enough for Google there's a good chance it does its job.
Heck, all 3 options could be implemented. That seems more like the norm these days to do at least an email verification and one of the robot prevention mechanisms.
Going through the process of getting my email cleared as been very frustrating. Again only one person has complete control of this. It took several attempts to get an automated verification email. My VPN and ISP IPs were blocked at their own forum registration so I couldn't even sign-up to ask a question. I had to do it from work.
Can something else be implemented in the standard BOINC server setup?
Joined: 29 Aug 05
Using Stopforumspam.com gives us less traffic on the servers, and certainly less spammers leaving everything they can. Just look at https://boinc.berkeley.edu/dev//top_users.php, a lot of those are spammers, they just can't leave their crap anymore because they're blocked from doing so. But even then, some manage to get through:
We have had a human spammer on these forums the past 14 days, they would easily circumvent all of your options given, because:
1 - Email validation. Any fake email could be entered to sign up for a BOINC project. There's to validation email sent before the account could be used. Email creation and validation link clicking could be automated by spammers as well so there of course needs to be more.Spammers can use real email addresses as well, easily registered under their own spam business. So validating email addresses doesn't work in this, and wouldn't have worked against the human spammer taking it out in these forums.
2 - Captcha phrases/image identication. Some of these can be a pain to read. Click images of street signs, cars or type in the letters. ETc, etc. Even the SFS forum as one where chooses images of female characters and I had to study the images as they were subtle feminine differences.Since it was a human spammer, they'd easily pass captcha's. Even then, captcha's can be circumvented by automated spammers as well. As can tokens. As can a lot of other options.
3 - Google's 'I am not a robot' mouse click. Not sure how that works but if it's good enough for Google there's a good chance it does its job.Human spammer. He can get through this.
The present fix is holding the spammer back, until he figures out what we've done. Then he'll be back. In this very forum as well, as that was one of his favorites to put his stuff in, every hour.
I personally don't really see the need to use a VPN on projects or these forums, as what data you exchange with them and us isn't going to be of such a nature that it needs end-to-end encryption.
Joined: 1 Jul 16
I human spammer is doing all this every hour? That's not really sustainable. And it seems like extra protections beyond SFS or any of these email registrations/captchas are needed to stop human spammers anyway.
In no way did I suggest using a VPN and BOINC would not be a reason for me to use a VPN. That is until Net Neutrality gets dumped and DC data gets the slow lane. I'm guessing I used the IP while on a VPN or maybe the spammer just used my email while on that IP.
The only evidence SFS has for that IP is against the very 1st user, not even me. Spammers just move on to another IP/name and others get punished.
Copyright © 2024 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.