On Mon, Apr 28, 2008 at 03:48:27PM +1000, William Uther wrote: > > On 27/04/2008, at 9:58 AM, [EMAIL PROTECTED] 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.
I agree. But it's one of the reservations I have about a completely distributed wiki. If it's popular enough toe make distribution necessary for scalability (as opposed to backup and convenience), it will be big enough for spam to be a problem. -- hendrik _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
