WWW

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.

Die Webhostlist (ja, ohne Link. Jeder kann .de dahinter setzen, wenn er will) ist ein Web-Portal, auf dem Angebote von Providern und Gesuche von zukünftigen Kunden zusammen finden sollen. Ein ganz normaler Preisvergleich bzw. Kleinanzeigenmarkt.

Dafür gibt es zwei Kanäle: Das Angebotlisting, in dem jeder Provider seine Angebote einstellt und Kunden nach diversen Kriterien suchen können auf der einen Seite und das Forum auf der anderen Seite. Im Forum stellt ein Kunde seine Anforderungen ein und Provider können mit einem Angebot antworten. nicht selten führt das zu skurrilen Dingen wie "Suche Webspace mit Feature foobar." mit der Antwort "biete das zwar nicht an, aber vielleicht ja was anderes was dich interessiert".

Als wichtige Bemerkung sei noch eingeführt, dass Provider bei Webhostlist unterschiedlichen Status haben können. Ungeprüft ist man immer als erstes. Wenn man dann viel Geld zahlt (ich weiß viel ist relativ), wird man Geprüfter Provider. Dazu muss man eigentlich nichts weiter machen als Geld zu zahlen. Zahlt man dann noch mehr Geld, wird man sogar Premium-Provider. Bisher war der Mehrwert darauf begrenzt, dass neben den Angeboten ein hübsches goldenes Emblem gezeigt wurde, das dem Kunden versichert, dass der Provider auch wirklich Geld an Webhostlist gezahlt hat.

Die zahlenden Provider haben sich (mittlerweile erfolgreich) beschwert, dass das Geldausgeben nur für ein hübsches Bildchen vielleicht nicht ganz gerechtfertigt ist.

Daraufhin wurde folgendes Umgestellt:
Wer ein Gesuch in das Forum einstellt, muss Daten-Striptease betreiben. Webhostlist fordert eine vollständige Adressangabe, anfangs sogar zwingend mit Telefonnummer. Gleichzeitig kann der Suchende auswählen, welcher Provider-Typus seine Daten und sein Gesuch sehen kann. Standardeinstellung ist (*Tusch*) zahlender Geprüfter Provider.
Die Webhostlist begründet das unter dem Applaus einiger zahlender Provider damit, dass man ja auf seriöse Geschäftsbeziehungen setze und daher die Angabe einer Identität verlangt werden könne. Zudem möchten Anbieter auch wissen, wem sie eventuell kein Angebot mehr machen möchten, wenn die den Namen schon kennen. Nun ja.
Ein Foren-Teilnehmer hat das treffend umschrieben mit der Pflicht, bei jedem Geschäft einer Einkaufspassage immer vor jedem Betrachten des Schaufensters eine Visitenkarte abgeben zu müssen.

Klar, so schlägt man zwei Fliegen mit einer Klappe: Es wird für alle Datenkraken-Provider sehr interessant, viel oder sehr viel Geld an Webhostlist zu zahlen, denn dafür bekommt man jetzt zuverlässig neue Adressen für seine Verbraucherinformationen. Webhostlist bekommt also mehr zahlende Kunden. Auf der anderen Seite werden die Adressen ja gespeichert und somit reiht sich Webhostlist nahtlos in die Liste der in den letzten Jahren stark an Wert gestiegenen Unternehmen mit vielen "Benutzerprofilen", in welcher Form auch immer.

Die vielen Forums-Beiträge, die diese Regelung als kompletten Unsinn bezeichnet haben, wurden konsequent ignoriert, was natürlich auch irgendwie aussagt, dass diese Regelung wohl nicht mit guten Argumenten belegt werden kann.

Die komplett sinnbefreite Kompromisslösung, die jetzt angestrebt wird (oder schon implementiert ist), sieht vor, dass der Anbieter erst nach Abgabe eines Angebots die Kontaktdaten des Interessenden sieht. Wie man das überhaupt irgendwie begründen kann, ist mir noch nicht eingefallen.



Als weitere Veränderung (da weiß ich aber nicht seit wann) gibt es bei der Suche nach Webhosting-Tarifen jetzt auch keine Möglichkeit, die nicht-zahlenden Provider überhaupt anzuzeigen. Erst nach Erhalt der Ergebnis-Liste kann man die Suchergebnisse auf nicht-zahlende Provider ausdehnen. Und diese Einstellung springt meiner Erfahrung nach manchmal etwas willkürlich wieder auf die Standardeinstellung zurück.

Was ich damit sagen will: Jeder, der über Webhostlist einen Provider sucht, sollte sich darüber im Klaren sein, dass er immer erstmal nur Angebote von Firmen bekommt, die der Webhostlist Geld bezahlt haben. Auch wenn die Webhostlist sich nach außen als kostenlos für beide Seiten kommuniziert. Und dass im Forum nun die Angabe falscher Daten zur Regel wird, ist (denke ich) auch klar.

Ich hätte einen penetranten Newsletter-Versender im Angebot, der kein Double-Opt-in macht.
Mit Ausnahme des "Erfolgreich eingetragen" auf der Website bekommt der glückliche Newsletter-Empfänger übrigens keine Mail (bis auf den nächsten Newsletter natürlich).

Zudem noch: Auf der Website oder im Newsletter wird keine Möglichkeit genannt, wie man den Newsletter abbestellen kann. Es gibt nur "Anmelden".

Irgendwie gar nicht gut, oder? ;-) Wenn man sowas macht, sollte man zumindest den Firmensitz nicht in D haben.

Neulich konnt eich mich endlichmal aufraffen, mich um automatisiertes Onlinebanking zu kümmern um nicht immer alle Lastschriften für schokokeks.org manuell machen zu müssen.

Die gute Nachricht zuerst: Es geht einfacher als ich vermutet hatte. Ich benutze jetzt diese Kommandozeile:

aqbanking-tool debitnote --bank=60291120 --account=671279017 --rbank=12345678 --raccount=192837465 --rname="Kundenname" --value="123,00:EUR" --purpose="schokokeks.org" --purpose="Re-Nr. 1234, Kd-Nr. 05" --purpose="vom 2007-12-01" --force-check --exec

Diese Zeilen lasse ich mir von einem Script zusammen bauen, das die Daten der aktuell offenen Rechnungen aus der Datenbank liest.


Aber nun zum Ernst der Lage:
Ich hatte vor einiger Zeit in einem Blog-Posting dazu aufgerufen, dass man an das AqBanking-Projekt spenden sollte, damit der Entwickler die Spezifikationen für die neuen Volksbank-Karten kaufen kann.

Ich hatte diesen Aufruf nicht gelöscht oder geändert, weil ich der Meinung war, auch wenn diese Spezifikationen jetzt beschafft wurden, sollte der Autor einen Anreiz haben, den Code auch zu schreiben.

Jetzt allerdings muss ich diesen Aufruf entschieden zurücknehmen. Der Grund dafür ist hier zu finden:
http://www.aquamaniac.de/sites/aqbanking/user.php#aqbanking-cli

Eben dieses Kommandozeilen-Programm, mit dem ich obigen Kurztipp durchführe, wird aber der kommenden Generation der AqBanking-Schnittstelle kommerzielle Software werden und nicht mehr frei zur Verfügung stehen.

Natürlich ist das keine komplette Katastrophe, man kann (vermutlich) eines der auf AqBanking aufbauenden Programme als Vorlage für ein relativ minimalistisches, neues Kommandozeilen-Programm benutzen. Aber alleine das Vorgehen, dieses Programm ohne Erklärung, mit der fadenscheinigen Begründung "Da dieses Tool hauptsächlich professionell benutzt wurde, ist es nun nicht mehr frei verfügbar", kommerziell zu machen, finde ich sehr bedenklich.

Kombiniert mit der Erkenntnis, dass dieses Projekt nur Code annimmt, wenn die vollständigen und uneingeschränkten Verwertungsrechte an Martin Preuss übertragen werden, finde ich dieses Projekt ab sofort nicht mehr unterstützenswert. Trotz der unbestrittenen Leistung, die Martin Preuss in dieses Programm investiert, finde ich diesen Umgang mit Code-Beiträgen Dritter nicht angemessen für ein freies Projekt.

Diese Woche erschien die neue Version der Handy-Java-Software »Mobile Trail Explorer«, Version 1.8.

Mit dieser Software und einem Bluetooth-GPS-Empfänger ist es möglich, GPS-Tracks aufzuzeichnen. Das größte manko der Vorversion war, dass die Software gelegentlich beim Speichern abstürzte (die berüchtigte "OutOfMemoryException") und damit der komplette Track weg war. man durfte also nicht vergessen, nach spätestens 500 Trackpoints zu speichern, da sonst die Datenmenge zu groß wurde.

Nicht so mit der neuen Version!!

Jetzt gibt es die Option "GPX-Stream". Dabei wird sofort begonnen, die Datei zu schreiben. Die Software schreibt Punkt für Punkt in die Datei und hält nicht einfach alles im Speicher. Dadurch gibt es keine Wartezeit und kein Speicherproblem nach Abschluß der Aufzeichnung.

Kurzanleitung:

• Menü
• Manage Trails
• Option
• New GPX stream
• Dann kommt die Frage des Telefons ob auf die Speicherkarte geschrieben werden darf
• Danach noch »Start/Stop recording«
• Nach Abschluß der Aufzeichnung (»Start/Stiop recording«) kommt der üblicher Speichern-Dialog, mit der zusätzlichen Option am Ende »Close GPX Stream«
• Der Name der resultierenden Datei beginnt mit »stream_«

Besonders erwähnenswert:
Wenn das Programm abstürzt oder versehentlich beendet wird, geht nichts verloren! Beim nächsten Start fragt das Programm ob der alte GPX-Stream fortgesetzt werden soll. tut man das nicht (»Forget about it«), hat man aber auch trotzdem noch eine Datei, bei der man nur das XML manuell schließen muss, die Punkte sind dennoch alle drin.

Noch nicht getestet habe ich, ob in diesem GPX-Stream auch die Waypoints drin sind.

Nach diesem ersten Eindruck der neuen Version: Prädikat »Absolut empfehlenswert!«

Ja, die wesentlichste Neuerung war, dass das Program OSM-Tiles als Hintergrund anzeigen kann und damit die eigene Route live visualisieren kann. Aber ohne vernünftige Daten-Flatrate und ohne schnellere Verbindung ist das für mich etwas sinnlos. Ich freu mich einfach über die neue GPX-Stream-Funktion.