Während unserer Argentinienreise blieb MUY 479 immer irgendwie präsent. Doch erst zuhause konnte ich das Geheimnis schließlich lüften. Das Kennzeichen verriet eben jenes Fahrzeug. Die in den Fotos gut erkennbaren Unebenheiten deuten auf eine Fiberglaskarosserie hin. Tatsächlich verwendete das abgebildete Fahrzeug eine solche. Es handelte sich um das Justicialista Gran Sport Coupé – eine argentinische Eigenentwicklung unter dem Dach der IMAE. Das Fahrzeug hatte Frontantrieb, verschiedene Quellen sprechen von interessanten Motorisierungen der Prototypen: Da ist die Rede von einem luftgekühlten V8, der wohl von Tatra geliefert sein worden dürfte, recht häufig erwähnt wird der 40kW starke Boxer des Porsche 356 (ohne S). Und dann gab es noch einen Vierzylinder-Zweitakt U-Motor – eine Konstruktion, die vom Puch-Zweitakt-Doppelkolbenmotor abgeschaut war, aber als Eigenentwicklung ausgegeben wurde. Ich habe keine Ahnung, wie der Motor angeordnet war, vorstellen könnte ich mir eine Art Boxerkonstruktion mit einem quer liegendem Puch-Motor links und einem rechts. Die Realität der meisten der rund zweihunder produzierten Gran Sports dürfte mit DKW- oder Wartburg-Zwei- und Dreizylindern weit zaghafter ausgesehen haben.

Mit der Marke “Justicialista” war es nach Pérons Sturz schnell vorbei. Wen wundert’s. Dass anschließend Wartburgs als “Graciela Wartburg” in den gleichen Hallen montiert wurden, ist eine andere Geschichte. Wer diese Justicialista wohl gekauft hat?

Eines der ersten selbständigen Projekte war mit dem Rastrojero ein kleiner Pickup beziehungsweise geschlossener Geländewagen, der in Größe, Leistung, Nutzlast und Preis in der Kategorie der “Civilian Jeeps” (CJ, ab 1945) von Kaiser Willys und Land Rover (ab 1948) anzusiedeln war. Entwickelt wurde es seit Ende der 1940er, Produktionsbeginn war 1952. Der erste Rastrojero (“Landmann”, “Bauer” oder “Farmer” – vielleicht kann mir ein Leser, der argentinisches Spanisch spricht die passendste Bedeutung des Wortes heraussuchen) wurde von 1952 bis 1969 gebaut und erinnerte optisch eher an Dodge Power Wagon als an Jeep oder Land Rover. Motorseitig war er zunächst nur mit dem legendären seitengesteuerten 2,2l Benziner (Baureihe L134, “Go devil”) von Kaiser Willys erhältlich, der bereits im zweiten Weltkrieg Militärjeeps antrieb. Bereits 1954 löste der Borgward 1,8l-Diesel mit 42PS aus dem Hansa 1800 Diesel den rennenden Teufel ab. Es ist mit Sicherheit kein Zufall, dass das Datum der Umstellung mit der Errichtung des argentinischen Borgward-Werkes zusammenfiel.

Erst im Jahr 1969 wurde die erste Generation des Rastrojero von einem Nachfolger abgelöst, dessen Design an eine Mischung aus Peugeot 504 und Fiat 124 erinnerte und der auch mit einem Diesel von Indénor erhältlich war. Doch dazu später mehr. Die Fotos entstanden im November 2008 in San Rafael, Argentinien. Das Copyright für alle Aufnahmen liegt bei Mattias Schlenker. Sollte die Weiterverwendung gewünscht sein, bitte Mail an mich, ich gebe die Aufnahmen dann unter einer passenden Creative Commons Lizenz frei.

Dummerweise nicht verriegeln. Zum Abschließen und Öffnen stehen folgende Möglichkeiten zur Verfügung:

• Die Zentralverriegelung mit Schlüsselfernbedienung schließt alle Türen, wertet aber die Sensoren der Türen und Heckklappe aus und öffnet sofort wieder, wenn einer der Sensoren “geöffnet” anzeigt
• Der “Panic-Button” schließt alle Türen und wertet hierfür den Zustand der Heckklappe nicht aus
• Das Verriegeln/Entriegeln der Fahrertüre triggert die Zentralverriegelung
• Das Öffnen einer Türe bei aktivierter Zündung öffnet die Zentralverriegelung
• Das Öffnen der Heckklappe funktioniert mittels Magnetschalter

Der Magnetschalter der Heckklappe und die Zentralverriegelung liegen auf unterschiedlichen Sicherungen. Die Zentralverriegelung auf einer eigenen Sicherung, die Sicherung der Heckklappe ist nicht aus der Bedienungsanleitung ersichtlich.

Nun dachte unser 307, die geschlossene Heckklappe stünde offen und ließ sich nicht mehr verriegeln. Einen Teilerfolg brachte es, in das Auto einzusteigen, dieses mit Panic-Button zu verriegeln und dann die Sicherung der Zentralverriegelung abzuziehen (bei geschlossener Fahrertüre). Damit waren alle seitlichen Türen geschlossen, die Fahrertüre konnte von innen entriegelt und von außen per Zündschlüssel verriegelt werden. Leider ließ sich die Heckklappe noch öffnen. Abhilfe schuf hier nur die Radikalmethode: Batterie abklemmen, Motorhaube fallen lassen: Das Auto ist rundum zu.

So gelang es mir immerhin, das Auto “dicht zu machen”, ich musste heute nacht keine Angst haben, dass Punks einziehen. Und ein “Notfallbetrieb” ist möglich, solange man nur Fahrertüre und Heckklappe öffnen muss.

Heute früh laufe ich ans Auto, klemme die Batterie wieder an und merke, dass das zentrale Info-Display nicht mehr eine geöffnete Heckklappe anzeigt. Also Sicherung F14 wieder rein und siehe da: Alles ist so, wie es sein soll. Ich wüsste nun zu gern, ob das Problem in der Elektronik selbst lag — wir alle kennen Software, die irgendwann einen Betriebszustand erreicht, der vom Programmierer nicht vorgesehen war, — oder ob einfach Feuchtigkeit dem Sensor zu schaffen machte.

Befriedigend ist das Abklemmen der Batterie bei Zentralverriegelungsproblemen jedenfalls nicht. Eine eigene Sicherung für die Heckklappe, die im Fehlerfall abgezogen werden kann, würde hier den Komfort bis zur Behebung des Problems deutlich erleichtern.

Seit ein paar Jahren schon habe ich das Gefühl, dass sich die Wikipedia nicht wirklich voranbewegt. Die Zahl der Einträge steigt (aber das Wachstum flacht ab) und die jährlichen Spendenaufrufe bitten um größere Summen. Das ist quantitatives Wachstum. Ein qualitatives Wachstum kann ich nicht erkennen. Fefe verdeutlicht qualitative Probleme aus der Sicht des Contributors, ich sehe die Probleme bereits in der Sicht des Lesers: Während Felix ganz zurecht mit der sehr gewöhnungsbedürftigen Editierung von Einträgen argumentiert (ganz besonders bei Tabellen) und einen WYSIWYM-Editor fordert, frage ich, wo denn die Erleichterung für den User ist?

Die Wikipedia benötigt Semantik

Die Wikipedia nutzt — wie der Name schon sagt — das Konzept des Wikis zur Speicherung von Information. In Wikis sind Links unheimlich schnell erstellt und dadurch entsteht schnell ein dichtes Netz von Hyperlinks, an denen man sich entlanghangeln kann. Eine simple Syntax hilt dabei, Abschnitte, Überschriften und schnell erfassbar zu formatieren. Ich benutzte Wikis sehr gerne, um Projekte zu koordinieren. Denn da ist die gute Verlinkung zwischen Seiten die beste Möglichkeit, Dokumente immer bei der Hand zu haben oder neue hinzufügen zu können, ohne dass diese untergehen.

Ich kenne aber auch die Probleme des Wiki-Prinzips. Eines der größten ist die fehlende Semantik, bzw. die Einbindung semantischer Abschnitte. Ein Beispiel gefällig: Ich editiere vor allem an Artikeln zu Automobilthemen und Ländereinträgen. In beiden Fällen hat man mit Tabellen zu kämpfen, die erstens schrecklich zu formatieren sind und zweitens nie weder über die verschiedenen Wikipedias konsistent noch irgendwie vergleichbar ist. So hat Deutschland (Stand 18. November 2009) mit 81.882.342 Einwohnern Platz 15. der Bevölkerungsreichsten Staaten ein, während es in der englischsprachigen Wikipedia mit 82.060.000 Einwohnern noch Platz 14 hat.

Hin und wieder kommt ein Bot vorbei und vergleicht Daten oder fordert zu Korrekturen auf, aber das kann keine echte Semantik ersetzen. Denn diese erforderte die externe Einbindung tabellarisch vorgehaltener Daten. Das muss kein Widerspruch zum Wikipedia-Prinzip sein: Die Möglichkeit, eine semantische Tabelle an jeder Stelle einzubinden, solte in Fefes WYSIWYM-Vorschlag unterkommen können. Zudem bin ich sicher, dass sich mit etwa 20 vordefinierten Tabellentypen 95% der Anwendungsfälle und 99,9% der Aufrufe von Seiten, die Tabellen enthalten, abdecken können. Für den Longtail oder die Frage, nach allen Automobilen der Klasse unter vier Metern, die jemals mit Peugeots TUD-Motor ausgeliefert wurden, sind dann die objektrelationalen Profis zuständig…

Die Wikipedia benötigt Interaktion

Anja und ich haben vor gut einem Jahr für Johann Graf Lambsdorff die interaktive Weltkarte auf Basis von Google Maps für den CPI 2008 erstellt. In der Wikipedia findet sich eine derartige Fülle an Daten, dass es ein leichtes sein sollte, automatisch ähnliche Karten zu generieren. Das Kartenmaterial sollte bei OSM zu beschaffen sein, die resultierenden Möglichkeiten sind einfach zu schön: Wie wäre es mit Karten, bei denen man per Schieberegler die Entwicklung eines Indexes über die Jahre nachvollziehen kann oder die Korrelation verschiedener Indices (bspw. Korruption und BIP) verdeutlicht bekommt? Die traurige Wirklichkeit sind statische Karten, die von sehr engagierten Usern in Handarbeit als SVG oder PNG erzeugt werden können. Was für eine Verschwendung an menschlicher Rechenleistung!

Wir könnten das Thema viel weiter spinnen. Mit einer Ode an die Freude, deren Thema im Notensatz gleich als Midi abspielbar ist. Vielleicht nicht der beste Weg, mit Klassik umzugehen, aber einer, der Einblicke gewährt und Themen erkennen und zuordnen lässt. Um nichts anderes sollte es bei einer Enzyklopädie gehen.

Die Wikipedia benötigt Zwonull

Heutzutage werden Definitionen aus der Wikipedia gerne von Journalisten in den typischen 1000-Zeichen-Kurzerklärungen geglättet und verwurstet. Rankings aus der Wikipedia in Tabellen übernommen und das ganze mal korrekt mit Quellenangaben versehen als Kasten mit Hintergrundinformationen dargestellt, mal als Abschnitt in den Text verwurstet. Doch selbst beim klar abgetrennten Kasten ist nicht immer klar, wie dieser aus Sicht der Wikipedia-Lizensierung zu bewerten ist: Handelt es sich beim gesamten Artikel um ein abgeleitetes Werk oder ist der Kasten als eigenständiges Werk zu betrachten, da der Artikel auch ohne erklärendem Kasten seinen Charakter behält und der Kasten unverändert bei vielen Artikeln platziert werden kann?

Ausgerechnet die Encyclopaedia Britannica hat hierfür eine elegante Lösung gefunden: Widgets, die in jede beliebige Webseite eingebunden werden können und Inhalte aus der Enzyklopädie bereitstellen (bei der Britannica leider nicht toll umgesetzt). Bei dieser Form der Einbindung bleibt der fremde Inhalt klar als solcher erkennbar und wird nicht Teil des anderen Werkes. Technisch ließe sich ein besserer Nachbau der Britannica-Widgets recht einfach realisieren lassen, die nötige JavaScript-Programmierung ist eher trivial. Jedoch müsste sichergestellt werden, dass die als Widgets ausgelieferten Kurzzusammenfassungen in Sachen Qualität und Lesbarkeit über dem gewöhnlichen Niveau der Wikipedia liegen. Kurzum: Den einleitenden Abschnitt zu verwenden, wird in vielen Fällen funktionieren, aber nicht in allen.

Ein wichtiger Effekt wäre die Wahrnehmung, dass nicht mehr der Leser zur Wikipedia muss, sondern die Wikipedia zum Leser kommt. Durch die Einbindung externer Inhalte schüfe man jedoch auch eine gewisse Verantwortung des Einbindenden für die eingebundenen Inhalte. Und da es für eine Onlineredaktion, die einen Artikel mit Wikipedia-Hintergründen aufpeppen möchte, einfacher ist, die Zusammenfassung im Wikipedia-Widget sprachlich zu glätten, als in eigenen Worten komplett neu zu formulieren, dürften schnell beide Seiten profitieren.

Die Wikipedia benötigt Professionalisierung

Die Wikipedia wird gerne mit Open-Source-Projekten verglichen. Doch in der Struktur der Mitarbeit gibt es signifikante Unterschiede. Am Linux-Kernel kann jeder herumschrauben, der sich die Quellen gezogen hat, doch landen seine Patches nicht automatisch im Produktionskernel. In der Wikipedia war es bis vor kurzem so, dass anonyme Änderungen fast überall möglich waren. Mittlerweile ist das Problem etwas entschärft, doch befriedigend ist diese Lösung nicht. Kristian Köhntopp schlägt als Lösungsansatz ein besseres Mentorenmodell vor, das die Meritokratie-Vorstellungen einbezieht.

Mich wundert auch, dass sich Wikimedia Deutschland e.V. kaum in die inhaltliche Entwicklung der Wikipedia einmischt. Zwar sponsort der Verein löbliche Projekte zur Gewinnung älterer Autoren (sinnvoll, denn ein Ingenieur auf Altersteilzeit hat viel freie Zeit, sein erworbenes Wissen in die Wikipedia einzupflegen) oder zur Förderung der Medienkompetenz von Schülern, doch direkte Unterstützung kann ich kaum erkennen: Domain-/Internetkosten sowie Bücher/Fachzeitschriften, die an Autoren gehen, um Artikel inhaltlich zu überarbeiten, machen nicht einmal 5% der Ausgaben aus^[1].

Was spräche also dagegen, hauptberuflich ein oder zwei Editoren zu beschäftigen, die gemeinsam mit der Community Artikel überarbeiten, für die sich prinzipiell viele Nutzer interessieren, deren Qualität jedoch hinter den gewünschten Standards zurückbleibt? Warum nicht einen “Wikimedia Summer of Editing” analog zum “Google Summer of Code” ausrufen, bei dem Studenten oder Doktoranden während der vorlesungsfreien Zeit bestimmte Artikelbereiche nach inhaltlichen und sprachlichen Kriterien überarbeiten? Ich könnte mir gut Dreierteams aus zwei “Fachidioten” und einem Journalistik- oder Sprachwissenschaftsstudenten vorstellen. Profitieren würden alle:

• Zuallerst stiege die Qualität, die Lesbarkeit und die Übersichtlichkeit vieler Artikel

• Eine Überarbeitung durch (angehende) Wissenschaftler und die dadurch zwangsweise bessere Belegung mit Quellen würde die Zitierfähigkeit der Wikipedia verbessern

• Eine bessere Zitierfähigkeit würde wiederum mehr Wissenschaftler dazu bewegen, die Wikipedia nicht nur als Quelle (vor allem für Begriffsdefinitionen und periphäre Informationen) wahrzunehmen, sondern auch dazu motivieren, Artikel aus dem eigenen Fachgebiet zu verbessern

• Schließlich könnte die Bearbeitung von Wikipedia-Artikeln auch der Reputation der (angehenden) Wissenschaftler dienen: Ein gut strukturierter, recherchierter und belegter Wikipedia-Artikel mit 30.000 bis 50.000 Zeichen stellt einen ähnlichen Aufwand wie eine Seminararbeit dar, entsprechend sollte er anerkannt werden

Mir erschließt sich nicht ganz, ob und in welchem Umfang Wikimedia e.V. ein Sponsoring in diese Richtung betreiben möchte. Ein Schreibwettbewerb ist ein kleiner Anfang. Bounties für Überarbeitungen wären besser und ein groß angelegter “Wikimedia Summer of Editing” absolut wünschenswert. Ich möchte diesen Vorschlag nicht als Vorstoß in Richtung der Kommerzialisierung der Wikipedia verstanden wissen. Aber derzeit ist das Editieren der Wikipedia für fast alle Beitragenden eine Luxusbeschäftigung, die in der Freizeit stattfinden muss. Gerade angehende Akademiker haben zwischen Studium und Nebenjobs wenig Zeit, sich diesen Luxus leisten zu können. Deshalb setzt das Modell des “Summer of Code/Editing” an der richtigen Stelle an: Haltet Studenten von fachfremden Billigjobs fern, steigert ihre Motivation und tragt gleichzeitig dazu bei, die Inhalte der Wikipedia analog zum Funktionsumfang von OSS-Software effizient zu verbessern!

Die Wikipedia benötigt einen Fork

Viele der angesprochenen Punkte wären bereits für sich alleine kaum in der bisherigen Wikipedia durchzusetzen. Ein großes Problem ist, dass der Mensch ein Gewohnheitstier ist, der ungern mit alten “User Experiences” bricht. Von vielen derzeit aktiven Admins und Moderatoren wäre schon ob eines Wikipedien-übergreifenden semantischen Tabellenmodells Protest zu erwarten. Würde ein “Summer of Editing” von den vielen Alten Hasen, die an Myriaden von Artikeln Detailverbesserungen vornehmen, als Invasion der Bezahlschreiber wahrgenommen werden? Wie wären die Reaktionen auf eine stärkere Verquickung von Wikimedia e.V. und Wikipedia-Community beispielsweise bei der Auswahl von Themen und Autoren für einen “Summer of Editing”?

Ich glaube nicht, dass derart massive Änderungen in einem großen, gewachsenen Projekt wie der Wikipedia durchzuführen wären – die Analogie vom Schlachtschiff und dem Schnellboot greift ganz gut. Ein kleines Team, das mit einem Fork durchstartet hätte bessere Karten, etwas zu bewirken. Um verwaiste Inhalte sollte man sich keine allzu großen Sorgen machen. Bei Artikeln, die im Fork nur geringe Änderungen erfahren, reicht es, die “Original-Wikipedia” zu beobachten und Änderungen ggf. nach Kontrolle zu übernehmen. Artikel, die sich von der Original-Wikipedia emanzipiert haben und aktive Betreuung oder massive semantische Überarbeitung erfahren oder erfahren haben, werden aus diesem Abgleich ausgenommen.

Oft wird argumentiert, dass aus dem Forking eines Projektes eine ineffiziente Ausnutzung von Ressourcen folgt. Das ist nicht der Fall:

• Bei den meisten Projekten ist der Aufwand, neue Ideen in einem Fork umzusetzen geringer als diese im “Mutterprojekt” auszuprobieren

• Stellt sich ein Konzept als unbrauchbar heraus, ist es einfacher, den Fork sterben zu lassen, als bei Änderungen im Mutterprojekt einen aufwendigen Rückbau durchuführen

• Konnten neue Konzepte erfolgreich im Fork ausprobiert werden, spricht nichts gegen eine Aufnahme dieser Ideen ins Mutterprojekte — Open Source ist durchlässig

Erinnert sich hier noch jemand an EGCS? Die “Enhanced GNU Compiler Suite” war ein Fork des GNU-C-Compilers durch den Linux-Distributor RedHat, der die Maßgabe hatte, die starke Fokussierung auf C/C++ und die x86-Architektur aufzubrechen. Der ursprünglich von einem kleinen Team entwickelte Fork fand bald bei den Entwicklern so starken Zuspruch, dass die Verantwortlichen des GCC-Projektes zwei Jahre nach dem Fork beschlossen, die damalige 2.7-Serie des GCC einzustellen und EGCS 1.1 als GCC 2.95 weiterzuentwickeln.

Natürlich gelten für ein Projekt wie die Wikipedia, das aus Code und Content besteht, andere Regeln: schon die Zusammensetzung der Mitarbeiter ist deutlich breiter. Dennoch bin ich sicher, dass der Fork genügend frustrierte Interessenten anlocken wird, um mit ihm erfolgreich neue Konzepte auszuprobieren: Vom Programmierer, der die Semantik verbessern möchte, über den Webexperten, der Widgets mit guter Usability entwickelt, hin zum Wissenschaftler, dessen Anliegen es ist, Artikel zu “seinem” Themengebiet besser zu strukturieren, sehe ich viel zu befreiendes Potential. Loslösen sollten wir uns auch von dem Irrtum, dass nur eine reine Community-Wikipedia neutral ist: Lieber ein großes Medienhaus stellt einen Redakteur ab, der die oben angesprochenen “1000-Zeichen-Kurzzusammenfassungen” für Widgets glättet und macht dies transparent, als ein anderes verschwendet die Energie darauf um hinter einem Proxy versteckt “als IP” die Unternehmensgeschichte zu schönen.

^[1] Im Rechenschaftsbericht weist Wikimedia e.V. ca. 60.000 Euro Abschreibungen aus, etwas weniger als 20% der Bilanzsumme. Dabei scheint es sich größtenteils um Server zu handeln, die als Reverse Proxy oder lokaler Mirror die Server der Wikimedia Foundation in Florida entlasten.

Nachtrag, Links

• 20. November 2009: Streitgespräch zwischen Felix von Leiter und Pavel Richter im SZ-Blog “Schaltzentrale”

Ich halte wenig davon, ich habe auch für 800km keine Lust, 500kg Akkus mitzuschleifen. Und welche Ströme sind eigentlich beim “Tanken” erforderlich, wenn es mal schnell gehen soll?

Vielleicht bin ich verwöhnt: Normales Dieselöl hat die 80fache Energiedichte wie der Akku des Tesla. Selbst mit IBM Ziel ist es noch Faktor 10 und die ungelöste Tankfrage, wie ich in fünf Minuten 750kWh reinkriege (das entspricht 60 Liter Diesel a 12,5kWh). Ja, das sind 150kWh pro Minute oder 9MW Leistung beim Tanken…

Viel sinnvoller würde ich es daher finden, wenn Silizium als Energiespeicher zum Einsatz käme. Das kann entweder direkt in Wärme umgewandelt werden oder katalytisch dazu benutzt werden, Wasserstoff für eine Brennstoffzelle zu erzeugen. Akkus als Zwischenspeicher: nett, aber vielleicht eignen sich auch Kondensatoren? Und für die Stadt schweben mir eh Induktionsschleifen an Bushaltestellen und Ampeln vor. Zukunftsmusik? Nö, was bei Dell-Notebooks und Straßenbahnen funktioniert, sollte auch für Stadtautos klappen.

Nachtrag: PDF zu Silizium als Energieträger

• 3 Eier gekocht
• 200 g frische Champignons
• 1 Bund Petersilie
• 1 Bund Dill
• 2 Zwiebeln
• 1 rote Pfefferschote
• 200 g Emmentaler Käse
• 200 g Doppelrahm-Frischkäse
• 2 kleine Knoblauchzehen
• 6 getrocknete Tomaten
• etwa 20 schwarze trocken eingelegte Oliven ohne Stein
• Salz
• Pfeffer
• 1 TL ital. Kräutermischung
• 1½ bis 2 breite Baguettes (“Bauernbaguette”)

Alles klein würfeln, würzen und mit dem ausgehöhlten Innenleber der Baguettes gut vermischen. Das Stangenbrot in der länge halbieren. Vorsicht – nicht ganz auseinander schneiden – aushöhlen Brotkrumen in die obigen Zutaten mischen und Brot(hülle) mit der Käsemasse füllen und wieder schließen.

Wir hatten gestern ein Baguette und ein kleines Sauerteigbrot. Das Sauerteigbrot war geschmacklich interessanter, aber härter und damit schwieriger zu essen. Ich habe nicht das gesamte Innenleben beider Brote verarbeitet, sondern nur etwas mehr als die Hälfte. Bei Weichkäse und Emmentaler war ich etwa 25% großzügiger. Wenn keine Vegetarier zugegen sind, können statt der Champignons auch 250 bis 300g Geschnetzeltes verwendet werden.

Brot mit Rouladenbändchen oder Bratenschnur verschließen, in Alufolie einwickeln und bei 200°C 20 bis 30 Minuten backen. Anschließend an ca. sechs hungrige Mäuler verfüttern.

Für die Sperrung dürfen vollqualifizierte Domainnamen, Internetprotokoll-Adressen und Zieladressen von Telemedienangeboten verwendet werden. Die Sperrung erfolgt mindestens auf der Ebene der vollqualifizierten Domainnamen, deren Auflösung in die zugehörigen Internetprotokoll-Adressen unterbleibt.

Demnach sollen die Provider Listen nicht nur der Domainnamen, sondern tatsächlich komplette URLs, wohl auch mit GET-Parametern erhalten. Sehen wir uns die Alternativen an:

1. Sperrung auf IP-Ebene:

   Es gibt keine Möglichkeit, zuverlässig herauszufinden, ob hinter einer IP-Adresse nur eine Domain gehostet wird oder zu erkennen, wann eine Site auf einen Server umzieht oder von ihm wegzieht. Nicht einmal das Ausbleiben von HTTP-Verkehr auf eine bestimmte Domain könnte als Indiz gewertet werden, dass bestimmte Hosts einer Domain nicht auf dem Server liegen — schließlich muss eine Domain nicht zwangsläufig zum Hosten von Webseiten verwendet werden oder kann momentan einfach brach liegen. Selbst wenn man beim Aussprechen der Sperrverfügung für eine IP-Adresse sicher ist, dass hinter ihr nur illegale Inhalte gehostet werden, kann es sich um einen Shared Hosting Server handeln, der grade erst befüllt wird.

   Wie schnell es zum Overblocking kommen kann, hat die Youporn-Sperre durch Vodafone bewiesen, dort haben einige Provider auf IP-Ebene geblockt, ohne zu berücksichtigen, dass Youporn zu dieser Zeit sich Server mit anderen Inhalten teilte. Die Kollateralschäden dieser Form der Sperrung sind nicht zu überblicken.

2. Sperrung auf Ebene der vollständigen Zieladresse:

   Der einzig technisch praktikable Ansatz, dies zu realisieren ist die in Großbritannien gebräuchliche Cleanfeed-Methode. Hier werden “verdächtige” Hostnamen entweder per DNS- oder per Router-Manipulation auf einen transparenten Proxy umgeleitet. Dieser filtert angefragte HTTP-Requests und liefert nur bei bestimmten Mustern das “Stoppschild” zurück. Eine derartige Filterung wirkt auf den ersten Blick eleganter (weil weniger anfällig gegen Overblocking), hat jedoch den Beigeschmack, dass hier Privatunternehmen beauftragt wären, die Kommunikation ihrer Kunden zu überwachen. Nicht schön: Ein HTTP-Request kann persönliche Daten sichtbar in GET-Parametern, aber ebenso unsichtbar in Cookies oder POST-Requests transportieren. Ich habe wenig Vertrauen, dass ein Privatunternehmen wie die T-Com die anfallenden Daten vertraulich behandelt.

Die vermeintlich “technologieneutrale” Formulierung hält einige massive Problematiken aus grundrechtlicher Sicht bereit:

• Freie Wahl der Sperrmethodik:

  Den Providern werden keine Auflagen gemacht, Overblocking zu vermeiden. Ein Provider, der per Routingtabelle sperrt und täglich die IP-Adressen der auf der Sperrliste verzeichneten Domains ins Nirvana oder zum eigenen Stoppseitenserver routet, kann nicht für Overblocking verantwortlich gemacht werden, er erfüllt nur den Wortlaut des Gesetzes, auch wenn nur eine Domain auf einem Shared-Hosting-Server mit 50.000 anderen Domains nur eine kurzzeitig kinderpornografische Inhalte enthielt. Beschwerden sind zwar nachträglich übers Verwaltungsgericht möglich, doch möchte ich nicht wissen, wie lang ein Verfahren dauert, wenn plötzlich eine sehr große Anzahl versehentlich mitblockierter Seiteninhaber klagt.

• Analyse des kompletten (unverschlüsselten) Datenverkehrs des Kunden:

  Warum nicht einfach auf die erste Stufe von Cleanfeed verzichten und stattdessen den gesamten HTTP-Verkehr über einen transparenten Proxy schicken? Neben einer Vereinfachung der Sperrinfrastruktur hat dies für den Provider den Vorteil, dass häufig angeforderte Inhalte gecachet werden können. Dies ist keine Zukunftsvision: Wer via Vodafones Websessions surft, bekommt (je nach Wal des Access-Points, Stand Januar 2009) von diesem transparenten Proxy Grafiken in schlechterer Qualität ausgeliefert, um den Traffic gering zu halten. Jene Mechanismen, die zur Identifikation von angeforderten Grafiken dienen, können ohne Änderungen dazu benutzt werden, die Sperrverfügungen umzusetzen. Während es bislang möglich ist, durch die Wahl des Access Points einen mobilen Internetzugang ohne Proxy zu verwenden, wird dies nach Implementierung der Sperrtechnologien nicht mehr möglich sein und sämtlicher ein- und ausgehende HTTP-Verkehr wird von einem Privatunternehmen analysiert werden.

Analog zur Welt der Post bedeutet der gegenwärtige Gesetzentwurf in etwa: Wir machen Listen mit den Adressen von bösen Leuten, die kinderpornografische Inhalte per Versandhandel vertreiben und die Post muss dann alle Postkarten prüfen, ob diese an die bösen Leute gerichtet sind. Ist das der Fall, behaltet Ihr die Postkarte und liefert die Stopkarte zurück. Wie Ihr das macht ist uns egal: Ihr dürft alle Postkarten, die über Euer System laufen, komplett lesen, wenn das einfacher erscheint oder Ihr dürft (analog zur IP-Adresse) gerne die Postkarten an einen ganzen Postleitzahlbezirk einkassieren.

Wir diskutieren momentan hauptsächlich über die Sperrung per manipuliertem DNS-Server, weil diese einerseits am einfachsten umzusetzen ist (wo nicht bereits transparente Proxies existieren) und andererseits viele Befürworter des Gesetzes sagen, dass die Nameserverabfrage vor dem Kommunikationsaufbau liegt. Ich an dieser Stelle einmal an die Juristen ab: In der gegen Overblocking anfälligen Sperrung auf IP-Ebene und der Analyse sämtlicher HTTP-Anfragen sehe ich einen klaren Verstoß gegen Artikel 5 und 10 unserer Verfassung. Selbst nach Streichen dieser Passagen bliebe noch die DNS-Sperre, die zumindest das Potential hat, den Email-Verkehr massiv zu behindern und damit auch in den Schutzbereich von Artikel 10 eingreift.

Selbst wenn es gelänge, das Gesetz dennoch — ausschließlich mit DNS-basierten Sperren — umzusetzen, bleibt die Frage nach der Verhältnismäßigkeit: Aus Bundesmitteln wird derzeit die Einführung von DNSSEC gefördert, welche das Gesetz mittelfristig wirkungslos machen wird. Eine Verhältnismäßigkeit zwischen den wenigen Seiten, auf denen die Sperre in zwei oder drei Jahren noch nutzt, dem Aufwand für den Aufbau der Sperrinfrastruktur und den gebundenen Personalkapazitäten von BKA-Mitarbeiter, die statt zur Sperrlistenpflege mit besserer Schulung effizienter zur tatsächlichen Verfolgung von kinderpornografischen Angeboten eingesetzt werden sollten, ist nicht gegeben.

Auf das Mißbrauchspotential von Cleanfeed oder anderen Lösungen, die auf transparenten Proxies beruhen, gehe ich später ein…

DNS-basierte Internetsperren kinderpornografischer Inhalte galten bislang als der einzig praktikable Weg, ohne Verfassungsänderung schnell ein symbolträchtiges Sperrgesetz auf den Weg zu bringen: Befürworter des Gesetzes argumentieren, dass eine manipulierte Nameserver-Antwort noch in die Phase vor dem Kommunikationsaufbau fällt und deshalb keinen grundrechtsrelevanten Eingriff in die Kommunikation selbst darstellt.

Die Funktionsweise der im “Gesetz zur Bekämpfung der Kinderpornografie in Kommunikationsnetzen” geplanten Sperren ist am ehesten mit einer manipulierten Telefonauskunft zu vergleichen: Ruft ein Surfer eine Webseite auf, wird zunächst bei einem Nameserver die einem Hostnamen zugehörige IP-Adresse angefragt. Bei den hierzulande geplanten und in einigen skandinavischen Ländern umgesetzten Sperren liefert der – auf staatliches Geheiß – manipulierte Nameserver des Internetproviders einfach die IP-Adresse des “Stoppseitenservers”, der entweder beim BKA oder beim Provider stehen wird.

Bislang konzentriert sich die Debatte lediglich auf die Sperrung von Webseiten, fast jeder Diskussionsbeitrag und jedes Rechtsgutachten geht davon aus, dass der Anfrage an einen Nameserver zwangsläufig ein HTTP-Aufruf, also die Abfrage einer Webseite folgt.

Weiterlesen im Lawblog…

In jedem Fall sollte aber meines Erachtens in der Debatte, welche Maßnahmen zur Gewaltprävention ergriffen werden, die von den Bundesministern von der Leyen und Schäuble vorgeschlagene Sperrung von kinderpornografischen Seiten im Internet mit Blick auf Killerspiele neu diskutiert werden.

Ich weiss es nicht. Vielleicht, dass die Internetsperren auch für “Killerspielewebsites” und “Killerspieleportale” genutzt werden sollten? Oder dass Killerspieler leichter zu KiPo-Konsumenten werden? Dass KiPo-Konsumenten erst virtuell, dann real töten wollen?

Mir scheint eher, als wolle Thomas Strobl einfach bei beiden emotionsgeladenen Themen medial präsent sein. Das ist ihm gelungen, ich schreibe drüber.

Nachtrag: Auch Netzpolitik nimmt sich des Themas an und das Lawblog.

Nachtrag, 19. Juni: Thomas Strobl hat seine Forderungen bekräftigt und möchte nun offenbar die nächste Sau durchs Dorf treiben. Artikel bei Golem.

Worum geht es? Um die Wirkungslosigkeit von Internetsperren auf DNS-Ebene vor dem Hintergrund der Einführung von DNSSEC, einem Signaturverfahren für Nameservereinträge. Brisant: Das Bundesamt für Sicherheit in der Informationstechnologie unterstützt derzeit in einem Feldversuch die Einführung von DNSSEC . Hier wird also mit Bundesmitteln und damit Steuergeldern eine absolut begrüßenswerte Technologie eingeführt, welche aber gleichzeitig die Sinnlosigkeit des Sperransatzes im “Gesetz zur Bekämpfung der Kinderpornographie in Kommunikationsnetzen” entlarvt.

Ich argumentiere hauptsächlich auf technischer Ebene, die rechtlichen und gesellschaftspolitischen Argumente wurden von verschiedenen Seiten — auch in den von Familien- und Wirtschaftsministerium  eingeholten Gutachten — mehrfach vorgebracht.

• Mein Brief als PDF

Nachtrag, 11. Juni: Heise hat einen älteren, sehr lesenswerten Artikel zu DNSSEC und Sperren per Nameservermanipulation. Es dürfte mittelfristig darauf hinauslaufen, dass der Client einen Resolver bekommt und der manipulierte Nameserver des Providers gar nicht mehr angefragt wird.