Hi, just an AUR spam "victim" here. I had a relatively recent case of one account flagging all of my 183 packages alphabetically at 90- to 120-second intervals. When I began to unflag some of them, a new account flagged those at 60-second intervals the next day. On 03/13/2013 10:36 AM, Kwpolska wrote:
On Wed, Mar 13, 2013 at 11:33 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Status quo:
06:54 < gtmanfred> ok, it really is time for something else 06:54 < gtmanfred> the spammer is now creating a new account for every comment and flag out of date
The account suspension feature does not help here.
Options:
* Allow package maintainers to block the "Flag package out-of-date" feature for a certain amount of time. Note that this might eventually cripple the "out-of-date" function. Also, this does not work for comments. I suggest a flag 24–hour immunity for added/updated packages and a 60–minute immunity after a package gets unflagged.
* Use CAPTCHAs during account registration. We could either use MAPTCHAs ("What is 1 + 1?") or something like reCAPTCHA [1]. MAPTCHAs can be solved easily by bots, reCAPTCHA itself is evil, and image CAPTCHAs can be solved by Indians for a dollar or two per thousand images.
* Moderate new accounts. Might be a lot of work. We need some TUs that review and unlock accounts. Also, it might be hard to distinguish a spam bot from a regular user. If we require a short application text, this might result in less users joining the AUR.
Maybe block the ability of commenting and flagging in the first 24 hours of an user account’s existence? If someone is a new user, they probably want to either comment about a
* Block IP addresses. Bye-bye, Tor users! Don’t worry, http://proxy.org is here to help our lovely spammers.
Also, is email verification necessary? If yes, block 10minutemail.com and other services of this kind. If not, make it so and see “if yes”. Blocking disposable email sites is just playing catch-up. Looking at some of the few other users affected around the same time, all spam flags were done by different accounts with different disposable email sites. Just googling quickly, I can find dozens of various disposable email sites that haven't been used as of yet. Also, this catch-up game is a no-win for mods (TU's); when you take this to its logical conclusion, you get horrendously large databases of spammer's IPs, emails, etc. This is evidenced by stopforumspam.com, which, in an attempt to combat spam, has amassed almost 44 million spammer records. It's a waste to attempt to recreate this kind of thing on the AUR with
In my case, this wouldn't have helped. The spammer waited >24 hours to start reflagging my packages. And if we start extend these intervals, it just wastes the time of legitimate users. package, flag a package, or upload one or two PKGBUILDs. If they're not interested in maintaining packages, then their account is essentially useless for the first 24 hours. these stopgap measures, really. I don't remember if you need to verify your email when you create an AUR account, but that's definitely a good starting point. Still, a lot of these sites allow you to read any email sent to the disposable address (while you have the site tab open), so it's not even close to 100% effective.
-- Kwpolska <http://kwpolska.tk> | GPG KEY: 5EAAEA16 stop html mail | always bottom-post http://asciiribbon.org | http://caliburn.nl/topposting.html
All the solutions posted on this thread (besides Xyne's) are really going in the wrong direction; not only are they just rehashes of old discussions on aur-dev/aur-general, they're focusing on things like IP address and email, or setting time limits, when they should be addressing the behavior itself. These other things can be circumvented (with very minimal effort on the spammer, I will note, but manage to cause significant annoyance to most users), but when a user is, say, systematically flagging one maintainer's packages alphabetically [1], there should be a system (as Xyne has detailed) in place to address the behavior manually (i.e. with TU intervention). If TU's must intervene anyway, let's use some proactive measures, shall we? [1] This is just an example, so don't focus in too hard on this specific behavior and lose sight of the big picture of preventing spam (useless comments, incorrect flags, junk PKGBUILDs) of all kinds. For example, the spammer could have a list of maintainers and cycle through the list, or iterate over them pseudo-randomly, and that would defeat measures tailored to the specific aforementioned behavior.