Join us on IRC: #infoanarchy on irc.oftc.net — channel blog

Talk:Wiki Pros And Cons

From iA wiki

  • (discuss malicious users and sabotage):
    • name pseudo-forgung
    • subtle editing
    • malicious editing under the smokescreen of a lot of other editing (difficult to notice)
    • Malicious scripts could cause both subtle and wide-sweeping changes, even under multiple pseudonyms. Really intelligent distributed attacks could use multiple IPs.
    • There is time between malicious material being caught and this material being corrected.

Oh, I'm sure it's a trivial point, but a lot of browsers have hotkey-esque functions completely screwed over when a user is editing within a textbox. Things like ctrl-b to pull up bookmarks does something else while editing. This sortof influences a Wiki, since much of a user's time is spent in an edit box. -- sy

Ooh.. I've noticed that with a Wiki, I find subtle mistakes when I post up a wiki and read it again. I think the Wiki-editing form is just foreign enough to regular thought to have a person not perceive the text the same way as when reading a wiki not being edited. Notice how multiple edits are common? This could be solvable with a local-editor.. it would save bandwidth by allowing the editor to locally view a Wiki without constantly downloading/editing : uploading/proofreading : downloading/editing : uploading/rereading. A WYSIWYG Wiki-editor of some kind would also do the job. -- sy

There's some discussion going on about this at Wikipedia: http://meta.wikipedia.org/w/wiki.phtml?title=Dedicated_Wikipedia_editor&redirect=no

Also check out: C-Keen's Wiki which has some nice linkage about the different kinds of wikis. Perhaps just link to some of the originators of wiki, maybe they would maintain an updated page of info? -- sy

Alright.. one method of vandalism is to write subtly different edits and not have them noticed such that when a regular user comes by and makes a little change, their change overwrites the other one. Notice C-Keen's overwrite of garbage on the PHP page? Well, I was going through the recent changes and I never saw that user's original edit. This means that if PHP was a HUGE page, and C-Keen edited it without knowing of any malicious alteration, other users would just see his name on the recent changes list, and that page might not get double-checked if there is sufficient trust. ->

Let's say I was running along updating everything in sight.. well if I didn't know the original content of a page, and I was just linkifying things, and I didn't notice that subtle malicious edits had been previously made, well then the only way to tell that there has been any malicious intent would be to pray that some other reader drops by and notices the subtle differences. "many eyes" is no protection for a Wiki! ->

Furthermore, until some future reader dilligently checks the changelog of a page to see if subtle changes had indeed been made, much time could go by before a malicious edit could even be noticed. Most likely what would happen is that a future revision would make a correction or addition out-of-hand without noticing a change.. and the fullness of the original edit would have been lost because of the malicious change. ->

There is no way to easily undo the changes of a malicious user.. one is forced to manually edit and correct a page. There is also no resonable way to globally undo malicious changes.. nor to reasonably undo old malicious changes caught later. ->

There's a quick way to undo changes. Simply open the version before the malicious change, click "edit", then click "save". The malicious version is replaced. -- Stephen Gilbert
Doh, I suck. Thanks for pointing that out. <code> =) </code> -- sy

If there is a fear in the loss of fullness which subtle malicious changes create, the solution is to have layers of trust and user levels.. yes, the exact thing which Wiki's so openly protest against. Changing the way the recent changes page does things, to filter out "trusted" edits and show new user edits etc, would allow moderator-types (like myself) who idly read every changed page to linkify and check for spelling mistakes etc.. a recent changes change would allow us to see these new/untrusted users and specifically check up on them.. maybe we can flag a page as confirmed so that future moderation checks don't notice the checked page. Bleh, big topic. -- sy

I have to disagree on that. Many eyes are indeed a way of protecting the wiki. When I made that correction on the page I reviewed the changelog if there was any original page set up which was not the case. Then edited the page.

And the authors identities are on the record, just the last one is shown on the Recent Changes page. Nevertheless it is possible for everyone to see who did what on a wiki.

Therefore I don't see any reason to establish any authority enforcing Moderation/Censorship. I am a Wiki Anarchist in that way =) -- C-Keen

updated discussion. I really don't think you caught my argument that "many eyes" is no protection. There is no guarantee that anything inobvious will be caught.. a thorough user would be forced to check a page's individual changelog and refer to past revisions to check the current one..a number of pages could be edited and re-edited again and again and there is a strong likelyhood that nobody would remember a past revision well enough to note a changed or missing sentance or paragraph. Perhaps this is the price paid for openness. Perhaps it's really no loss at all.. afterall if nobody notes missing discussion from subtle changes, then it doesn't matter much anyway does it? -- sy

Just thought of something. Current "moderation" techniques involve a user going through the recent changes list and checking new links etc etc.. from old to new. Well, frequently while doing this out of curiosity, I have noticed that "new" edits appear below where I'm currently checking. This means that it's very easy for even a thorough user to miss new pages. I'm not sure about newly re-edited pages doing the same thing. Hmm.. just brainstorming I suppose. -- sy

I don't mean to pull a "grandfather" routine here, but you guys are quite new to wikis. The pros and cons of the system have been discussed, debated, analysed and re-examined many, many times. Are you sure you want to reinvent the wheel here, discussing such things in isolation from the wider wiki world? You would find it much more enlightening to read and contribute to Wiki (the original) or Meatball.

One of the dangers of a wiki is that it doesn't enforce focus; this must be provided by the wiki participants. Let's focus on infoAnarchy topics (copyright, file sharing, information searching, counter-exploitation), and leave the general wiki discusion to the wikis that are dedicated to such subjects. -- Stephen Gilbert

I agree and disagree. I agree that it's good to get acquainted with wikis before talking about them. I disagree that this wiki is not a good place to talk about collaborative writing -- in fact, that's one of its subject areas. The iA wiki can complement Meatball nicely, if only because it doesn't use the braindead CamelCase syntax ;-) --Erik

Fair enough. If we can avoid restating what has already be restated, I'll be happy. ;-) On a more positive note, people who are new to wikis can also come up with different angles of approach that wiki veterans may miss. Wikipedia was founded by wiki newcomers, and it was largely scoffed at by the wiki community in its early days. The idea of using a wiki as a tool for developing documents for distribution outside of the wiki is an under-explored idea. -- Stephen Gilbert, who also hates CamelCase

Bleh, edit conflict hit me. <code> =p </code> ->
On that line of thinking.. I for one would love to go around gathering resources which already speak on the topic. I certainly don't want to reinvent the wheel on this one. Even though I think I could probably do things very nicely in the end, it's basically a waste of time to do things from scratch. I also see the link between the / this wiki and collaboration in general and see the subject tying into a malicious user's discussion. While I see a great value in having one major section of this wikispace being a discussion on information and how to get it, I see another section speaking of disinformation.. malicious users, social engineering and related (even down to virii) and securing information. For me personally, there are a lot of entirely unresolved issues surrounding how a wiki can deal with covertly malicious users.. I'm really worried about that issue. Getting some more thorough wiki resources is on the top of my things to do. -- sy
Don't worry too much. In general, wikis are more secure than most other interactive sites, because they're so obvious to abuse, so people had to think of smart solutions. For example, we had a comment flooder for some time on the infoAnarchy forums, and the only way to deal with that was to delete comments individually (or run a MySQL query), because Scoop doesn't provide a nice interface to revert changes. A wiki, on the other hand, makes it trivial to restore an older revision and to revert all vandalism. The current wiki implementation we're using is flawed, the Wikipedia wiki is much more sophisticated. I'll use many of Wikipedia's advanced features like Watch lists and special user privileges in ScoopWiki. --Erik

UseMod isn't flawed; it's just purposely simple. It works really well for low to moderate traffic wikis... depending on what you want to accomplish.

In practice, Rack, wikis tend to work much better than you would think. All rely on a good dose of what some people call Soft Security (see http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity for details). Three active contributors can easily counter even subtle vandals on a young and small wiki like iA. -- Stephen Gilbert

I love Usemod's simplicity, but Wikipedia's advanced features like watch lists, its great i18n etc., make it even more suitable for smaller wikis IMHO. In fact, Wikipedia works better for smaller wikis than for large ones, as the software is not very efficient. I would have used WP if I had been aware of all its features when I set up this wiki.--Erik
In fact? Facts aren't so subjective.
What's subjective about the claim that the Wikipedia software is not very efficient? I've actually run tests on the thing.

Why do you think the advanced features of Wikipedia make it superior for small wikis (excluding i18n, that is obvious)? Just curious. -- Luke

Wikipedia has excellent usability, nice separation of discussion pages from content pages, fairly clean code, some nice little tweaks to page rendering (e.g. if part of a word is a link, such as GNUs, the entire word is rendered as a link, but only to the part that is highlighted), file uploading support, neat special functions (orphaned pages, most wanted etc.), watch lists (already useful for relatively small wikis), and lots of other stuff. It's also much easier to deal with SQL dumps than with Usemod's text files. The downside is that the database is not very well tuned and there are locking issues under load. --Erik

I'm really looking forward to seeing ScoopWiki. How much cash would it take to get you working full time on that? :) -- Stephen Gilbert

Not much, that's actually what I'll do (pretty much, I also have to work on some BerliOS stuff) as soon as the i18n of Scoop is finished. --Erik
  • Is history log flooding possible? That is, the pushing of lots of garbage for the purposes of making the wiki huge. Sure the pages can be overwritten by older copies, but don't the log entries of the garbage stay without administrative action to completely wipe those users' garbage?
Yes, that's possible, unless you use the KeptPages mechanism, which means that old revisions expire after a while. Another possibility is to limit the number of edits from a single IP address per minute. Personally, I think that it's reasonable, especially for wiki-weblog combinations, to restrict editing to logged in users, which allows a lot more control. Among wiki-advocates, however, this is generally considered a bad idea (makes discovery of the wiki concept harder). --Erik
Retrieved from "http://www.infoanarchy.org/en/Talk:Wiki_Pros_And_Cons"