== '''Information required''' == (Josh) Since the previous software running this site was working fairly well, why was it replaced in the first place? Could we have a little information on what's going on? [CMcC] thought it was all public information. The previous incarnation was swamped by spiders. It was designed with locks and a lock breaking mechanism with a timeout of 10 minutes. The spidering was such that the timeouts timed out on valid edits, enabling multiple edits to be partially committed, thus causing corruption of data. It was considered a good idea to try to harden the server - to exclude rampant spiders. There was a mood to change, and change was necessary to prevent the inevitable repetition of the corruption. After about a fortnight, nothing was being done, so I decided I'd be willing to port the backend to my [Wub] front end, on the basis that I needed to write some hardening of the type needed anyway, and that Wub shouldn't suffer from the same network issues. In the absence of any practical alternatives or anyone to fix the problem in the time frame needed, that's what I chose to do. I get the benefit of testing Wub in a heavy duty application. The wiki gets to be hardened against attack and accident. When someone comes up with a better working implementation, I'm more than happy to hand it off to them. To that end, the wikit stuff is currently in subversion, and will be constituted as its own project. I don't plan to do much in terms of extending wikit beyond the functionality it had, but some people like [jdc] seem to have plans and willingness to put them into action. Feel free to contribute! ---- (Josh) Thanks Colin for your great efforts! Great attitude! Great spirit of initiative! You rolled out your sleeves, you spit in your hands and you moved forward. Way to go! Unfortunately, in all modesty, I must admit that I am not versed enough in these sort of problems but perhaps others are and they might contribute solutions. They might even be able to contribute an algorithm of some kind. I doubt it though since you are playing in a very very specialized area. But let's remain optimistic. My 2 Euros: wouldn't it be a good idea to only let in participants with passwords the same way it is done in the chat? This way vandals won't be able to vandalize the wiki and we could go back to the old Wikit? It seems to me (and to a lot of wiki webmasters) that times have changed: there are way too many cookoos out there so we cannot leave the gate open at night like we did in the old days. This wiki has always been very peaceful thanks to the fine and dedicated participants from all around the world therefore participants have never caused a single problem here; vandals are the ones who screwed up the wiki. They shouldn't have access to the wiki in the first place. We should close the gate. [stevel] Josh, this is a regular question and there's a regular answer ;) Consider the analogy of a shop window. Occasionally you get vandalism, but the solution isn't to board up the shop window, but rather to replace the glass on the rare occasions it is smashed, and perhaps install some security lighting. The wiki is Tcl's shop front and so we want to avoid boarding it up. One design goal of the wiki is to avoid barriers to people contributing (even if that means occasional vandalism). That's why we don't require passwords. (Josh) Great answer! Thanks Steve. IMHO in the absence of a technical solution, the implementation of a passwords system could be the solution however. Is it possible to examine how other wikis have fixed the very same problem and what solutions were implemented? I am sure they must also have been attacked by spiders. [stevel] No, the implementation of a password system is explicitly not what we want. This decision has been quite deliberate and well considered over a number of years. Passwords are a barrier to people contributing, and they don't stop spammers. The spidering issue has been dealt with via a honeypot (visit wiki page 5 if you want to see it in action). Also, forcing people to register before editing means we get a cookie on their browser, so we can detect persistent spammers should that become necessary. And once the revisions are back working again it will be easier to restore after vandalism. I'm not suggesting this system is perfect, but it is sufficient for now and preserves the open nature of his wiki. We could do a lot worse. [dkf]: There are a number of ways to implement anti-spam measures, and it has been a long-standing policy of the Tcler's Wiki to avoid techniques that discourage contribution. Instead, we've used a policy in the past of relying on the community to spot spamming and revert it rapidly. There are a few technical components to support that policy not yet online, but experience shows that spam isn't a big problem with a large community of vigilant [Recent Changes] watchers. However, by encouraging people to always contribute with a consistent ID (something which was not consistently done before) it makes it easier to trace activities of persistent and annoying scum and put in place measures to deal with them as necessary. (Josh) We certainly all trust you guys are doing the best for this wiki. Interesting! I am new to this cookie security approach. In the password system: a spammer (or a vandal) requires a password; he gets it, he spams and he keeps on spamming (or vandalizing) until his password is revoked. Then he gets a new password using another e-mail address and he starts the same behaviour over again. '''Question:''' Is that what you're suggesting? The problem seemingly with your cookie approach is that you end up blocking complete IP networks just to stop one individual from spamming when with the password system you only block one spammer at a time. But then again I could very well be mistaken. Since the cookie installed cannot be edited, you could therefore stop Joe Blow@142433 and he won't be able to post from his computer anymore but JamesK@142433 could be able to post however. Am I right? '''Question:''' Can you actually stop anyone from deleting a cookie in his computer and take a new one? Went to page 5. Hey you need good eyes to read the characters. I am sure more than one honest participant will be caught in the web! I also tried to make sense of what Colin wrote above: ''It was designed with locks and a lock breaking mechanism with a timeout of 10 minutes. The spidering was such that the timeouts timed out on valid edits, enabling multiple edits to be partially committed, thus causing corruption of data.'' It is very well written, well formulated but perhaps not clear enough for non-experts like me. '''Question:'''What does this all mean? Can you provide examples? No offense! I am not trying to be mean or difficult or nosy; it's just that when I don't understand something I ask questions. That's how I learn. :-) [DKF]: Two reasons why I'm not giving details: 1. There's no fixed rules anyway; we can tune our response as we see fit. (Let the Kangaroo Court decide their fate!) 2. I don't want to give spammers a recipe for working around our response. However, an example might be to review all changes they made while using a particular cookie, and to ban logins from their subnet (perhaps making it look like an unfortunate server bug) since it is fairly easy to find that info out and Tclers are mostly fairly dispersed (i.e. not too much risk of collateral damage being harmful). (Josh) Great answer! Hazy but reasonable. If you can develop strategies to counter them we are all for it. As you say, no need to get into details and give spammers and vandals recipes. I trust you can develop tools to counter them with the system you're putting in place and this is what counts. I also trust the Kangaroo court will judge in good conscience! Kangaroos have been known to be great judges! :-) They jump around like all good judges do! :-) But do they fall asleep in the middle of a court session like judges sometimes do? As for the mysterious paragraph: ''It was designed with locks and a lock breaking mechanism with a timeout of 10 minutes. The spidering was such that the timeouts timed out on valid edits, enabling multiple edits to be partially committed, thus causing corruption of data.'', any further enlightenments? All in all, thanks so much to the Teclers' New-Zealand and Australia connection (Oceania): Colin and Steve (from Digital Smarties) for your help in this difficult time. ---- [[[Category Wikit]|[Category Discussion]]]