Re: [Monotone-devel] Re: Monotone spam (was: wiki spam)

[William Uther]

On 27/04/2008, at 9:58 AM, address@hidden wrote:

> On Sun, Apr 27, 2008 at 12:39:25AM +0200, Thomas Keller wrote:
> > The amount of wiki spam gets more and more annoying - do we already  
> > have
> > something setup like this [0] for our MoinMoin installation?
> >
> > And, can we somehow easily block certain IP (ranges) through
> > LocalBadContent as well? Whoever recently defaced our FrontPage  
> > used an
> > IP inside the range 89.149.241.0 - 89.149.244.255 which is assigned  
> > to a
> > small German web hoster [1], so it would not be a big / global  
> > issue to
> > just block his further attempts.
>
> Eventually, there's going to be monotone spam.

Monotone is generally used in situations where there is more control
over the user-base than you're assuming.  We don't have CVS spam, and
the wiki is no more distributed than CVS.

> In a distributed network of monotone installations, especially in a  
> large one,
> someone, somewhere, is going to check in a revision containing load of
> spam, and netsync will quickly, and efficiently, spread this to all  
> the
> machines in the net.  Once it's done once, of course, it will be done
> again and again.  Now the security model can be configured to
> ignore the certificates relating to the spam, and maybe repeatedly
> reconfigired as necessary,  but do we have any effective way of
> reclaiming its disk space?

Not yet.  Does MoinMoin reclaim the space of old spammed pages, or does
is just revert the main page and leave the spam in the history?

Hrm.  As an aside, is there something stopping Google from indexing the
history on the wiki (nofollow or robots.txt), or are those history
links useful for SEO even once they've been reverted?

It would be nice to have a way to reject revs signed by a particular
person on sync, unless they're also signed by someone else, or a child  
rev
is signed by someone else.  This would stop bad revs from being sync'd
all over a cloud.  This feature would be much easier to implement in  
nuskool
I suspect.

> Now I don't think it's urgent to solve this problem now, but it's
> important to brainstorm solutions, so that when the time comes, we  
> won't
> have implemented a lot of things that make spamfighting hard.
>
> This is related to the problem discussed a few months ago about a
> mechanism to permanently expunge a particular revision from all copies
> that might exist enywhere.  There I believe the motivation was to  
> revoke
> copyright violations.

Yeah - it's useful.  I don't think it is the highest priority though.

Cheers,

Will         :-}