I’ve been committing some code to the ressl project. I’ve found it worth to spend some time on that project that aims to make securing your communication more secure. But still people have some misconceptions about whether they can trust the new library and should make their code depend on libressl.

I have prepared a simple FAQ for them:

• Q: Should I base new code on the libressl API?
• A: No.

The reason is as simple as it gets. libressl was designed as a drop-in-replacement for openssl to protect the only asset openssl still has: an API that (even though it’s broken as hell) still is used widely. While they’re doing this, they try to do everything right that can be done right in a 201*-ish project.

Thing is, openssl is not actually there to provide you with secure software, but to implement the “nobody ever has been fired for using openssl”-aspect of your average “crypto”-library. It’s – well it’s there and it has some FIPS certification. But let’s face it: the code is terrible, the “maintainers” haven’t done any maintenance besides reselling their FIPS-asset, the API is terrible, the cipher-defaults are terrible, the interfaces into certificate checking are next to unusable, the core functionally works hard to cloak their badness from any modern bug detection heuristics, covering most of their bugs, and openssl’s maintainers ignore bug reports, because fixing them would break their certification, hurting their business of selling FIPS-consultancy.

Now, the OpenBSD guys were facing a tough challenge: write just another SSL library with a sane API that no one is going to use, or clean up the library that is de-facto standard and hard to rip out of each and every tool that tries to connect to the interwebs securely.

Most users of the openssl library come there, because they stumbled across transport security as an afterthought. Maybe because it’s been another tick on their compliance chart, or because they’ve seen the passwords flowing through their wireshark window – throw some crypto on it, they thought. What they need to realize is, that they actually need three separate libraries in the first place – which openssl conveniently layer-violates into one (and even adds dangerous cruft like kerberos):

a secure and sanely configured certificate exchange-, parser- and checker- library, a library of sane (and BY DEFAULT SECURE) crypto primitives that can apply ciphers on a data stream, a set of standard conforming heuristics that will (re-)negotiate cipher suites based on 1) and the availability of ciphers from 2) openssl fails in every single aspect of this. 99,999 percent of users nowadays do use openssl to secure their socket-based communication on servers or clients talking with each other via TCP. The whole BIO abstraction provided by openssl is wasted on them. The stack-like approach to look at “chains” of certificates falls short on modern setups with several expired and unexpired certs of the same CA in a single key store. You still can – as a MITM – trick most openssl setups into using null ciphers or weak algorithms. Checking CRLs still is a black art done right by no one. openssl still implements each and every memory allocation level bug ever displayed on “software security 101” in your favorite university.

Now I will – judging by the current progress – give ressl a year until they matured enough to acknowledge them having picked all low hanging fruit. Then OpenBSD can proudly (and rightfully) announce that software linked agains libressl on their (and other) platforms is much more secure than before. And after looking into the source code I also understand that fixing it while also inventing a saner API exceeds the OpenBSD team’s capacities. So I urge you to consider what exactly you need secured and what tools provide you exactly what.

If you’re up to implementing secure communication between your app and your server or between your appliances, first check if you really need all the TLS features – like the whole set of X.509 features that openssl gives you (and if so, check back which license of the available TLS implementations could possible also suite your needs) – or if you can just go with a public domain library like NaCl and put a little thought into what cryptographic primitives it gives you and where you need it.

Until then rest assured that securing your application is not just a case of linking in another unreviewed lib.

For over 15 years I’ve been – together with friends – running elektropost.org, a community mail server that provides free email accounts and mailing lists for friends, family, several NGOs and small companies – so they don’t have to turn to google mail or worse. We pride ourself in being good netizens, providing spam filtering, discarding our double bounces and so on.

Imagine our surprise when we suddenly were served bounces like

Remote host said: 554 5.7.1 Service unavailable; Client host [217.115.13.199] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?217.115.13.199

basically denouncing us as spammers. When investigating the issue, we were informed that

Causes of listing: System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop).

our system has sent an email to a secret mail address guaranteed to only receive spam emails. Any protest is futile, the website http://www.spamcop.net/w3m?action=blcheck&ip=217.115.13.199 told us,

Dispute Listing: If you are the administrator of this system and you are sure this listing is erroneous, you may request that we review the listing. Because everyone wants to dispute their listing, regardless of merit, we reserve the right to ignore meritless disputes.

basically saying: All the bad guys say that they are not the bad guys, so … sure, go on, drop us an note, whining about how bad the world is and we ignore it. Because you are a spammer. And we know because we said so.

At this point I would have just ignored them, after all the internet told me that they even put gmail on their RBL. But it turned out that several larger sites actually use the lists provided by spamcop and the amount of bounces started to hurt our community mail server.

I dug a little deeper and found that the spamcop project actually makes money selling it’s block list to other mailers in need of immediate updateso for US$ 1000: http://www.spamcop.net/fom-serve/cache/340.html and, worse they even sell email accounts for US$30 per year http://www.spamcop.net/ces/pricing.shtml which clearly indicates a conflict of interests. “Unfortunate mis-listing” of other free mail servers now appears as defamation of potential competition. So they better have their facts straight! But – have they? How to find that out, if they never want to present their proof of me being a spammer?

After failing to provide my email address as abuse-contact for our mail server at abuse.net – due to our mail server being on the black list (oh, the irony), I focussed on writing the most brown-nosing post on their feedback system. I explained, that we kept our system tidy for over a decade and would appreciate some assistance in resolving their claim. After a while I received an email, again explaining, that

This IP is listed because it is sending spam to our traps. Traps are addresses on our systems that have never existed and could never subscribe to be on any mailing list. Any mail to them is spam. We will not provide any information that identifies our traps or their locations.

but also providing a sample of the spam they received. And indeed

    Received: from elektropost.org ([217.115.13.199]) helo=elektropost.org
            by <removed>; Tue, 21 Jan 2014 17:xx:xx -0800
    Date: Wed, 22 Jan 2014 08:xx:xx +0700
    Message-ID: <2172___________________3767@gasz.nl>
    From: Online Casino <hqbwrgayueue@gasz.nl>
    To: <x>
    Subject: Ihr Ziel: Profit

this very much looks like spam, originating from our mail server. I also found some traces of that email in my rather sparse mail server logs and was flabbergasted for a moment, how this could have been relayed through the server without anyone authenticating. Fortunately I found a corresponding incoming spam mail to one of our users accounts, I found a mail forward set for this user to the address that obviously now serves as one of spamcops spam traps and from then on it all became clear. That user has set up a dedicated vacation account and forwarded all emails from that account to a satellite mail provider. The user also wrote several blog posts, pointing potential co-travelers to this address. The provider shut down the account a while ago and now decided that since nearly every email to this account looks spam-ish, it would make a perfect spam trap.

Now, even our overeager friends at spamcop have noticed that re-using a once legitimate address is a stupid idea, from http://www.spamcop.net/fom-serve/cache/402.html:

Traps must consist of email addresses which have never been used for legitimate email. They should not be "recycled" user accounts.

However, they never seem to verify, if their contributors actually follow those guidelines. In our case, a simple google search would have warned them.

I just wrapped up all this in an email to the hard-working “deputies” they employ over there at spamcop HQ and hope for a quick de-listing, and maybe – just maybe – for an apology.

In the end all left to conclude is: Do no put the burden of fighting spam on others. My users actually experienced bounced emails, I experienced two days of debugging and fixing other peoples amateurish setup, our project’s reputation was damaged. Spamcop, your secret spam traps are a stupid idea and they hurt the community, in our case possibly driving users away from a privacy-aware project to other freemailer providers that are large enough to have resources to deal with problems like you.

As a developer nowadays using a source code management system is non-optional. I’ve been a happy user of cvs for quite a while now, as it is complex enough for all my use cases and simple enough to allow fixing things with a text editor without breaking other people’s checkouts. I’ve had little reason to change this, as cvs was available everywhere and with ezjail – one of my more important projects – it was even essential providing means to checkout its latest development state on a vanilla FreeBSD installation, where cvs was the only scm system provided.

However, time moves on. The FreeBSD project chose to remove cvs from base system in its next major release 1 and OSX Developer Tools ship without cvs from OSX 10.8 onward. So it was time for me to move on, as well. The choice to migrate FreeBSD development to subversion 2 seemed not such a bad idea back in 2008, but for me svn has always been a world of pain. It adds complexity without providing any benefit and removed the option for simple repository manipulation when things went awry. In 2013 the only sane option – despite a creeping headache considering the license – is git. Its increased complexity pays off by having integrity checks, a well established user base, an almost fanatical devotion to the pope and in the end I can use it as I used cvs.

I set up gitolite 3 with a UMASK of 0022 4 (to save me trouble later with tools like cgit and gitdaemon) and created empty repositories for each project to migrate. After playing around with several tools, I found cvs2git 5 the best option, allowing me to import the cvs repositories onsite with this tiny script:

git clone git@example.org:${project}
mkdir -p dumps/
cvs2git --blobfile=dumps/${project}-git-blob.dat --dumpfile=dumps/${project}-git-dump.dat --username=cvs2git --fallback-encoding=utf8 ${CVSROOT}/${project}
# Use a text editor the fix committer’s emails, etc here in the dumps/${project}-git-dump.dat file
cd ${project}
cat ../dumps/${project}-git-blob.dat ../dumps/${project}-git-dump.dat | git fast-import
git checkout master
git gc --prune=now
git push origin master
cd ..

This scripts needs to be run as a user who can read CVSROOT and has commit rights to the gitolite repositories.

Being the polite hacker that I am, I wanted to avoid breaking other people's checkouts with my migration. I also need to provide backward compatibility to users of FreeBSD installations that still come with cvs only. This means that the pserver URIs need to remain intact. However, the tool I hoped would solve this problem – git-cvsserver 6 – comes with some surprising mapping of cvs modules into git branches. Which basically renders it unusable as a legacy support mechanism. This left me with little choice but keeping the old cvs repositories as write-only copies. I wrote a git commit hook that commits every change 7 to cvs using a dummy checkout in /home/cvs/${project}, after granting the git user commit rights to cvs. This works well, the only drawback is that it makes all commits appear to come from git in the cvs view. But I think this is an acceptable price.

In order to provide an additional update commit hook and not break gitolite’s builtin hook, I needed to add a so-called VREF 8 to the repo config, which looks like this in my conf/gitolite.conf:

repo ezjail opentracker minimunin jaildaemon
    RW+              = id_dsa
    R                = @all
    -   VREF/cvspush = @all

My git repos reside in /usr/local/git/, so I put my commit hook script to /usr/local/git/.gitolite/local/VREF/cvspush and fixed my /usr/local/git/.gitolite.rc to have an entry:

LOCAL_CODE => "$ENV{HOME}/.gitolite/local",

The hook itself is here (don’t forget to set +x permissions. Also if you checkout your cvs repositories somewhere other than /home/cvs, you need to change this, as well):

And finally all my project description pages were updated to reflect the new way to checkout the source code, as was the web interface 9. All thats left now is to provide read only svn access to the projects, for all FreeBSD users running 10.

Due to changes in how the FreeBSD port system handles the install target, certain ports fail to install with the error "pkg_create: make_dist: tar command failed with code 256" in Jails installed with the current version of ezjail. ezjail from version 3.4 fixes this. Until then you should execute the command mkdir -p /var/ports/packages as a workaround in all jails you want to install ports in.

ezjail 3.3 is out. Besides several bug fixes, it allows to install ezjails in alternative zpool, copes with auto-configure interface syntax for IP addresses better and properly supports the new distribution server layout. Refer to the Version history for details. On a side note, the project home page was brushed and polished.

ezjail 3.2.3 is out. The 3.2.2 introduced an inconvenient bug that prevented ezjail-admin update to find /usr/src.

ezjail 3.2.2 is out. This release contains minor fixes in zfs code.

Seit Version 10.7 kommt Mac OSX mit der Möglichkeit daher, WDE – also "whole disc encryption" – für seine Systemplatte anzuschalten. Mit ein wenig Gefrickel kann man auch externe Platten verschlüsseln lassen. In diesem Text soll es aber darum gehen, wie man sein mobiles Gerät möglichst flughafenkontrollfest schützen kann. Apple nennt seine WDE "FileVault 2".

In fast allen bekannten WDE-Szenarien hat man ein Paßwort für seine Festplatte, das nicht das selbe ist, wie das Benutzerpaßwort. Letzteres gibt man nämlich gefühlte tausend Mal am Tag mitten im Desktop und eventuell einmal zu leichtfertig und zu oft ein und legt im Speicher seines – oder im schlimmsten Fall eines anderen – Computers diverse Kopien dieses Paßworts an. Das WDE-Paßwort hingegen benutzt man nur in sehr kontrollierten und nicht so leicht durch Software zu emulierenden Umgebungen: direkt beim Booten und nach dem Aufwachen. Die Macher von FileVault 2 unter OSX haben diese Trennung im Standardfall nicht so vorgesehen – das Festplattenpaßwort wird einmal generiert und mit dem (Haupt-)Benutzerpaßwort verschlüsselt. Im Normalfall muß man nur beim Booten dieses Paßwort eingeben und ist danach direkt eingeloggt. Apple hat aber in FileVault 2 eingebaut, bestimmten Benutzern das Entschlüsseln der Platte zu erlauben, anderen nicht. Dies machen wir uns zunutze, indem wir einen extra-Benutzer anlegen, der einzig für WDE zuständig ist und allen anderen Benutzern das Entschlüsseln versagen.

Am Einfachsten ist dies, wenn die WDE noch nicht angeschaltet ist. Man legt sich einen neuen Benutzer "WDE" oder "crypto" an (dieser braucht keine Admin-Rechte), loggt sich unter diesem Benutzerkonto ein und aktiviert in den Systemeinstellungen => "Sicherheit und Privatsphäre" => FileVault die FileVault-Verschlüsselung für die Systemplatte (hier braucht man kurz Benutzername und Paßwort des Admin-Benutzers). Dabei achtet man darauf, daß einzig der WDE-Benutzer in der Zugriffsliste für FileVault aktiv ist. Den Recovery-Key sollte man sich notieren und nicht mit auf Reisen nehmen. Dabei versteht sich von selbst, daß man den Service von Apple nicht wahrnehmen möchte, diesen Key bei ihnen zu verwahren. Man kann sich jetzt auch gleich wieder ausloggen, die Festplatte wird im Hintergrund komplett weiterverschlüsselt. Wenn es nur einen Benutzer gibt, der entschlüsseln darf, wird man beim Booten genauso nach dessen Paßwort gefragt und auch gleich unter diesem Benutzerkonto eingeloggt. (Hinweis für die Paßwortwahl: Hat man eine deutsche Tastaturbelegung, ist diese zumindest unter 10.7 im WDE-Login-Bildschirm noch nicht aktiviert. Zuweilen muß man seine Umlaute erst suchen.) Nun kann man sich gleich wieder ausloggen, um sich danach mit seinem Standardbenutzer anzumelden.

War FileVault 2 bereits aktiviert und dem Standardnutzer das Entschlüsseln erlaubt, kann man diesem auch nachträglich die Rechte zum Entschlüsseln entziehen. Dazu legt man wie oben einen neuen WDE-Benutzer an, gibt diesem im FileVault-Dialog die Entschlüsselungsrechte und verpaßt dem Standardbenutzer ein leeres Passwort. Das geht im Systemeinstellungs-Dialog für Benutzerkonten nicht, dazu muß man das Terminal bemühen. Dem Kommando "passwd" gibt man sein altes Paßwort mit und drückt danach zweimal Return. (UPDATE: in OSX 10.8 erlaubt passwd nicht mehr, ein leeres Passwort einzustellen. Nun braucht man das Kommando sudo dscl . -passwd /users/USERNAME "". UPDATE 2: Seit 10.14 kann man auch mit dem dscl nicht mehr leere Passwörter vergeben. Aber mit dem Kommando sudo fdesetup remove -user username kann man manuell Usern das Recht zum Platte entschlüsseln wegnehmen.) Da nun FileVault für diesen Standardbenutzer kein Paßwort zum Verschlüsseln des Festplattenpaßworts mehr hat, werden ihm die Rechte zum Entschlüsseln der Platte entzogen. Dies kann man im FileVault-Dialog der Systemeinstellungen überprüfen, ein kleines gelbes Dreieck sollte nun warnen, daß nicht alle Benutzer die Platte entschlüsseln dürfen. Wenn man dies überprüft hat, kann man sein altes Standardbenutzer-Paßwort wieder setzen. Dieser Benutzer ist nun ent-FileVault-et, man sollte dies mit eventuellen anderen Benutzerkonten wiederholen.

Dem aufmerksamen Beobachter wird aufgefallen sein, daß nach dem Zu- und wieder Aufklappen keine Eingabe des WDE-Benutzer-paßworts notwendig ist. Dies bedeutet, daß der Festplattenschlüssel noch ungesichert im Speicher liegen muß. Ist der Computer mit Thunderbolt ausgestattet, oder hat einen FireWire-Port in einem ungesicherten Modus (ab 10.6 ist der FireWire-Bus beim Schlafen standardmäßig aus), kann der Schlüssel (beispielsweise bei einer Kontrolle am Flughafen) über den direkt am RAM anliegenden Thunderbold/FW-Bus ausgelesen werden. Somit ist die Verschlüsselung angreifbar. Um dem Computer beizubringen, beim Zuklappen den beim Booten eingegebenen Festplattenschlüssel aus dem Speicher zu löschen, bedarf es nur dieses Kommandos: sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25

Nun dauert das Aufklappen bei meinem MacBook Air statt 5 rund 25 Sekunden. Ich habe aber ein deutlich besseres Gefühl dabei, mein ausgeschaltetes Gerät jemand anderem in die Hand zu geben.

Ich schreibe ja schon seit einer geraumen Weile Software. Vieles von dem, was ich in meinen Anfängertagen schrieb, ist zum Glück vom gnädigen Gott der verrottenden Bits aus der Digitale gewaschen worden. Floppies und Backupschludrian waren hier die Auslesewerkzeuge. Ein Segen, den die Kids von heute übrigens nicht mehr erfahren. Vieles, was gewiß nicht einmal das Licht der Öffentlichkeit erblicken hätte sollen, findet ja inzwischen Produktiveinsatz. Damals, in meiner "guten alten Zeit" hätte der Verlust des Quellcodes aber nicht den Schaden bedeutet, den er heute so anrichtet. In der Szene, in der ich programmierte, lasen wir die Programme ja eh im Disassembly – eigene und die anderer Leute. Es kam dabei vor, daß ich mich über einige besonders umständliche Konstrukte wunderte, die ich in so analysierter Software vorfand, das Konzept von höheren Programmiersprachen und Compilern kam für mich überraschend. Programmierer fanden aber auch händisch Mittel und Wege, das Lesen des Codes mit dem Disassembler trickreich zu erschweren. Es war wichtig, sich auf Parties zusammenzufinden, mit den für Demos programmierten Effekten zu beeindrucken, sich beim Kaltgetränk über die Kniffe und Erfahrungen auzutauschen – und natürlich zu prahlen.

Seitdem hat sich einiges geändert. Die meiste Software, mit der ich lesend und schreibend zu tun habe, ist inzwischen selbstverständlich im Quellcode verfügbar. An bestimmter Software darf man überhaupt nicht mehr entwickeln, ohne die Quellen ebenfalls zu veröffentlichen. Zu manchem Projekt ist heutzutage Lizenzslalom ein signifikanter Anteil am Zeitbudget geworden. Ich finde das nicht gut. Kids sollten lieber ihre Skills im Programmieren verbessern, statt zu Möchtegern-Lizenz-Anwälten zu verkommen. Einige Entwicklungen sind auch auf der Festplatte besser aufgehoben als auf github oder sourceforge.

An die Benutzung meiner Open-Source-Software stelle ich eigentlich nur zwei Bedingungen: Veröffentliche die nicht unter deinem Namen, und wenn du brauchbar findest, was ich schrieb, dann triff dich mit mir zum Schwank auf ein Bierchen. In der Vergangenheit ist dies schon 1987 (laut eines unbestätigten WP-Gerüchts angeblich von einem gewissen John Bristor) als Beerware-Lizenz kodifiziert worden und wird von Poul-Henning Kamp als einem der bekanntesten Vertreter der Autorenzunft bemüht. In der Vergangenheit hat mir diese Lizenz schon einige feucht-fröhliche und vor allem gesprächsreiche Abende beschert.

Während ich mich wahrlich nicht beschweren möchte, Pakete mit Bier in meinem Postfach vorzufinden – zuletzt hat eine Shirtdruckerei die Lizenz "eingelöst", für Nickis mit dem von mir entworfenen und unter der Beerware veröffentlichten Logo des Alternativlos-Podcasts bekam ich drei Fässer Bier zugesendet – sollte der eigentliche Zweck nicht aus den Augen verloren werden. Wer meine Software gebrauchen kann, treibt sich wahrscheinlich auch in der selben Nische herum, wie ich. Sich da auf ein Bier zusammenzusetzen, erfüllt dabei mehrere Zwecke: Ad 1: ich habe den direkten Feedback zu meinen "Kunden". Ad 2: Ich kann einem selbstgesteckten Bildungsauftrag gerecht werden, aus erster Hand von Fehlern und Irrwegen erzählen, die nicht den Weg digitaler Aufzeichnungen finden sollten. Ad 3: Zwei offensichtlich computeraffine werden zu sozialer Interaktion angehalten. Ad 4: Es fließt Bier. In der Lizenz ist nämlich nicht festgehalten, wer das Bier bezahlen soll. Ich möchte mich nun auch nicht von dankbaren Mithackern aushalten lassen. Und so floß dann bisher auch traditionell das Gros des mir eingeschickten oder auf die Bühne transportierten Biers direkt als Freibier zurück in die Community.

In diesem Sinne: Prost.

Unsere Generation hat es ja wirklich gut. Es bleibt noch abzuwarten, wie die Lebenserwartung unserer Nachfahren in Anbetracht des Wandels der Ernährungsgewohnheiten sich weiterentwickelt, ob die Allgemeinbildung in die vergeßliche Cloud outgesourced wird, mit was unsere Enkel bezahlen werden, wenn sich das mit dem Geld als Irrweg herausgestellt hat, ob die religiösen Hetzer des Finanzextremismus, des Lebensanschauungshomogenismus und der bürgerlichen Zwangstransparenzmachung es schaffen, die Kohorten aufeinander loszuhetzen und natürlich, wie lange wir noch auf genügend fermentierte Dinokäkel zurückgreifen können, um unsere privilegierten Gesäße auf transkontinentale Entdeckungsreisen jetten zu lassen.

Und just dies habe ich mir vorgenommen, bevor das Benutzen des Luftraums nur noch wenigen Benzinhortern möglich sein wird: Eine empirische Untersuchung, ob die Erde tatsächlich rund ist. Dazu werde ich darauf achten, mich auch wirklich nur ostwärts zu bewegen und dabei Zwischenstops an den Orten der Welt machen, an denen ich strategisch gute Freunde stationiert habe. Natürlich ist die gesamte Reise komplett uneigennützig! Als ausgewiesener Verehrer und Förderer von Krtek ist es meine Aufgabe, seine geopolitische Bildung voranzutreiben und in Bildern zu dokumentieren. Dazu nehme ich die Strapazen der Reise tapfer in Kauf.

Der erste Reisebericht über die überraschend kühle erste Station meiner Reise folgt.

Zwischenfrage: Ede in Singsing bekommt ja seine Briefe immer erst, nachdem Karl-Heinz Redlich einen kurzen Blick dreingeworfen hat, Bedenkliches geschwaerzt und Kassiber komplett kassiert hat. Wie heisst die Taetigkeit, die Kalle dort ausuebt?

Nun stelle man sich mal vor, man saesse gar nicht ein, aber trotzdem gaebe es da einen Kalle, den man fuer jedes bisschen Text, das man lesen oder schreiben wollte, vorher fragen muesste. Der wuerde dann in einem dicken Katalog waelzen, ob das seine Ordnung haette. Und wenn er keine Bedenken haette, duerfte man die Information konsumieren oder niederlegen. Richtig: Auch das ist Zensur.

In letzter Zeit hoeren wir, auch von eigentlich gebildeten Menschen, dass die Web-Sperren keine Zensur seien. So argumentierte Heinrich Wefing in der aktuellen Zeit, dass das "Eine Zensur findet nicht statt" aus dem Grundgesetz ja im Konsens als "eine Vorzensur findet nicht statt" ausgelegt werden muesse. Somit sei das Ausfiltern einmal als unrecht erkannten Materials keine Zensur mehr.

Meines Erachtens nach war dieser Konsens jedoch eine blosse Verneigung vor der Realitaet, dass es bis dato technisch schlicht unmoeglich gewesen ist, auf der Konsumentenseite mit der Zensur anzusetzen. Die Moeglichkeit, Druckwerke in grosser Zahl zu verfielfaeltigen, war einigen grossen Spielern vorbehalten, die im Zweifel zusammengerufen und kontrolliert werden konnten. Man konnte frei publizieren und konnte als Verantwortlicher fuer Druckerzeugnisse, die strafrechtliche Konsequenzen nach sich zogen, belangt werden.

Neu ist, dass nun nicht mehr die Publikation, sondern die Rezeption jedes Werks im Internet ueberwacht und im Zweifel zensiert oder gar sanktioniert werden soll. Im Netz muss man fuer foermlich jedes Informationszipfelchen die Nameserverinfrastruktur bemuehen. Pro geklickter Webseite koennen das schnell mehrere dutzend Anfragen sein. Und genau bei den Nameservern setzt das Gesetz eine Armada von Kalles an seinen individuellen Index Librorum Prohibitorum.

Man kann sich die Tragweite dieser Massnahme in die reale Welt uebertragen kaum vorstellen. In allen Bibliotheken und Buchhandlungen muesste man mit dem Buch, das man gerade kaufen moechte, noch vor der Kasse bei Kalle vorbei und haette mit Sanktionen zu rechnen, hielte man das falsche Buch in der Hand. Doch die Analogie fuer das Netz-Sinnesorgan "Browser" ist hier noch zu duerftig: Allein das Betrachten von Buechern im Schaufenster der Buchhandlung, das kurzfristige Aufflackern eines Plakats an einer Litfasssaeule schon waere eigentlich einer Erlaubnis beduerftig.

Nun ist das Zensurgesetz also um Magnituden monstroeser als alles, was bisher unter dem Begriff "Zensur" durch unsere Kulturgeschichte humpelte. In Ermangelung eines drastischeren Begriffs fuer dieses Ungetuem sei es jedoch erlaubt, vorerst den noch harmloseren Ausdruck zu verwenden.

Fuer den durchschnittlichen Bildungsbuerger sind memory holes ein Haushaltsbegriff. In digitalen Medien geht das mit dem "schnell was unbehauptet machen" noch schneller. Binsenweisheit, ich weiss. Trotzdem eine kurze Veranschaulichung.

Jedem Computerbesitzer, der schon einmal ein Bildbearbeitungsprogramm geoeffnet hat, sollten Nachrichten der Art, dass Filesharer anhand von Bildschirmausdrucken des p2p-Tools auf dem Rechner von Strafverfolgern – oder schlimmer gar: privater Rechteverwerter – Strafanzeigen kassiert haben, zumindest ein Stirnrunzeln hervorlocken.

Verweise der Art "http://test.com/seite.html abgerufen am 24.12.1978" machen dann Sinn, wenn web.archive.org dort just zu diesem Tag vorbeigekommen ist und von der /robots.txt nicht ausgeladen wurde. So rechte Beweiskraft, eventuell gar im juristischen Sinne, duerfte aber auch web.archive.org nicht geniessen. Das auch, obwohl diese Quelle fuer mich plausibel genug als neutral gilt.

Eine Nachricht im Papier-SPIEGEL kann ich auch Jahre spaeter noch als Quelle oder Beleg in Papierform aus meinem Keller wieder hervorkramen. Die Wahrscheinlichkeit, dass ich mir in der Druckerei meiner Wahl einen eigenen SPIEGEL gefaelscht habe, ist gering. Zur Not liegt ein Pflichtexemplar aller ernstzunehmenden Publikationen bei der Staatsbibliothek als Referenz.

Anders bei SPIEGEL Online. Einige Autoren sind dafuer beruehmt, dutzende Revisionen eines Artikels in hoher Frequenz zu "updaten". Nachvollziehbar ist ja noch, dass sie – seit sie den Lektor abgeschafft haben – dauernd Rechtschreib- und Grammatikprobleme korrigieren muessen. Wir sehen aber in letzter Zeit den Trend, kommentarlos einst Behauptetes zu entfernen, Ueberschriften abzumildern oder zu verschaerfen. Andere Zeitungen ziehen gar ganze Artikel zurueck. Wenn man Glueck hat, findet man diese noch in seinem Browsercache. Den Beweis zu fuehren, dass dieses elektronische Dokument auch wirklich vom Server der Zeitung geladen wurde, wird dem Leser aber schwerfallen.

Nun ist ja nachzuvollziehen, dass die (Online-)Magazine nicht ALLE Ausgaben umsonst ALLEN zur Zitatspruefung zur Verfuegung zu stellen wollen. Ich will aber dasselbe Mass an Nachvollziehbarkeit und Belegbarkeit von Veroeffentlichungen der sich selbst ernst genug nehmenden Medien! Und zwar im selben Sinne, wie ich das mit den Papierzeitschriften auch konnte. Ich komme deshalb nicht drumherum zu fordern, dass Pruefsummen aller Revisionen an einer oder mehreren unabhaengigen Stellen hinterlegt werden, gegen die ich als Leser und Zitator meine Kopie, aus der ich zitiere, belegen kann.

Hier bieten sich natuerlich zuerst die Bibliotheken an, die Listen von signierten Pruefsummen vorhalten und bei Disput als autoritative Quelle zum Vergleich herhalten koennten. Diese Signaturen muessten alle teilnehmenden Publikationen leisten - und dass fuer jedes Update.

Weiter sollen auch Bibliotheken selbst eigene Signaturen auf einzelne Zitate aus einer spezifischen (dann im Volltext vorgehaltenen) Revision eines Online-Artikels herausgeben. Um journalistische Standards zu unterstuetzen und einer breiten Masse an Schreibern das Zitieren zu ermoeglichen, muss dieser Zitatsdienst natuerlich kostenfrei zur Verfuegung stehen.

Wie genau dies umgesetzt wird, werden viele schlauere Leute als ich gewiss ausbaldowern. Einzig: Das Wohlfuehlgefuel beim Lesen eines Online-Blattes (und dabei schliesse ich "Qualitaetsblogs" explizit mit ein) stellt sich erst ein, wenn nicht yesterdays news im digitalen memory hole verschwinden koennen.