Skip to content

Front About Search
  You are not logged in Link icon Log in Link icon Join
You are here: Home » Members » Giles Turnbull » Old WtW Stories » Making the best of a wiki

Log in

Making the best of a wiki

by Giles Turnbull -- 2001/01/23

Wiki is a great idea - readable/writeable web pages that anyone can edit instantly in their browser window. But like many good ideas on the net, it only takes one idiot to vandalise a wiki and ruin it for everyone. WriteTheWeb asked one wiki webmaster for his thoughts on making the best of wiki, and keeping out the vandals.

The wiki concept, for those who are unfamiliar with it, was pioneered by Ward Cunningham at the original wiki and has been followed up by a variety of weird and wonderful wiki clones. But what do you do when idiots decide to vandalise your wiki?

Wikis are designed to be instantly editable by *anyone*. Sadly, that means anyone can decide to trash other people's work.

Built into wiki technology is the concept of different versions of a page over time, so in theory it should be easy to revert a page back to its previous non-vandalised state when the need arises. But that doesn't make it any fun.

Simon Michael runs, which had to put its "shields up" late last year after being vandalised. WriteTheWeb conducted an email interview with him.

WtW: Can you tell me briefly what is for, and why you decided to run a wiki?

SM: (previously called ZWikiWeb) began as a demo/test/discussion/collaboration site for my experimental wiki-on-zope software. Prior to that I ran a personal notes wiki on, based on AtisWiki. I had spent some time exploring Ward Cunningham's WikiWikiWeb at this point. Some reasons I started my own wiki:

  • speed - at that time, I had a slow link and editing on WikiWikiWeb was too slow for me to do it much.
  • to streamline the user interface to my own taste. One of the things I wanted to try was inlining the edit form on the page.
  • some privacy and topic freedom.

A more general answer to why wiki - I had been looking for ways to simplify and cut through the non-useful kinds of complexity that clutter up the web (and our lives). Wiki looked to me like a powerful step in the right direction.

I also felt the zope/wiki combination needed to be explored. I didn't know how to do this at first; thought about it, proposed and discussed it on the net for a while. Eventually I put everything else aside and worked on a preliminary hack that did some wiki-linking in zope. ZWiki grew from there, and attracted interest and contributions quite quickly.

WtW: The spirit of wiki management appears to be largely based on trust. Clearly you can trust the vast majority of your users. Is it fair to say wikis leave themselves open to attack and should take more responsibility for security?

Also, in November last year, your site was attacked by a so-called WikiVandal. What can you do to stop this kind of behaviour? (Bearing in mind your own comments.) Which ones do you, personally, favour?

SM: The original wiki concept is based on anonymously-writable pages. This works well for a reasonably respectful community. A vandal can obviously wreak havoc fairly easily; this may not be a problem if the community is pro-active about maintenance and tolerant of the occasional breakage.

A persistent vandal is more of a problem. The more well-known a wiki site becomes, the greater the chance of attracting visitors like this. On I can and do block certain IP addresses which have been persistent pests.

There are various other safeguards a wiki could implement to make large-scale vandalism more difficult without giving up the openness. For example, limiting the number of posts from a visitor in a given time period. If you're willing to require a login, then of course something like zope's access control allows you to implement any security policy you want.

WtW: On a more esoteric note, is it frustrating to have your efforts vandalised like this? How does it feel - does it make you angry, annoyed, or are you able to shrug your shoulders and carry on?

SM: All this is far outweighed by the positive participation of the many.

The problems so far have been minor and more in the nature of newbies testing the technology. It can be frustrating when you have to waste time on cleanup. I hope we can continue to convince each visitor that there's more value in building the site than f***ing it up!

Vandalising a wiki is pretty lame, after all. :)

WtW: Given your feelings about the issues, what do you see as the future development for wiki communities? Could they ever become more consumer-oriented? Can wikis be useful for things like building personal home pages, corporate web sites, weblogs, or other popular web publications?

SM: Certainly. Wikis can do everything but butter your toast :) One thing I think we will see more of is modeless WYSIWYG editing. But right now a "wiki" (speaking of zwiki, here) page can look like any other page. I see it as a move to a more powerful abstraction...

read-only web page -> edit-in-place web page -> editable, executable page

WtW: How do you mean?

SM: I touch on a couple of points there -

  • I think we will eventually see more in-place WYSIWYG editing of pages (ie no need to load a separate web page to edit). This will broaden the appeal for the masses.
  • Zwiki pages can look like any other web page - ie without special link names, without special header/footer etc - and may be used for things other than wiki-style pages.
  • The idea of "web page" is a powerful abstraction, allowing us to think of the diverse content of the internet simply as a collection of hypertext pages linking to each other. A page is a manageable unit of content with consistent functionality - forward, back, refresh, bookmark, submit form, etc.

So far, we have mostly seen a simpler case of this abstraction - "web pages which are usually read-only". "Read-write web pages" is a more powerful notion, which was part of the first www implementation and has resurfaced in wiki and elsewhere.

Another widespread enhancement is "executable web pages". Examples include cgi pages, pages containing java applets, javascript, ASP, PHP, DTML, etc.

Combine the last two and you get something still more powerful and general - "read-write, executable web pages". This is an incredibly powerful but also explosive mixture, due to the security issues associated with executing unknown code.

As far as I know the combination of zope's 2.2 security model with wiki is one of the first implementations where you could seriously think about providing this abstraction to users while maintaining some control of the security situation. (More details of these issues may be found on and