Seit mehr als fünf Jahren (September 2002) betreibe ich meinen Wiki-Server ohne Lesebeschränkungen. Jedermann kann weltweit alle Wikiseiten lesen. Diese Offenheit (Biblionetz:w01882) ist mir wichtig, denn ich bin der Meinung, dass wir bei eLearning immer noch am Anfang stehen und voneinander lernen können sollten. Learning Management Systeme, bei denen ich nicht über den Login-Screen hinaus komme, ermöglichen mir aber kein Lernen an anderen Beispielen.

Die Inhalte dieses Wikiservers sind aber meist nur für Personen interessant und relevant, die den Kontext ihrer Entstehungsgeschichte einordnen können. Wenn Schüler/innen den zweiten Weltkrieg bearbeiten, dann sind ihre Gedanken für sie selbst, die Lehrperson, ihre persönliche Umgebung und andere eLearning-Interessierte relevant, nicht aber für den Rest der Welt. Aus diesem Grund ist es nicht sinnvoll, dass die Seiten dieses Wikiservers von Suchmaschinen gefunden werden. Darum schliesse ich mit der Datei robots.txt von Anfang an alle Suchroboter aus. Die grossen Suchmaschinen wie z.B. Google halten sich an diesen Hinweis und verzichten darauf, Seiten dieses Wikiservers zu indexieren.

Nicht an diesen Hinweis halten sich hingegen Spambots, d.h. bösartige Suchroboter auf der Suche nach E-Mailadressen oder der Möglichkeit, Werbung auf einem Wiki zu deponieren. In den letzten Monaten musste ich eine Zunahme solcher Spambots feststellen, die teilweise mit der gesamten zur Verfügung stehenden Bandbreite die Inhalte dieses Wiki-Servers abgegrast haben.

Um keine Lesebeschränkungen für Besucherinnen und Besucher einführen zu müssen, musste ein anderer Schutz gefunden werden. Gestern hat nun Benedikt eine Spambot-Falle installiert, die folgendermassen funktioniert: Auf allen Wikiseiten ist ein für den Menschen unsichtbarer Link platziert. Dumme Spambots, die allen Links nachgehen, werden auch diesen Link abrufen. Dies löst jedoch eine sofortige Sperre ihrer IP-Adresse aus. Somit sollten Spambots vom Abgrasen des gesamten Wikis abgehalten werden, während normale Wikiuser nichts von dieser Massnahme bemerken sollten.

Bevor nun ein schlauer Schüler auf die Idee kommt, das Wiki seiner Schule durch den Abruf dieses verbotenen Links aus dem Schulnetz lahmzulegen und damit eine Wikistunde zu sabotieren, hier noch folgende Hinweise: Gesperrte IP-Adressen erhalten als Antwort eine Erklärungsseite mit Captcha (Biblionetz:w01616) zurück, auf der sie die Sperre durch Eingabe von nur menschenlesbaren Zahlen wieder aufheben können. Zudem kann ich einzelne IP-Adressen auch in eine Whitelist eintragen, so dass das Abrufen des verbotenen Links von dieser IP-Adresse aus wirkungslos bleibt.

Ein letzter Hinweis für Techies: Bitte die Spambotfalle nicht an meinem Wiki testen: Erstens erhalte ich jeweils ein Mail, wenn sich ein Spambot in der Falle verfängt und zweitens will ich eine unverfälschte Statistik, wie viele Spambots wir fangen konnten. Wer die Funktionsweise testen will, ist eingeladen, dies auf der Website der verwendeten Software zu tun: http://www.spider-trap.de/

Why do I blog this:

• Naja, einerseits damit die User dieses Wikis von diesem Feature wissen. Dieser Blog dient auch als Announcement-Board für das Gesamtwiki.
• Andererseits, weil diese Massnahme ein schönes Beispiel für soft security (Biblionetz:w01915), die zeigt, dass man mit dem notwendigen technischen Know-how nicht nur die Wahl zwischen sicher und brauchbar hat, sondern dass differenzierte Lösungen möglich sind.

Patrick Lambe verweist in einem Blog-Posting auf eine Präsentation von Benjamin Greenberg der non profit Organisation Physicians for Human Rights, der die mailflutsenkende Wirkung von Weblogs vorrechnet:

Eine ähnliche Rechnung gilt für die Aussage Wiki kann die E-Mailflut verringern (Biblionetz:a00731)

Diese Woche ist auf meinem Wiki-Server in einem Bereich eines Gymnasiums ein dummer Fehler beim Umbenennen von Seiten geschehen, der mich ca. 2-3h Arbeit und etwas Nerven gekostet hat. Ich möchte diesen Zwischenfall nicht unterschlagen, da ich nicht nur die problemlosen Seiten des Wikibetriebs aufzeigen will. Andererseits scheinen mir diese 2-3h Arbeit im Verhältnis zu den Aktivitäten und Userzahlen auf dem Wiki relativ wenig zu sein, so dass ich Wiki weiterhin als Erfolgsmodell bezeichnen würde.

Was ist passiert? Jemand hat vor einiger Zeit - entgegen meinen Empfehlungen - Wikiseiten mit Seitennamen erstellt, die kein WikiWord sind, nämlich Seiten mit den Namen A, B, C usw. Bisher wehrt sich mein Wikiserver nicht gegen solche Seitennamen (aber vielleicht muss ich hier eine Einschränkung einbauen).

Diese Woche nun hat jemand anders gesehen, dass da Seiten mit einem einzigen Buchstaben als Namen bestehen und hat diese Seiten alle umbenannt, so dass sie alle Wiki-Words als Namen tragen. Um bei solchen Umbenennungen tote Links zu verhindern, bietet TWiki an, alle internen Verweise auf die umzubenennende Seite anzupassen. Hier kommt nun ein Implementationsproblem von TWiki ins Spiel: Weil TWiki davon ausgeht, dass Seitennamen immer WikiWords sind und somit jedes Auftreten eines solchen Worts auch einen Verweis darstellt, sucht TWiki einfach alle Vorkommen des zu ändernden Seitennamens und bietet dem User an, diese Verweise umzubenennen. Konkret: TWiki hat bei der Umbenennung der Seite A nach LiteraturverzeichnisA in allen Wikiseiten des Bereichs nach dem Auftreten des freistehenden Buchstabens A gesucht.

TWiki ist gegen 2300 mal fündig geworden und hat den User gefragt, ob er diese 2300 Seiten mit dem Buchstaben A im Text auch anpassen möchte. Da diese Frage nicht gross und blinkend dargestellt wurde und die Auflistung der 2300 Seiten erst durch runterscrollen sichtbar geworden wären, hat der ahnungslose User der Frage zugestimmt und schwupps wurden in 2300 Seiten der freistehende Buchstabe A durch den Text LiteraturverzeichnisA ersetzt. Und um die Sache noch etwas komplexer zu machen, geschah dies nicht nur mit dem Buchstaben A, sondern mit vielen Buchstaben im Alphabet, da der User mehrere Seiten umbenannt hat.

Als ich vom Vorfall Kenntnis erhielt, waren schon einige Stunden vergangen, in denen andere ahnungslose User Seiten bearbeitet hatten. Unser Server macht zwar alle paar Stunden einen Snapshot aller Daten, hätte ich aber diesen Snapshot wieder eingespielt, so wäre ein Tag Arbeit des betroffenen Gymnasiums auf dem Wiki verloren gewesen (das entsprach ca. 75 Seitenänderungen).

Nun hat das Wiki zwar eine Versionsverwaltung, aber es ist doch etwas mühsam, an den betroffenen 2300 Seiten die Veränderungen einzeln wieder rückgängig zu machen. Die Seite LiteraturverzeichnisA wieder nach A zurück zu benennen ist auch keine Lösung, da TWiki dann erkennt, dass A kein WikiWord ist und besondere Massnahmen trifft, damit diese 2300 A's im Wiki als Link dargestellt werden.

Ich habe dann die besagten 2-3h benötigt, um mich in RCS und die Verwendung von RCS in TWiki einzuarbeiten und den Ursprungszustand wieder herzustellen, ohne dass irgendwelche Spuren im TWiki zurückgeblieben sein sollten. Da ich gleichzeitig noch an einer fiebrigen Grippe gelitten habe, geschah das alles im Halbdelirium und ohne Dokumentation, so dass ich heute nicht mehr genau sagen kann, welcher Kniff schlussendlich zum Ziel geführt hat.

Wie gesagt: Dieser Unfall bringt mich nicht davon ab, weiterhin die Offenheit von Wikis zu propagieren. Erstens ist dies der erste derartige Vorfall in fünf Jahren und zweitens hätte ich - auf meinen Perfektionismus verzichtend - mit dem Einspielen des gebackupten Snapshots innert einer Viertelstunde das Problem ebenfalls lösen können, wobei dann halt 75 Bearbeitungen verloren gegangen wären.

Für die Zukunft muss ich mir überlegen, wie ich meine TWikiuser dazu anhalten kann, nur WikiWords als Seitennamen zu verwenden. Nach der Automatisierung des Problems von vergessenen Passwörtern mit der TWiki-Version 4.12 ist das verwenden von Non-WikiWords das grösste, wenn nicht das einzige Supportproblem.

Gestern Mittwoch, den 12. Dezember 2007 war dieser Server zeitweise nicht mehr erreichbar. Auf meiner Seite betraf dies das Biblionetz, das Weblog hier, das gesamte Wiki (inkl. der Gymnasial-Wikis), aber auch meine private Mail.

Ich möchte betonen, dass es nicht an unserem Server lag, der friedlich (und etwas gelangweilt) vor sich hin schnurrte, sondern am Netzwerk dazwischen, wie auf diesem Netzwerkdiagramm zu sehen ist (der Unterbruch in der grünen Kurve):

klicken zum Vergrössern

Für den User kommts aufs selbe raus, für uns ist die Fehlerbehebung schwieriger: Wir sind zwar nicht schuld, können aber dafür auch wenig dagegen tun. ,

Seit etwa zehn Jahren Jahren plädiere ich für offene ICT-Systeme im Bildungsbereich, seien dies nun Computer, Netzwerke oder Plattformen (siehe z.B. meinen letzten Artikel "Offenheit aushalten lernen" (Biblionetz:t08000).

In persönlichen Gesprächen werde ich nach solchen Plädoyers des öftern mit einer Mischung aus Milde und Mitleid angelächelt: "Der Arme kennt eben die harte Realität des Lebens (noch) nicht, darum hat er so naive Idealvorstellungen. Spricht von Offenheit und Vertrauen; wenn der mal unsere Schülerinnen und Schüler / unsere Studierenden / unsere Mitarbeitenden erleben würde, dann wäre sein Vertrauen schnell aufgebraucht."

Verbal klingt das dann vielleicht etwa nach "Im von Dir genannten Umfeld mag das ja klappen, aber bei uns [wahlweise Schule, Schulstufe, Kanton, Land einsetzen] würde das nie funktionieren."

Bei diesem Totschlagargument ist dann auch meine bisherige, fünfjährige Erfahrung als Betreiber von mehreren Wikis auf verschiedenen Schulstufen in verschiedenen Kantonen und Ländern ohne Überzeugungskraft.

sagten Paul Watzlawick, John H. Weakland und Richard Fisch bereits 1974.

Auf der gleichen Biblionetz-Seite (Biblionetz:w00321) steht aber noch ein weiteres Zitat zum Thema Vertrauen von jemandem, den man nicht als Softie oder Naivling mit Weltverbesserungsabsichten bezeichnen würde. Der St. Galler Management-Professor Fredmund Malik sagt im Kapitel Die Grundsätze wirksamer Führung seines Buches Führen - Leisten - Leben auf Seite 149

Es sind zwar nicht meine Mitarbeiter, aber nach diesem Prinzip funktionieren die von mir betreuten Wikis:

Damit sollte klar sein, dass die Offenheit von Wikis und das den Nutzenden entgegen gebrachte Vertrauen nicht auf Naivität und Unkenntnis der Lage beruhen müssen. Offenheit und Vertrauen können auch sehr überlegt sein. Nachtrag: Marc Pilloud (12.12.07)
Hallo Beat, ich unterstütze deinen Ansatz zum Thema "offene" ICT Infrastruktur sehr. Möchte jedoch auf die problematische Definition von Vertrauen von Fredmund Malik aufmerksam machen. Das was Malik hier macht ist eine Umdefinition des Begriffes Vertrauen und der oben zitierte Watzlawick würde diese Definition als Doublebind bezeichnen. "Jederzeit erfahren, ab wann dein Vertrauen missbraucht wird", heisst nichts anderes als Überwachung und Überwachung und Vertrauen, lassen den Mitarbeiter (Student, Schüler, etc.) in einen emotionalen Doublebind gefangen. Jemand den ich überwache, dem Vertraue ich nicht. Was Malik mit seiner Aussage empfiehlt, ist die Mitarbeiter mit einer Doppelbotschaft "gefangen" zu halten.

Ja, bei Schul-Wikis ist es so, dass man jederzeit feststellen kann, wenn jemand etwas ändert und was er ändert. Man hat also eine hohe Überwachung im System eingebaut. Das mag der Grund sein, dass du das Zitat von Malik beigezogen hast. Bin mir da aber nicht sicher inwieweit man hier Aussagen aus dem einen Bereich (Management) auf ein anderen Bereich (Kollaborative E-Learning Plattform) übernehmen kann/soll. Da was im auf einer kollaborativen E-Learning Plattform durchaus Sinn machen kann noch lange nicht als Managementstil zu empfehlen ist.

Um etwas zur Diskussion beizutragen möchte ich die Frage stellen, ob Wiki gar kein Vertrauen braucht, da es nur wenig Motivation/Interesse gibt, etwas im Eigeninteressen destruktiv zu verändern (ich spreche jetzt explizit von Schul-Wikis und nicht von Wikis des Typs Wikipedia etc.). In Wiki sind keine Schulnoten und keine Prüfungen etc. zu finden. Der Aufwand/Ertrag Wiki für einen destruktiven Eigennutzen zu verwenden ist einfach zu gross. Vertrauen tritt ja erst dann auf wenn man Vertrauen auch missbrauchen kann, vorher braucht es gar kein Vertrauen.

Vielleicht lässt sich daraus eine Aussage machen, dass man nicht von "offenen" ICT Systemen sondern von "minimal closed" oder "minimal controlled" Systemen spricht … das heisst, dass man nicht Systeme schliessen und schützen muss, wo es nichts oder wenig zu beschützen gibt oder der Aufwand/Ertrag für einen Missbrauch einfach zu gross ist. Eventuell helfen folgende 4 Kategorien weiter:

1. minimal geschlossen / minimal überwacht
2. minimal geschlossen / maximal überwacht
3. maximal geschlossen / minimal überwacht
4. maximal geschlossen / maximal überwacht

Mit geschlossen meine ich hier Eingangskontrolle und Zugriffskontrolle. Mit überwacht meine ich Logging und Überwachung. Bin da auch offen für andere Begrifflichkeiten

Wenn wir diese vier Kategorien nehmen, dann gehört Wiki zum Punkt 2. Dazu würde zum Beispiel auch die Metro in London gehören, die zwar für alle zugänglich ist, jedoch weitgehend überwacht wird.

Laptops wo die Lehrer Installieren können, was ihren Bedürfnissen entspricht, würde dann in die Kategorie 1 gehören. Wobei mit dem Virenscanner "Minimal überwacht wird" und das Login der Lehrperson zu einem "Minimal geschlossen" wird.

Bin gespannt auf Reaktionen... ,