[Maybe Spam] Re: Swiki vandalized

Frank Shearar Frank.Shearar at rnid.org.uk
Wed Jan 26 11:45:33 UTC 2005



> -----Original Message-----
> From: Cees de Groot [mailto:cg at cdegroot.com]
> Sent: 26 January 2005 11:19
> To: The general-purpose Squeak developers list
> Subject: Re: [Maybe Spam] Re: Swiki vandalized
> 
> 
> On Wed, 26 Jan 2005 10:45:21 -0000, Frank Shearar  
> <Frank.Shearar at rnid.org.uk> wrote:
> > These bot-driven defacements are EASY to fix(*).
> 
> If they're really bot-driven, they're even easier to prevent, 
> I think. Add  
> a gif-with-numbers (should be easy enough to create a Squeak 
> snippet to  
> generate that) for human-presence confirmation on edits, and add  
> 'rel="nofollow"' to all the links and prominently display 
> that fact on the  
> edit page (actually, I have mixed feelings about that latter 
> bit as well).

We had a bit of a discussion on "captcha" tech not too long ago, actually. In early December, I think. In summary, my feelings are: "use it if you must, but make sure blind/vision-impaired people have an equivalent", and that equivalent MUST NOT be "get a sighted person to help out".

> > Don't lock down the Swiki just for these. Yes, it's 
> annoying. It's like  
> > someone throwing garbage on your lawn just after you've 
> cleaned it. But  
> > I don't think that the price is worth what little we get from it.
> >
> Would you feel a Terminus-based solution, where only 
> Apprentice+ people on  
> SqP could add links, to be too high a price? Not that I'm in 
> any position  
> to add Terminus to minnow, just feeling around for the 
> general sentiment  
> on this.

That's not too bad, actually. My first thought was "no" because I like open systems, but disallowing adding new links (that is, external links as opposed to links to other pages on the wiki) isn't terribly onerous.

Having said that, if you're going to have permissions, I like the idea of tying permissions to reputations & reputation servers. One caveat with reputation servers is that it requires members of a community to update their opinions of others. Otherwise you get some poor guy slaving 24/7 for Squeak, submitting fantastic change sets, and he's still only an Apprentice.

> > Having said that, MediaWiki have a very nifty feature where 
> admins can  
> > ban IPs or even IP ranges for limited periods of time. (I 
> don't know  
> > what the upper limit is: the field is a text field, so 
> presumably you  
> > could even specify "10 years".)
> >
> Problem is, most of these seem to come from dynamic IP 
> address ranges (I  
> have a lot of trouble with bots on www.cdegroot.com wiki's, 
> so I'm a bit  
> experienced, alas). So by the time you discover this and add 
> the IP these  
> guys probably already are working from another one.

Agreed. You could block a C class, but then of course you potentially block innocents too. If you can catch an attack in progress banning the IP will prevent _further_ damage, but that depends on your time zone & how often you check the swiki.

Hm, wouldn't it be nice to have some serious log introspection for a wiki? Then you could check usage patterns for particular IPs and know that attacks usually occur at time N from block B, you know? (This violates privacy of users on a grand scale, so you really want this admin-only or something.)

frank


*******************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.
If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.
If you have received this email in error please notify the RNID
Helpdesk by telephone on: +44 (0) 207 296 8282.
The Royal National Institute for Deaf People
Registered Office 19*23 Featherstone Street
London EC1Y 8SL No. 454169 (England)
Registered Charity No. 207720
********************************************************************




More information about the Squeak-dev mailing list