WWW

Ich bin recht früh aufgewacht. Beim morgendlichen Konsum meiner RSS-Feeds fiel unangenehm auf, das heise down ist. Nachdem ich einige Zeit damit zugebracht habe mein Netzwerk-Setup zu prüfen kam ich doch auf die Idee, dass es an denen liegen könnte. ;-)

Bei der Suche nach aktuellen Infos über den Status quo fiel mir dieses Blog-Posting von Fefe in die Hände. Und er hat ja so recht. :)

Nein, ich weiß auch nicht, wieso Heise seit Stunden down ist. Ist mitten in der Nacht, da updated sich da eh nichts. Geht mal schlafen oder feiern oder was weiß ich, Nerds. Nicht zu fassen, sitzen da alle vor ihren Kisten und klicken reload im Browser.

Peter Pramberger hat gestern Abend auf der SKS-Devel-Mailingliste angekündigt, seinen PGP-Keyserver unter keyserver.pramberger.at abzuschalten:

Several weeks ago I got a complaint from a user getting his old PGP key
removed from my keyserver. He got the usual answer in such cases, but
unfortunately wasn't accepting it. Instead he insisted on his right to get the
key removed, in accordence to the Austrian Data Protection Act (DSG 2000).

Ohne das Österreichische Datenschutzgesetz im Detail zu kennen, gehe ich stark davon aus, dass es sich zu den anderen in Europa gebräuchlichen Datenschutzgesetzen nicht all zu sehr unterscheidet. Der Fall ist also im Grunde portabel.

Nach anfänglicher Empörung stelle ich mir allerdings schon die Frage, was an der Begründung eigentlich dran ist. PGP-Keyserver funktionieren nach dem Prinzip, dass man nur öffentliche Keys hoch lädt und diese Keys dann für immer öffentlich abrufbar sein sollen. So gibt es mehrere Keyserver-Netzwerke, die ständig die Keys unter einander austauschen. Löscht man einen Key auf einem Server, wird er umgehend von einem anderen Server wieder kopiert. Eine nachhaltige Löschung ist also nicht vorgesehen und in der Praxis auch nicht möglich.

Auch wenn es sich dabei um öffentliche Schlüssel handelt, stimmt es natürlich, dass der Eigentümer beim Hochladen nicht in rechtlich brauchbarer Weise über den Umstand aufgeklärt wird, dass das eine unwiderrufliche Veröffentlichung seines Namens, seiner E-Mail-Adresse und ggf. seines Fotos ist.

Ohne dass dies irgend jemand mal zu mindest zu einem erfahrenen Anwalt trägt oder gar eine Gerichtsentscheidung provoziert, bleibt der Betrieb eines PGP-Keyservers also vermutlich eine höchst gefährliche Sache, deren juristische Konsequenzen der einfache Admin nicht abschätzen kann.

Mit großem Tam-Tam hat sich am Montag das Hamburger Abendblatt zum heiligen Samariter der Old-School-Journalisten empor geschwungen und verkündet, dass man zukünftig für einen Teil der Inhalte Geld haben möchte. Wenn man sich im HA-Online-angebot umschaut, sieht man dass quasi alle Artikel nur noch gegen Gebühr angeboten werden sollen.

Ob das eine gute Idee ist? Ich möchte darauf nicht eingehen. Es ist zu abstrus.

Warum ich den Artikel schreibe, hat einen anderen Grund. Und zwar die Offenbarung vor Google, die das Abendblatt hier abliefert.
Es ist noch nicht allzu lange her, da ging durch sämtliche Online-Medien eine Welle der Entrüstung. Man sah sich konfrontiert mit einer Ausgeburt des Bösen, nämlich Google News. Google scannt selbstständig eine gigantische Menge an Artikeln auf allerlei Nachrichten-Seiten und gruppiert diese anhand von Schlagwörtern.
Beim HA habe ich zugegebener maßen nichts finden können was diese Aufregung formuliert, aber z.B. beim Spiegel gibt es einen Artikel dazu: Wie Google News Redaktionen ausbeutet.

Man mag also Google nicht. Google ist böse. Denn Google bringt einem nur noch mehr Klicks von noch mehr Kostenlosfanatikern.

Kern meines Spotts: Man nehme einen UserAgent-Switcher (z.B. als Firefox-Extension) und schalte auf eine Kennung des Google-Bot um. Et voilà, die Website des Hamburger Abendblattes steht wieder sperrangelweit offen wie gehabt und man kann alle Artikel ohne Einschränkung lesen.

Was sagt uns das? Ich glaube nicht, dass hier die Programmierer der Website einen gravierenden Fehler gemacht haben. Es ist bestimmt kein Faux-pas, dass hier der Google-Bot die Nachrichten lesen kann, die man eigentlich nur im Abonnement erhalten sollte.
Aber warum? Wäre das jetzt nicht die längt herbeigesehnte Situation, dass man dem bösen Google News (der mit einem Seiten-Login nicht wirklich umgehen kann) endlich einen Riegel vorschieben kann. Dass endlich nicht mehr mühsam geschriebene Artikel in der Kostenloskultur verpuffen.

Aber nein, es ist recht klar, dass hier einfach die Werbe-Wirkung, der Klickzahlengenerator Google nicht geschädigt werden soll.

Das muss man sich mal auf der Zunge zergehen lassen: Da ist ein Unternehmen, das eigentlich nichts weiter macht als kostenlose Dinge aufwändig zu sortieren und wiederum kostenlos abzugeben. Dieses Unternehmen wird mit dieser Tätigkeit stinkend reich. Dann ärgern sich die Kostenlos-Content-Anbieter, dass das mit dem Kostenlos-Content ja gar nicht so gedacht sei, dass man das auslesen und sortieren soll. Man soll das nur lesen (im humanen Sinne) und nicht woanders speichern. Nun wird aber anders herum, genau der eigentlich nicht kostenlose Content zufälligerweise eben doch kostenlos nur in dieses böse Unternehmen gepumpt. Da stimmt doch irgendwas nicht an der Argumentationskette, oder?


Der Hohn auf dem ganzen ist ja, dass Google aus den mittlerweile lizenzierten Agenturmeldungen auch keine schlechteren Artikel produziert als die Journalisten. Im Gegenteil, die stupide Technik von Google schafft es im Zweifel sogar, verschieden tendenziöse Beiträge über das selbe Thema nebeneinander anzuzeigen. Eine Redaktion wird mindestens die für ihre Ausrichtung am besten passende Agenturmeldung publizieren, wenn nicht sogar noch das ein oder andere "unwichtige" Detail weglassen um einen vorher festgelegten Eindruck zu vermitteln. Objektiver (Endkunden-)Journalismus kann heutzutage von einer Maschine mindestens genauso gut erledigt werden wie von einer Redaktion. Na dann, Prost Mahlzeit an die Internet-Ausdrucker.

Nachdem wir seit ein paar Wochen mehrmals täglich mit einem bestimmt ganz interessanten, nur leider total unerwünschten Newsletter beglückt wurden, habe ich heute mal den Abmelden-Link betätigt. Ich möchte nicht sagen, um welchen Anbieter es dabei geht.

Der Link besteht an personenbezogenen Daten nur aus einem Hash, also eine zufälligen Zeichenkette. Üblicherweise legt man in einer Datenbank diesen Hash als einseitiges Identifizierungsmerkmal bei den Kundendaten ab. Eine löbliche Praxis, so wird keine E-Mail-Adresse übertragen.

Durch Aufruf der URL wurde mir meine E-Mail-Adresse angezeigt, zusammen mit der Meldung

Abmeldung

Ihre Abmeldung war erfolgreich. Wir bedauern sehr, Sie als Leser unseres geld.de-Newsletters verabschieden zu müssen.

Empfängerdaten gelöscht. IIhre persönlichen Daten und Einstellungen wurden erfolgreich aus unserem System gelöscht. Sie nehmen zukünftig nicht mehr am Empfang des geld.de Newsletters teil.

Klingt gut? Ja, tut es.

Aber es verliert seine Glaubwürdigkeit, wenn die selbe Meldung mit der selben Klartext-E-Mail-Adresse (die, wie wir wissen, nicht von mir in der URL übertragen wurde) nach einem Reload der Seite immer wieder gezeigt wird.
Noch immer weiß die Datenbank meine E-Mail-Adresse. Das sollte aber nicht so sein, wenn (wie geschrieben wurde) der Löschvorgang wirklich funktioniert hat.
Ein Löschvorgang auf die selben Daten, der wiederholt "erfolgreich" verläuft, ist keine gute Idee!

Übrigens erhält man die Abmelde-Bestätigung nur, wenn man AdBlock Plus abschaltet. ;-)

Da ich seit langem bei OSM aktiv bin, hatte es mich immer wieder gestört, dass ich kein mobiles Gerät habe, auf dem ich diese Karten nutzen kann.

Momentan gibt es leider keinen voll befriedigenden Weg, OSM-Karte auf einem mobilen Gerät zu betreiben und umfassend zu benutzen.
Die dafür programmierten Anwendungen sind einfach noch nicht so weit, dass man sich damit in fremden Gefilden navigieren lassen könnte und die Hersteller proprietärer Navigationssysteme halten ihr Dateiformat aus verständlichen Gründen unter Verschluss.

Seit langem sind mir Besucher-Tracker ein Dorn im Auge. Daher sind Domains wie www.etracker.de und google-analytics.com seit einiger Zeit bei mir im lokalen DNS-Server gesperrt, so dass diese aus meinem lokalen Netz nicht mehr aufgerufen werden können.

Leider wird grade etracker oftmals so penetrant eingesetzt, dann man einfache Unterseiten oder Downloads nicht mehr aufrufen kann, wenn deren Seite nicht mehr erreichbar ist.

Daher habe ich mir jetzt einen lokalen "Proxy" für dieses Problem erstellt. Das Setup ist simpel:

• Ein lokaler DNS-Resolver wird so konfiguriert, dass er für den betreffenden Host die Adresse eines eigenen Webservers zurückliefert.


• Der Webserver erhält einen neuen VHost, der für die Hostnames der betreffenden Websites verantwortlich ist.


• Ein CGI-Script liest die URL aus dem Aufruf-Parameter und sendet eine Weiterleitung an die betreffende Adresse ohne dass irgendwelche Statistiken zentral gespeichert werden.

Nachfolgend meine dafür verwendeten Konfigurationen und Scripte.

Ich habe dazu folgende Quellen in den letzten Tagen zufällig gefunden...
Auf Heise.de einen Artikel, in dem die Speicherdauer bei YouTube thematisiert wird:

YouTube lösche üblicherweise nach sieben Tagen die IP-Adressen der Rechner, von denen Dateien in das Internetportal eingestellt werden.

Dazu ein weiterer Heise-Artikel, der die IP-Adressen-Speicherung bei der Suchmaschine von Google behandelt:

Der Suchmaschinenbetreiber Google will die Haltedauer für die IP-Adresse bei Suchanfragen bis Ende September von bisher 18 auf künftig neun Monate reduzieren, danach werden die Anfragen anonymisiert.

Besonders nett ist natürlich die Begründung dieser neun Monate Speicherung in eben letzterem Artikel:

Laut dem Datenschutzbeauftragten des Konzerns, Peter Fleischer, sucht Google die Balance zwischen dem Datenschutz auf der einen Seite und den Interessen von Google auf der anderen. Letztere bestehen darin, die eigenen Dienste kontinuierlich zu verbessern und gegen Missbrauch und Angriffe zu schützen [...] (Hervorhebung von mir)

Missbrauch und Angriffe sind bei jedem Server und jedem öffentlich zugänglichen Angebot natürlich immer eine Möglichkeit. Daher habe ich an der einwöchigen Speicherung von IP-Adressen bei YouTube noch nichtmal grundlegend etwas auszusetzen. Ich finde es nicht gut, aber es tanzt nicht aus der Reihe anderer ("normaler") Websites.

Anders dagegen die Speicherung bei der Suchmaschine. Eine Internet-Suche hat ein für mich schwer erkennbares Missbrauchspotenzial. Auf YouTube kann man eigene Mediendaten hochladen, dabei sowohl bzgl. Urheberrecht als auch bzgl. Beleidigungen und ähnlichem unschöne Dinge tun. Durch eine Internet-Suche bei Google kann man... Nun, mir fällt jetzt nicht direkt etwas ein. Die Features der Suchmaschine halten sich derart in Grenzen, dass ich XSS (die sich aber durch IP-Adressen gar nicht wirklich verfolgen lassen) und vergleichbare Sicherheitslücken sicher ausschließen kann. Ebenso SQL-Injections. Ein einziges Eingabefeld lässt sich mit vertretbarem Aufwand gegen alle bekannten Sicherheitsprobleme absichern. Zumindest ungleich einfacher als die Features von YouTube.

Warum also begründet Google die Protokollierung von Suchanfragen damit, dass man auch ein Dreivierteljahr später noch wissen muss wer was gesucht hat um "Missbrauch und Angriffe" zu erkennen?

Im Gegenzug frage ich mich, warum ist dies bei YouTube anders? Warum ist das Hochladen und Veröffentlichen bei YouTube kein so großes Sicherheitsrisiko wie das Stellen einer Suchanfrage bei Google?

Ich finde das Schizophren und die Begründung mit der Sicherheit ist Heuchelei.
Bei uns wird normalerweise keine IP-Adresse gespeichert. Kunden können auf Wunsch Logfiles über maximal 10 Tage erzeugen. Wenn nicht explizit vom Betreiber aktiviert, dann auch das ohne IP-Adresse.

Ab und an hat man eine Idee, welche Anwendung der Menschheit noch gefehlt hat und will dieses Manko umgehend selbst beheben. Oft kommen dabei gute Ideen bzw. Anwendungen heraus.

Schlecht ist allerdings, wenn die Umsetzung dann doch genau das nicht macht was sie verspricht.

So gesehen beim einfachen Web-Service DownForEveryoneOrJustMe. Gibt man dort eine Adresse ein, die erreichbar ist, ist das eine nette Bestätigung, dass es funktioniert.

Gibt man aber eine Adresse ein, die einen Timeout verursacht (was ja ab und an vorkommt, wenn eine Seite wirklich down ist), dann erhält man nach einer entsprechenden Wartezeit einen Fehler von Google, dass auf der Website ein Fehler aufgetreten sei. Also der Timeout des bei Google betriebenen PHP-Scripts kommt früher als der HTTP-Timeout beim Versuch die Seite zu testen. :)

Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.

Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.

Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.

Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.

Ich komme mir grade vor als hätte ich ein paar Jahre hinterm Mond gelebt. Und zwar war mir die Existenz von CSS »block formatting contexts« völlig fremd.

Für meine Leser, von denen ich erwarte, dass es ihnen genauso geht, kurz ein Abriss:
Wenn man ein Element mittels float: left links ran kleben will, ist das einfach. Will man aber dieses float mittels clear: left wieder aufheben, dann fängt der nachfolgende Text erst unter der meistens vorhandenen linken Sidebar an. Zudem macht Internet-Explorer (< 7) gerne mal sehr komische Dinge bei einem traditionellen Sidebar-Layout.

Auf der Suche nach einer Lösung bin ich heute darauf gestoßen, dass man ein div auch in einen eigenen Formatierungs-Kontext setzen kann, innerhalb dessen beliebige clear-Statements möglich sind ohne das ganze Layout zu zerstören.

So einfach geht's: Dem Inhalts-div einfach overflow: hidden mit auf den Weg geben. Natürlich kann diese Eigenschaft Nebenwirkungen haben. Z.B. wenn man ein Element hat, das potenziell breiter ist als das Browser-Fenster. Sofern man aber die Größe des div nicht festlegt, sollte man oftmals gar keine Nebenwirkungen bekommen.
Der Internet-Explorer möchte (mittels conditional comments) noch zusätzlich ein float: left bekommen, damit das so funktioniert. Aber dann spielt auch der mit.

Die Lösung habe ich auf zahlreichen CSS-Hilfe-Seiten gefunden, eine Seite die es so hinbekommen hatte, dass ich es verstanden hab ist z.B. diese hier.