> I've got a list, but it has become obvious that maintaining a list
> manually isn't going to work. I'm tempted to require registration and
> authentication at this point as much as I hate the thought.
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
···
Also there is nothing to stop spammers from setting up a ton of "junk"
accounts to get around it. This has happened a lot on Yahoo Groups and
the group we are in basically decided that new users (for a period of
a couple of weeks) has to have their posts moderated. This was to
prevent general spam and job solicitations. I can't think of a way to
make that sort of scheme work in a Wiki environment though.
Rob
--
Personal responsibility is battling extinction.
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.
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.
See Jim's patch for UseModWiki at http://onestepback.org. He's
actually done something about Wiki spam. Is that a record?
Gavin
···
On Tuesday, September 28, 2004, 10:53:17 PM, Curt wrote:
Curt Hibbs [mailto:curt@hibbs.com]
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 Hibbs wrote:
> 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.
That's a very nice feature and, perhaps, its the kind of thing we could get
into Ruwiki over time.
> Curt Hibbs [mailto:curt@hibbs.com]
>>
>> 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
···
On Tuesday, September 28, 2004, 10:53:17 PM, Curt wrote:
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.
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.
That's a very nice feature and, perhaps, its the kind of thing we
could get into Ruwiki over time.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
: as of this email, I have [ 6 ] Gmail invitations
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
···
On Tuesday, September 28, 2004, 11:49:00 PM, Curt wrote:
Gavin Sinclair wrote:
On Tuesday, September 28, 2004, 10:53:17 PM, Curt wrote:
> Curt Hibbs [mailto:curt@hibbs.com]
>>
>> 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.
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..
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.
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
···
On Tue, 2004-09-28 at 10:02, Gavin Sinclair wrote:
On Tuesday, September 28, 2004, 11:49:00 PM, Curt wrote:
> 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.
On Tue, 2004-09-28 at 10:02, Gavin Sinclair wrote:
On Tuesday, September 28, 2004, 11:49:00 PM, Curt wrote:
> 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".
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)
> 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...
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)
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...
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...
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
I wonder how wikipedia blocks spam.. only one way to find out. 