Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: Trac Spam  (Read 6091 times)
Technomage
Admin
Community member

Posts: 80



View Profile
« on: April 10, 2011, 10:06:40 PM »

I've noticed, as I'm sure most of you have, that the Planet feed is full of spam tickets being posted on Trac. I've sent barra an email about it so hopefully he'll be able to clear out the offending tickets soon, but I think that there is a larger infrastructure issue here.

I recently ran into a blog entry entitled "The Death of CAPTCHA" (http://www.terminally-incoherent.com/blog/2008/07/01/the-death-of-captcha/) in which the author suggests in no uncertain terms that CAPTCHAs and other bot detection methods are pretty much obsolete, since quite a few companies are now offering large-scale manual spamming operations. While I commend these companies for improving oppertunities for minimum wage employment  Angry, this does put another nail in the coffin of our bot-checking approach to preventing spam.

I've been thinking about the alternative approaches we can take. We can try adjusting Trac's Akismet spam rules or switch to another filtering system, but I'm inclined to reject filtering all together for the following reasons. First, it isn't foolproof and the stricter we make the filters the more likely it will be that we reject legitimate Trac tickets. Second, any spam which DOES make it through the filters and isn't dealt with immediately increases the likelihood that we receive more spam: the company doing the spamming sees our site as an easy target (I'm not just being paranoid - these companies use various algorithms to rank sites for how easy they are to spam in order to maximize their efficiency).

Instead, I suggest that we require ALL new Trac tickets to be moderated before they are posted. Since we're going to have to moderate Trac no matter what method we use to prevent spam, we might as well make our effort worthwhile and prevent spam before it is posted rather than after the fact. We can keep the existing bot-checking filters as they can reduce or eliminate automatic spam and thus reduce our moderation effort.

I remember reading another blog about preventing spam not long ago which  - I couldn't remember where I saw it, but the basic idea was this: to prevent spam, a large website posted a brief but prominent disclaimer on every page with a submit button. To paraphrase, the disclaimer basically said "We actively check for spam and most of it is deleted within minutes of being posted, so don't waste your time trying to spam us." Remarkably, spam on the site was drastically reduced (something like 80%) just because of that simple disclaimer. The lesson is this: if we make it extremely difficult to spam our sites and advertise that fact, our moderation effort is likely to be very small.

Anyway, those are my ideas. Any thoughts?
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #1 on: April 11, 2011, 08:53:21 AM »

The situation is complicated here.

First thing is that not long while ago some of us had Trac permissions sufficient to delete tickets by hand. We could make some cleaning, and it was not hard nor laborious for us. Recently this has changed, and no one has this abilities any longer - maybe due to some infrastructure upgrade, maybe barra demoted us for a good reason.

As for Trac policy - I'd gladly disallow any links in anonymous tickets. This will fix the problem forever. File attachments, which were always possible, should suffice to communicate anything by a person that just passes by - attaching error log, screenshot, patch, whatever needed into ticket. This also needs no management.
I'm usually required to setup an account prior to posting bug reports in any major project, so others policies are even more restricted.

Third problem is Martin himself - vanishing without warning, right in the middle of our work.

His plans or reasons are nowhere to be found, we have zero chances to push things forward in planned direction without him sharing some vital information upon how should sprint end look like. I'm asking myself frequently if he is responsible or mature enough to manage my effort. Project is afloat for good couple of years, yet nearly no administrative privileges are distributed, nor managers duties, for the time he is more or less busy. Less important stuff is neglected as well, waiting for an ultimate solution (3D artwork pipeline is pretty vital example for lesser importance thing). And every time when something like what we have now strikes - project stalls without any really good reason. And few good person-years of collected effort are just waiting for a guy to sort out his real-life issues, people are waiting and getting bored or frustrated.

To be honest, I still adore Martin's management,  he has done great job here, and I'm nowhere close to leaving or conflicting (or managing... especially if the one to conflict with is absent, conflicting is pretty much impossible Cheesy). This is not the first time when something like that happens, but I just hope it will be the last such event.

As for disclaimers - I've seen things like "If you like to contact me, my mail is blablabla. If you send me any advertisements, viagra commercials, dating proposals and other spam, you have to pay me 100 $. If you won't pay me, I'll go to court to take 10 000$ for me and my trustworthy lawyer. This is not a joke."
« Last Edit: April 11, 2011, 08:58:08 AM by Q_x » Logged

Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #2 on: April 11, 2011, 06:08:20 PM »

I get what you're saying and I agree with most of it. I strongly advocate for shared administrator access to all of our web infrastructure so that we don't end up in this kind of situation again. If barra doesn't reappear in a reasonable span of time then I think that we can and should set up a new set of websites and transfer as much information as possible from the old ones - I don't relish the idea of abandoning our web infrastructure, but if it is holding us back then so be it.

However, I think there is a larger project culture issue here that needs to be addressed. Barra is an incredibly capable leader, so capable in fact that I think we've all been relying on him far too much to push the project forward. It really isn't fair of us to delegate so much of the project's infrastructure maintenance to barra - its not like he's being paid a salary for doing it. By relying on barra so much we've also set our bus factor to "1", i.e. if barra disappears the project dies. This is simply unacceptable for an open source, volunteer-based project. Practically no large, successful open-source projects exist that delegate major infrastructure maintenance to a single person - Python has Guido van Rossum, but he doesn't manage python.org by himself! The Apache project does practically everything by committee.

I think that this project needs a drastic change in project culture. We all need to be project managers working to maintain and propel PARPG forward. I feel like we're all trapped in our little area of expertise and unwilling to venture outside of it. Instead of saying "that's not my area of expertise" we all need to step up to the plate and out of our comfort zones. I recognize that everyone is volunteering their free time and that most don't have the time, energy or desire to learn new skills, but at the very least anyone could help advertise for new developers in the areas where we're lacking skills.

Most importantly, we need to make sure that at every point in PARPG's evolution that every developer has the tools and ability to manage the project infrastructure. This means demanding equal access to all project resources and administrator rights to all project infrastructure, and not being shy about it.

In practical terms, I think that this means:
  • All current developers need full administrator access to our project infrastructure, and we need some way of making sure that access cannot be denied by any one person
  • We need more developers with website management and development skills
  • We need more programmers who are willing and able to work on tools and GUIs
  • If the new agile development process is slowing us down because of lack of knowledge, then either a) everyone needs to do some research and learn about it, b) we need to pick and choose some elements of agile development we are familiar with (sprints, product backlog) and drop the rest or c) we need to scrap it all together

Case in point: if the sprint end isn't well defined, then lets define it. There's no sense in waiting for barra to do it for us.

I don't want to sound presumptuous - after all, I've only been here for a few months when most others have been with the project for years - but I feel very strongly about this, and I want to get the discussion going about the long-term viability of the project.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #3 on: April 11, 2011, 06:16:19 PM »

This is just a thought, but why don't we start having regular weekly or bi-weekly (meaning every two weeks) meetings to discuss the current state of the project. This way we would have a dedicated time slot for real-time discussions. It may be that we also want to setup some kind of elected committee system that rotates every month or so to make task delegation easier to manage.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #4 on: April 11, 2011, 06:34:29 PM »

Well, this pretty much reminds me of headless development times, when Beliar, Domtron and me did some enormous progress (and haven't ceased the project). Especially the spirit.
When Martin came back, he said he will be there for a month or so and will try to breathe a new spirit into the project, which he did, and was here longer than expected anyway.
I'd rather assume he will be back and push him to give some of us access to some places, as this is what we need, not backups. Using some h4x0r soft to copy wiki database may be in fact a waste of time.
Logged

zenbitz
Community member

Posts: 1164



View Profile
« Reply #5 on: April 11, 2011, 10:53:03 PM »

I can probably show up to weekly meetings and help provide direction, etc.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #6 on: April 12, 2011, 02:36:17 PM »

Well, this pretty much reminds me of headless development times, when Beliar, Domtron and me did some enormous progress (and haven't ceased the project). Especially the spirit.

How did that work out in terms of project management? I'm just curious as to how the three of you worked together, what sort of things went well, what didn't go so well... etc. I think some of the agile process has proved useful, but any lessons learned from that time would be helpful to know.

When Martin came back, he said he will be there for a month or so and will try to breathe a new spirit into the project, which he did, and was here longer than expected anyway.
I'd rather assume he will be back and push him to give some of us access to some places, as this is what we need, not backups. Using some h4x0r soft to copy wiki database may be in fact a waste of time.

Hmm, I wasn't aware of that. We should definitely push barra to give us administrator access to all of our web infrastructure, but my point was that we shouldn't let the infrastructure slow us down if he doesn't show up within a month or two to do so.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #7 on: April 13, 2011, 07:26:43 AM »

Technomage, headless development time was really pitiful experience, at least in my case. We have focused on the tasks I think can  be described as rewarding - eg. fancy cursors, main menu, and making brewing beer possible.
We did no management at all - anyone could do anything, and in fact it "kind of worked", as we focused strictly on most important small (small enough to tackle by one person) tickets.
Not much to learn from that, apart from avoiding the state in the future.
« Last Edit: April 13, 2011, 08:34:44 AM by Q_x » Logged

Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #8 on: April 18, 2011, 06:10:22 AM »

Barra gave me admin rights to Trac/Codesion today and I managed to delete all of the offending tickets. I also cleaned up the Planet feed as best I could. Apparently the Trac spam filter plugin wasn't configured properly and was letting obvious spam through, so that might have been the source of our recent spam attack. I don't know if Codesion accidentally reset our configuration or what, but in any case I made it significantly harder for a manual spammer to post a suspect ticket and limited the number of anonymous submissions from a single IP address to 2 per hour. Hopefully this significantly reduces our spam.

Someone suggested that we get rid of the anonymous submission process altogether and require users to register with our Trac site before submitting a ticket. I whole-heartedly support that idea. After all, what's the point of anonymous ticket submissions if our spam filters are so strict that they can't get through? (besides annoying the submitter)
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #9 on: April 18, 2011, 07:36:50 AM »

We had like 3 spam pieces daily, so I doubt if 2 per hour will change anything, honestly.
And limiting anything beyond for 24h period is quite pointless as well.

The policy IMHO should not be demotivating for spamers, but simply should disallow any spam. "Having login" policy is good, as long as it is for free, same seems to be disallowing any links in anonymous tickets or comments.
Logged

mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #10 on: April 18, 2011, 12:32:13 PM »

You can't login for free, as codesion doesn't allow anonymous users to register for Trac accounts. So our only choices are:
a) Don't allow anonymous tickets
b) Allow them, but mail the codesion support staff so they fix the logging and spam issues. Spam blocking worked fine in the past and nobody reset the Trac configuration lately, so I'm 100% sure that an update on codesion's side screwed something up.
Logged
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #11 on: April 18, 2011, 07:16:33 PM »

You can't login for free, as codesion doesn't allow anonymous users to register for Trac accounts.

That's unfortunate. I guess we just have to make do with the anonymous tickets.

Just to clarify, the spam filtering IS working now. I tested it by copying several of the spam tickets and attempting to submit them. I don't want to expose too much detail about our spam filtering in public, but basically our filters had a loophole that allowed obvious spammers to submit anyway by passing a CAPTCHA. We were simply putting too much weight on the CAPTCHA response, so I reduced that weight and strengthened some of the filters.

The policy IMHO should not be demotivating for spamers, but simply should disallow any spam.

Unfortunately there is always a trade-off here. We use some pretty sophisticated filters that work quite well, but even the most advanced filter is going to have some false positives and false negatives. If we strengthen the filters, then we risk blocking valid submissions (this was the case several months ago when I first joined the project).

I'm hoping that my changes to the spam filters will prevent the type of spam we saw over the past two weeks. I'm also going to try and get Codesion to fix the logging so that we can see how our spam filter is working and better fine-tune it.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #12 on: April 18, 2011, 07:18:42 PM »

Heya techno, nice work with the Trac plugin tweaking.

For some odd - but very fortunate - reason, Trac logging seems to be working fine again here. Could you please check if it does work again for you as well?
Logged
Pages: [1]
Print
Jump to: