RubyGarden Spam

[Curt Hibbs]

I'd certainly be against it, I know spam is a bad thing and indeed my
own wiki has had it from time to time but requiring authentication /
registration removes a freedom from people they shouldn't have to give
up and might indeed push people away from using it.

It certainly would be tolerable if a wiki is only spammed from time-to-time.
I have five project wikis on RubyForge, and I have to go clean up the spam
*every* day. This is more than troublesome, it is beginning to make wikis
unusable.

Austin Zeigler is adding authentication to Ruwiki, and Tom Copeland is going
to tie that into the RubyForge. So once all this is in place, the default
RubyForge wiki will be Ruwiki and a single login to RubyForge will suffice
for all normal RubyForge activities *as well as* all RubyForge hosted wikis.

This will help, but obviously won't be the final answer. At least we will
have a wiki written in Ruby, maintained by someone in our own community,
where we can react intelligently to the ever-changing spam threats.

Curt

 

[Curt Hibbs]

Curt Hibbs [mailto:[email protected]]

Austin Zeigler is adding authentication to Ruwiki, and Tom
Copeland is going
to tie that into the RubyForge. So once all this is in place, the default
RubyForge wiki will be Ruwiki and a single login to RubyForge will suffice
for all normal RubyForge activities *as well as* all RubyForge
hosted wikis.

This will help, but obviously won't be the final answer. At least we will
have a wiki written in Ruby, maintained by someone in our own community,
where we can react intelligently to the ever-changing spam threats.

I forgot to mention... On one of my RubyForge wikis, the home page had been
spammed so many times that the original content had rolled off the version
history and I was unable to recover it. This is why I started checking for
spam every day. It is a royal pain-in-the-butt and I can't wait until I no
longer have to do this.

Curt

 

[Gavin Sinclair]

Curt Hibbs [mailto:[email protected]]

Austin Zeigler is adding authentication to Ruwiki, and Tom
Copeland is going
to tie that into the RubyForge. So once all this is in place, the default
RubyForge wiki will be Ruwiki and a single login to RubyForge will suffice
for all normal RubyForge activities *as well as* all RubyForge
hosted wikis.

This will help, but obviously won't be the final answer. At least we will
have a wiki written in Ruby, maintained by someone in our own community,
where we can react intelligently to the ever-changing spam threats.

I forgot to mention... On one of my RubyForge wikis, the home page had been
spammed so many times that the original content had rolled off the version
history and I was unable to recover it. This is why I started checking for
spam every day. It is a royal pain-in-the-butt and I can't wait until I no
longer have to do this.

See Jim's patch for UseModWiki at http://onestepback.org. He's
actually done something about Wiki spam. Is that a record?

Gavin

 

[Curt Hibbs]

Curt Hibbs [mailto:[email protected]]

Austin Zeigler is adding authentication to Ruwiki, and Tom
Copeland is going
to tie that into the RubyForge. So once all this is in place, the default
RubyForge wiki will be Ruwiki and a single login to RubyForge will suffice
for all normal RubyForge activities *as well as* all RubyForge
hosted wikis.

This will help, but obviously won't be the final answer. At least we will
have a wiki written in Ruby, maintained by someone in our own community,
where we can react intelligently to the ever-changing spam threats.

I forgot to mention... On one of my RubyForge wikis, the home page had been
spammed so many times that the original content had rolled off the version
history and I was unable to recover it. This is why I started checking for
spam every day. It is a royal pain-in-the-butt and I can't wait until I no
longer have to do this.

See Jim's patch for UseModWiki at http://onestepback.org. He's
actually done something about Wiki spam. Is that a record?

I sent that patch to Tom Copeland yesterday. He's looking into incorporating
that into the existing RubyForge wiki's to give us some relief until Austin
has Ruwiki authentication finished.

Curt

 

[Gavin Sinclair]

Curt Hibbs [mailto:[email protected]]

Austin Zeigler is adding authentication to Ruwiki, and Tom
Copeland is going
to tie that into the RubyForge. So once all this is in place, the default
RubyForge wiki will be Ruwiki and a single login to RubyForge will suffice
for all normal RubyForge activities *as well as* all RubyForge
hosted wikis.

This will help, but obviously won't be the final answer. At least we will
have a wiki written in Ruby, maintained by someone in our own community,
where we can react intelligently to the ever-changing spam threats.

I forgot to mention... On one of my RubyForge wikis, the home page had been
spammed so many times that the original content had rolled off the version
history and I was unable to recover it. This is why I started checking for
spam every day. It is a royal pain-in-the-butt and I can't wait until I no
longer have to do this.

See Jim's patch for UseModWiki at http://onestepback.org. He's
actually done something about Wiki spam. Is that a record?

I sent that patch to Tom Copeland yesterday. He's looking into incorporating
that into the existing RubyForge wiki's to give us some relief until Austin
has Ruwiki authentication finished.

As Mr. Burns would say, "Ex-cell-ent".

I suspect that particular patch will be insufficient against sustained
attacks, because some of them will be deemed acceptable, because they
will use "HTTP" instead of "http". Still, it's a start, and one that
can be tailored.

Cheers,
Gavin

 

[Bill Guindon]

As Mr. Burns would say, "Ex-cell-ent".

I suspect that particular patch will be insufficient against sustained
attacks, because some of them will be deemed acceptable, because they
will use "HTTP" instead of "http". Still, it's a start, and one that
can be tailored.

which led to the odd thought, ok, make it case insensitive (which got a chuckle)
which led to... on edit: gsub(/http:/i, 'spam:') on display:
gsub(/link:/, 'http:')

tough to implement (would need to modify current content)
nuisance to users, as they'd have to learn new link method.
easily defeated

that said, it's still a thought, and worth sharing. could inspire
other thoughts..

 

[Andreas Schwarz]

It certainly would be tolerable if a wiki is only spammed from time-to-time.
I have five project wikis on RubyForge, and I have to go clean up the spam
*every* day. This is more than troublesome, it is beginning to make wikis
unusable.

I am using MediaWiki (the Wikipedia software), and because I can
rollback all changes from one IP with a single click, and ban this IP
with another click, it is really no valuable target for spammers, and I
never had problems with spam.

 

[Tom Copeland]

As Mr. Burns would say, "Ex-cell-ent".

The tricky bit is that we're running UseMod 0.91 on RubyForge and the
patch is for UseMod 1.0. And upgrading UseMod is a bit of an involved
process - I can't see a good way to do it with a script. So I may have
to do it Wiki by Wiki... argh...

Yours,

Tom

 

[Jim Weirich]

Tom Copeland said:

The tricky bit is that we're running UseMod 0.91 on RubyForge and the
patch is for UseMod 1.0. And upgrading UseMod is a bit of an involved
process - I can't see a good way to do it with a script. So I may have
to do it Wiki by Wiki... argh...

Tom,

If you would like, I'd be glad to adapt the patch for 0.91. The patch is
pretty simple minded, so it shouldn't be hard.

I might not have time to do it before RubyConf tho (wouldn't /that/ be
ironic ... hacking perl code at RubyConf)

 

[Curt Hibbs]

I am using MediaWiki (the Wikipedia software), and because I can
rollback all changes from one IP with a single click, and ban this IP
with another click, it is really no valuable target for spammers, and I
never had problems with spam.

That's a very nice feature and, perhaps, its the kind of thing we could get
into Ruwiki over time.

Curt

 

[Austin Ziegler]

That's a very nice feature and, perhaps, its the kind of thing we
could get into Ruwiki over time.

I'll have to look at the MediaWiki software to see how this is done;
perhaps it can be a 1.0 target feature -- but there are a lot of
features still desired and requested.

I'm currently approaching Wiki-spam from the concept of reducing the
value of wiki-spam as well as (ultimately) making it harder to spam
wikis without harming the overall usability.

There *will* have to be some rearchitecture of Ruwiki to make this
happen -- the current processing pipeline is not as straightforward
as I would like.

That said, I think that I'm close to testing Ruwiki on RubyForge --
watch ruwiki.rubyforge.org in the coming days.

-austin

 

[Tom Copeland]

If you would like, I'd be glad to adapt the patch for 0.91. The patch is
pretty simple minded, so it shouldn't be hard.

Hi Jim -

That'd be cool! Actually, I should give it a whirl myself... at one
point I flailed around with Perl a bit...

I might not have time to do it before RubyConf tho (wouldn't /that/ be
ironic ... hacking perl code at RubyConf)

Pragmatism uber alles...

Yours,

Tom

 

[David Ross]

Hi Jim -

That'd be cool! Actually, I should give it a whirl myself... at one
point I flailed around with Perl a bit...


Yours,

Tom

So is that the plan of action? I know I could talk over irc but you
disappear *poof*. I am starting to dislike how open wikis are to abuse
I wonder how wikipedia blocks spam.. only one way to find out.
/me joins freenode channel for wikipedia

okay. #1 comment from me.. block open proxies. I could give you a whole
list of common and specal ports that are in use by attackers.
*yes yes.. I am not talking just about ports like 80,8080, 1080, 3128,
there are more ports that crackers actually use *duh*

-- from #wikipedia
#2 mandatory time limit between edits
#3 look at mediawiki in editpage.php - spam regex $wgSpamRegex