[aur-dev] Fighting spam on the AUR
luolimao at gmail.com
Wed Mar 13 21:27:54 EDT 2013
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 at 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.
>> * 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
> I suggest a flag 24–hour immunity for added/updated packages and a
> 60–minute immunity after a package gets unflagged.
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.
>> * Use CAPTCHAs during account registration. We could either use MAPTCHAs
>> ("What is 1 + 1?") or something like reCAPTCHA .
> 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
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.
>> * 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
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%
> 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 ,
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?
 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.
More information about the aur-dev