[Systems] pe.wiki cleanup

[Chris Leonard]

On Wed, Nov 28, 2012 at 7:50 AM, Sebastian Silva
<sebastian at sugarlabs.org> wrote:
> Thanks to everyone involved and to the students. I didn't set up the wiki
> originally and indeed proper anti-spam countermeasures are required.
>
> (There appear to be spam hits every couple of hours).
>
> I'm on the road right now and will be arriving to Lima in a couple of days
> (i'll cross the border with Ecuador today). Thus I can't coach or even do
> much in a few days.
>
> Now, it would be good to find a general solution because as you can see
> here:
> http://cl.sugarlabs.org/wiki/index.php?title=Especial:CambiosRecientes&days=90&limit=500
> http://ar.sugarlabs.org/wiki/index.php?title=Especial:CambiosRecientes&days=90&limit=500
>
> - This is a general problem with "local labs" wikis. It does appear
> co.sugarlabs wiki is free of this problem so probably the badbehaviour
> extension was installed.

I did not even know we had ar, cl and co wiki instances.  I agree
general solutions are needed.

> A more general solution for getting rid of this problem, like copying real
> pages into a new instance or setting up a spam killer wiki bot, would be
> greatly appreciated.

In the few moments that the pe wiki was clean (I'm sure it is already
spamming up again) , I prepared a whitelist, see attached.  We need
Sebastian to land someplace stable to do a little reviewing and make
some calls as mentioned in the attached, but we have gotten useful
effort from our GCI participants that will place us on the road to a
more permanent solution.

My current thought is that the user databases of these wikis where
CAPTCHA has been defeated are so contaminated by spambot and malicious
users that the best approach is to save the whitelist pages and then
wipe the instance starting entirely from scratch seeded with the
whitelist pages.  Wiki pages effectively go away when deleted (i.e. no
longer visible in the useful indexes) , whereas wiki usernames can be
perma-blocked, but the entries remain in the data base (AFAICT).


> I would not hesitate to provide sysop access to the wiki for a student
> provided we had backups and he/she is properly identified and has proper
> privileges.

I think that Sugar Labs (and the local parties granted hosting) need
to acknowledge the problem as a first step to proposing a solution.

Steps that may be part of the solution include:

1)  Looking to how the Wikimedia Foundation addresses similar
problems.   The have a concept called "Steward".  Notably SJ Klein of
OLPC served as a Wikimedia Steward for some years.

http://meta.wikimedia.org/wiki/Stewards

I am not suggesting we need to actually implement that specific
title/priv in software, having "global b-crats" created at the
beginning of a wiki would probably be sufficient.  There are a number
people who step up to the call of the wiki and have histories that
qualify them for such a role.  I would mention FGrose, Bernie, Luke
off of the top of my head, I think there are a few more that could be
identified and immediately agreed upon.  Given that I came up the
OLPC/SL ranks via starting with wiki work I would probably include my
own name in that list.

Anyone who knows much about wiki work is that while elevated privs may
be considered by some an earned social status badge, they have no real
benefits other than giving you the power to do a lot of boring and
messy clean-up work.  I recall SJKlein making me an OLPC wiki sysop by
welcoming me to the "Mop and Bucket Brigade".  :-)

3) More clearly defining the responsibilities of the local instance
owners for developing their own community of countervandalism workers
(even if drawn from out-of-country Sugar Labs vols).  This is going to
run into the limited resources issue pretty quickly, but it is also a
pragmatic test of the value of a local instance.  If it is not
important enough to the local team to take responsibility for normal
wiki sysop tasks, then I would have to question how much the wiki is
actually used and whether Sugar Labs vols should reasonably be
expected to fill in that local maintenance role.  We do not have the
resources to invest in standing up and maintaining instances that are
not in active use just for the sake of having them.  We might be
better off incubating such starting efforts in a namespace on the main
wiki instance before graduating them.


2) Synchronizing the security extensions of our various wiki instances
to maintain a constant state of awareness of the changing threat
profile.  In the end of the day spam is more than jsut an annoyance,
it is a security issue in that it often promotes malware sites and can
lead to the host (Sugar Labs) being identified on external grey and
black lists as a site that hosts many malware links.  The better
security products out there for spam and web-filtering are
increasingly incorporating "reputation scoring" in their
methodologies.

Those are just a few thoughts I've had on the topic, I am very
interested in the input of others, especially FGrose, whose opinion on
things wiki I value above all others out of respect for the awesome
work he does.

Warmest Regards,

cjl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: somosazucar_whitelist
Type: application/octet-stream
Size: 3278 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/private/systems/attachments/20121128/82c12dc9/attachment.obj>