| Random Page
It's not clear what the problem is you are solving [by having a more substantial VersionHistory
The main "problem" to be solved is the PerceptionOfVulnerability of a wiki. Many people will not seriously consider using a wiki because its content can be easily destroyed by a malicious visitor. (Indeed, the first time I saw a wiki (the TCL wiki) I considered it to be just a social experiment.) In practice, serious attacks on wikis are rare, although at least one has happened. The last-author-copy feature is very useful in preventing casual vandalism--at WikiWiki I fix a few pages each month which were wiped or carelessly destroyed. It is not very difficult to circumvent, however. KeptPages [ed: or AuthorPages] would be similar to the last-author-copy feature, but it would not be as easy to defeat. (anon)
Well, I'd address the PerceptionOfVulnerability as being beneath concern. Forget perceptions and deal with the real issues.
- I'd say that the perceptions of visitors are a "real issue". Many people visit wikis, but few contribute--even those who have created a home page rarely become active contributors.
I'd also like to know what the real attack on a wiki was? Wiki:WikiMindWipe? Wiki:AnonymizerDotCom? Some other wiki?
- The definite attack was on a specific-topic swiki. All of the pages were replaced with the attacker's content. In that case, no content was permanently lost (because the swiki had full versioning). After the attack, however, the site admin decided to remove all the old versions because he didn't want to keep the attack junk in the history.
- I don't know of other intentional systematic attacks. (In one case a search engine followed a wiki's "delete this page" links. Ouch.) Some other wikis without any effective versioning (such as the Dolphin wikis and the old "Pattern Stories" wiki) have had several useful pages destroyed and not restored. C2.com has lost several pages this way, although the Wiki:RecentChangesJunkies are pretty quick at fixing most vandalisms.
On all the attacks on c2, the attacks have come from regular users of the site. Regular users know the flaws, know the community, know how to circumvent the security.
- What attacks on C2? The Wiki:WikiMindWipe was an author attempting to remove his contributions from the wiki. Even his occasional removal of other people's closely related content was arguably permitted by community norms. The Wiki:AnonymizerDotCom problem was more of an annoying social nuisance (forging people's signatures) than an attack.
- The bigger problem is that new visitors don't know the history of wikis, and usually leave before they learn it. I'm a pretty good example. Months before visiting the C2 wiki I found the TCL wiki. I was interested in "discussion" kinds of software, so I took a quick look around. I dismissed it when I noticed the complete lack of security, even though I hadn't noticed any vandalism. Fortunately, I revisited that wiki later (searching for some specific content), and found the link to C2. (The rest, as they say, is history...)
- Most people don't live in highly-trusting communities (places where you could leave your car unlocked or your door open without expecting a problem), and many have personal experience of vandalism. Those who have seen online communities destroyed or diminished by such attacks (as I have) do not want to experience it again, and they often avoid communities whose destruction seems inevitable.
- The usual reply to concerns about wiki vulnerability seems to be like "we just don't worry about it". Some replies go further, and imply that users should simply accept that the community may be destroyed. This is not very reassuring. I tried to give a little more detailed reply in Wiki:WikiErase. (I found it quite amusing that my link from Wiki:WikiWikiWebFaq to that page was quickly erased, although later restored. ;-) I think it's important to treat people's concerns seriously, even though wikis aren't as fragile as they might seem.
- The wiki protection methods I've proposed (such as KeptPages) would be like seat belts or air bags in a car. People don't expect they will need their seat belts, but they want them in their new cars. The protection methods limit the possible bad outcomes. Of course, if I have a high-speed collision between my compact car and a large truck, I'm dead. Short of that, seat belts give me a pretty good chance of survival. Similarly, a distributed DenialOfService attack would wreck nearly any discussion site (as one temporarily wrecked KuroShin), but protection methods could allow lesser attacks to cause far less damage.
- Hopefully, most of the methods will never be used. The experiences of other "open" online communities are not encouraging, however. --CliffordAdams (who has considered the C2 wiki as "6 months from the end" for the last 15 months)
In the event of a moderately-serious attack, the usual "wiki" solution is to let the site administrator handle the problem. Only the administrator is likely to have full regular backups of the site content. (Offsite backups are done occasionally for all Meatball content.) Even with regular weekly or daily backups, the attacker can stir up quite a bit of trouble. I think the C2 wiki works well partially because most vandalisms are easily fixable by any user.
[For a really serious attack (like automated "troll" scripts), the only reasonable solutions are filters to block the offending addresses. I'd like to work on ways to delegate some of that responsibility, so that the admin of a larger wiki doesn't have to be available 24x7. The goal would be for the delegated admins to handle a serious attack without intervention by the site administrator.] --CliffordAdams
There are better ways [than KeptVersions] of mitigating damage from a determined perpetrator after the attack has commenced (calming people and healing social wounds is more effective) that don't have dramatic social side effects.
- Block the offending IP.
- Take the script offline until the storm blows over.
- Allow PeerReview, RecentChanges and diffs contain the damage as with the Wiki:WikiMindWipe.
- Build in a SurgeProtector. (the only really effective long-term solution)
- Semi-frequent site backups just in case all of these fail.