Daniel Joyce <daniel.a.joyce at worldnet.att.net> said:
>But then, what if our attacker uses the 'rollback' button and rolls the 
>frontpage out of existance, to version 0 or 1? What if he finds a page 
>with a few revisions, and rolls them back out of existance?
>
So you don't do a rollback for normal users, you create a new version
based on an old one (would make sense to me in any case, that's what
you do in accounting for very good reasons: a correction transaction
instead of deleting an existing transaction).

Furthermore, a global rollback button (which would really remove versions)
would only be accessible to a limited set of admins.

>Or what if he simply bombs the page with LOTS of updates ( say a perl 
>script on his PC could do it ), and you find yourself having to try and 
>find revision #foo ( the last sane one ) out of 20,000... Could the 
>swiki even properly show 20k revisions so you could find the last sane 
>one to rollback to?
>
Not necessary. You could prevent such an attack with simple rate limiting
(once per 15 seconds, for example, on a swiki, would allow for quick
fixes by a normal user; with a bit of thought, you can come to reasonable
short/longterm, per page/global rates that you could all apply to separate
a normal busy user from a bot); furthermore, the global rollback button I
proposed would make undoing the attack in your scenario extremely simple:
"rollback all changes in this Swiki made from IP 1.2.3.4 between Fri,
26 July, 20:00 and Fri, 27 July, 07:00". 10 minutes of crunching later, all
the edits would have been zapped.

Another thing I thought about viz self/non-self discrimination,
artificial immune systems, etcetera, is maybe to build up word
frequency counts per page/swiki - a new edit that deviates by some
statistical measure from the known histogram(s) would raise an alert,
maybe queueing the edit for some sort of moderation. Kiddies replacing
every other word with Snork could easily be detected this way (for some
references and code, the 'ifile' package might be a good starting point
(http://www.ai.mit.edu/%7Ejrennie/ifile/). As it is based on statistics,
it should be doable to tune it on acceptable false positive/negative
rates. Again, this could be combined with rate-limiting - someone who
posts more than 3 'strangers' per hour, would be temporarily blocked
from accessing the Swiki (with a friendly message and the mail address
of the moderators, for example).

It's not as secure as PGP/GPG keys, but *way* more interesting (if only
to gain experience for similar collaboration environments inside Squeak)
and could be almost automatic (and friendlier to the occasional bypasser
who wants to fix a typo). I think having the computer doing the bulk work
assisted by a human operator (group) is really one of the best ways to
combine user-friendliness, flexibility and automation.

-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo