[aur-dev] Fighting spam on the AUR

[Limao Luo]

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.
>>
>> 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.

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 [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 
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% 
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.