The current state is blank and locked, and from the history it looks like we've been terribly scribbled on.
It seems the last good home page was Version 31, accessible at http://swiki.squeakfoundation.org/squeak-e/1.version?id=31 . Until we figure out how to reconcile the openness of a Wiki with protection from this kind of vandalism, could someone who has the password at least restore the home page to its version 31 state, but leave it locked? Thanks.
On the figuring-out front, any ideas for a solution based on the capability security principles Squeak-E stands for? Perhaps using Tyler's style of capabilities as unguessable https URLs?
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
On Tue, 2003-04-15 at 03:00, Mark S. Miller wrote:
The current state is blank and locked, and from the history it looks like we've been terribly scribbled on.
Yawn. It's a handful of script babies (kiddies is too good a word for them) going round all Wiki's they can find. It's even beyond boring.
The password on the front page is 'cap'.
On the figuring-out front, any ideas for a solution based on the capability security principles Squeak-E stands for? Perhaps using Tyler's style of capabilities as unguessable https URLs?
Guns, ICBMS? ;-). Seriously: so far we've kept the kids off by setting a simple password on the front page. As a Swiki is a social environment, if we need to look for solutions I'd look for 'advogato-style' solutions instead of trying to combine 'everyone can enter and edit' with the 'absolutism' of capabilities.
For example, on a first post a random editor is signaled for approval; editors are those who have modified (and gotten approved) more than n pages, where n is a function of how big the Swiki is and how hard you want to make it to become an editor. Or three random editors are mailed, only one has to approve, to make it easier on the editors. After x posts (0 < x < n) the editors aren't bothered anymore, and n-x posts more you're an editor yourself. This way, you can slowly and gently lead newcomers into a Swiki community.
Apart from that, the idea is to keep ahead in the 'arms race' of undoing malicious changes faster than they can apply them. Wiki vandals are so dumb, they will not use tools. So my five-second edit I just made probably countered a one-hour 'hacking' spree of a 5-year old - so I won ;-).
Regards,
Cees
At 04:56 AM 4/15/2003 +0200, Cees de Groot wrote:
Hey Cees,
Off-topic, I'm a bit curious about what my PGP 8 installation is consistently telling me about your emails. Any ideas?
*** PGP SIGNATURE VERIFICATION *** *** Status: Bad Signature from Invalid Key *** Alert: Signature did not verify. Message has been altered. *** Alert: Please verify signer's key before trusting signature. *** Signer: Cees de Groot cg@cdegroot.com (0xE0989E8B) *** Signed: 4/14/2003 7:56:13 PM *** Verified: 4/14/2003 8:21:06 PM *** BEGIN PGP VERIFIED MESSAGE ***
[snip]
Apart from that, the idea is to keep ahead in the 'arms race' of undoing malicious changes faster than they can apply them. Wiki vandals are so dumb, they will not use tools. So my five-second edit I just made probably countered a one-hour 'hacking' spree of a 5-year old - so I won ;-).
Just an idea, but perhaps edits to pages can be tagged with a unique identifier tied to the HTTP session along with a simple rollback mechanism. If you find extensive (or not) Wiki graffiti (wikifiti?), just rollback to a previous version without those edits. Wiki or Swiki may already have something like this, for all I know, but it eliminates passwords and keeps things open. This is arguably feature creep, and is also subject to feature creep (keeping track of deltas, asynchronous rollback for legit edits made during a vandal attack, two-phase commits, transactions, oh my!), but I thought I'd throw it out there.
On Tue, 2003-04-15 at 05:28, Dan Moniz wrote:
Off-topic, I'm a bit curious about what my PGP 8 installation is consistently telling me about your emails. Any ideas?
Either a bug in Evolution/GnuPG, or an incompatibility with PGP 8? I am on 'bleeding edge' Debian, so wouldn't be surprised if something is wrong on my end. CC'ed this message to me so I can check it ;-)
Just an idea, but perhaps edits to pages can be tagged with a unique identifier tied to the HTTP session along with a simple rollback mechanism.
Even simpler, probably, is something I suggested earlier: a button to roll back - wiki-wide - all edits from a certain IP address.
Guns, ICBMS? ;-). Seriously: so far we've kept the kids off by setting a simple password on the front page. As a Swiki is a social environment, if we need to look for solutions I'd look for 'advogato-style' solutions instead of trying to combine 'everyone can enter and edit' with the 'absolutism' of capabilities.
Incidentally, you are talking about policy instead of implementation. This policy could use capabilities in its implementation.
For example, people with the edit-page capability can edit pages at will. People without it must edit in a different way and submit to an editor. Editors have an approve-edit capability.
Something like that, I dunno. The fact that it's distributed over the web makes it more complicated.
Lex
Lex,
I think there was some discussion at e-Lang about the associated problems a while ago. I don't remember the details but it might be worthwhile to check the mailing list archives.
Cheers, - Andreas
-----Original Message----- From: squeak-e-bounces@lists.squeakfoundation.org [mailto:squeak-e-bounces@lists.squeakfoundation.org] On Behalf Of Lex Spoon Sent: Friday, May 16, 2003 3:30 PM To: Squeak-E - a capability-secure Squeak Subject: Re: [Squeak-e] What happened to our Swiki?
Guns, ICBMS? ;-). Seriously: so far we've kept the kids off
by setting a
simple password on the front page. As a Swiki is a social
environment,
if we need to look for solutions I'd look for
'advogato-style' solutions
instead of trying to combine 'everyone can enter and edit' with the 'absolutism' of capabilities.
Incidentally, you are talking about policy instead of implementation. This policy could use capabilities in its implementation.
For example, people with the edit-page capability can edit pages at will. People without it must edit in a different way and submit to an editor. Editors have an approve-edit capability.
Something like that, I dunno. The fact that it's distributed over the web makes it more complicated.
Lex _______________________________________________ Squeak-e mailing list Squeak-e@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-e
squeak-e@lists.squeakfoundation.org
-
Andreas Raab -
Cees de Groot -
Dan Moniz -
Lex Spoon -
Mark S. Miller