Blog
Mein Standort
Kategorien
Piratenpartei und wie man ein Forum nicht betreibt [Update]
gepostet in Internet am 13.02.2010 um 22:23
Das Forum der Piratenpartei ist umgezogen. So hiess es in einem Forenbeitrag im offiziellen Parteiforum. Schade nur, dass das voll gegen die Wand fuhr.
War das Forum vorher unter http://forum.piratenpartei.de/ erreichbar, hiess es nun http://forum-piratenpartei.de/ und bei einer Partei, die sich für Privatsphäre einsetzt, entstanden direkt P's in den Augen der Forenmitglieder. Ihre Daten wanderten ungefragt auf einen privaten Server und zudem noch an einen neuen Admin, mit dem wohl nicht jedermann einverstanden war. Verständlich, dass die Anzahl der Posts in dem Thread in kürzester Zeit rasant anstieg. Im Moment liest man grad eine Meldung auf dem neuen Forum, dass das Forum wieder umzieht, wohl an die alte Stelle zurück.
Ob wohl ein wenig Transparenz über den Umzug, die neue Administrator-Entscheidung (der vorher wohl schon Administrator war und angeblich eine andere sichtbare Nutzergruppe hatte) und den Datenschutz ein wenig Wind aus den Segeln genommen hätte, weiss man nicht. Bleibt abzuwarten, ob die Piraten jetzt zurückrudern.
Update: Inzwischen ist das Forum wieder auf der alten Domain zu finden und anscheinend wird es erstmal eine Klärung des Sachverhalts geben.
Pingback - Eine Fehlentwicklung
gepostet in Internet am 13.02.2010 um 20:56
Im Rahmen der Implementierung von Pingbacks in diesem Blog und fehlender Libraries für Python, die auch auf der AppEngine funktionieren, hab ich Pingbacks nach der Spezifikation implementiert.
In dem Zuge bekam ich das Gefühl, dass Pingback irgendwie eine Fehlentwicklung ist. Da wäre z.B. Auto-Discovery. Die XML-RPC-URL über einen HEAD-Aufruf zu holen finde ich noch recht legitim. Aber als Alternative HTML zu parsen und zu verlangen, dass der Meta-Tag innerhalb der ersten 5 kB des Dokuments vorkommen, ist nahezu frech. Der angepingte Server hat ein ähnliches Problem. Er muss (optional, aber um ordentliche Pingbacks in Blogbeiträgen anzeigen zu lassen, unumgänglich) HTML parsen, um herauszufinden, ob die gepingte URL wirklich in dem Dokument vorkommt und auch, um sich den Titel der Seite zu holen.
Als Gegensatz dazu gibt es Trackbacks. Da werden Quell-URL, Titel und ein kleiner Abschnitt des Textes bereits beim Ping mitgesandt und können vom Moderator bestätigt werden. Mein Problem mit dem Parsen ist nämlich, dass es in den meisten Fällen syncron passiert, da man, wie man das schon in der Spezifikation sieht, entsprechende Fehlercodes zurückgeben muss, wenn etwas schief läuft, wie z.B. dass die angepingte URL gar nicht im Quell-Dokument vorkommt.
Realitätscheck: Gehen wir mal von einem mittelgut besuchten Blog aus. Der Blogbeitrag wird gepublished und diverse Dienste angepingt (pingomatic, Pubsubhubbub, Yahoo, usw.), die widerum die eigene Seite aufrufen und auch die aktualisierten Feeds checken. Hinzu kommt der automatische eigene Tweet, der auch nochmal 20-30 Leute auf das Blog schickt. Jetzt kommt der Pingback an ca. 3 Links, die sich im Text befinden. Das Blog ist jetzt etwas unter Spannung und die Seiten werden erst nach 3-5 Sekunden ausgeliefert. Aus Skalierungsgründen haben viele Pingback-Implementierungen einen Timeout von 2-4 Sekunden für Requests eingestellt. Die angepingte Seite versucht also jetzt auch das pingende, etwas belastete Blog aufzurufen und bekommt im Zweifel einen Timeout nach 3 Sekunden. Schade nur, dass in diesem Moment das pingende Blog eine Fehlermeldung zurückbekommt und es höchstwahrscheinlich nicht nochmal probiert.
Meine Implementierung versucht den Ablauf asyncron zu halten. Er nimmt den Ping erstmal entgegen. Wenn der Ping in keinem gültigen Format gesandt wird, bekommt er einen Generic-Error (0), ansonsten immer ein OK. Danach wird drei mal versucht, die Seite aufzurufen und zu parsen und dann erst aufgegeben. Diese Methode skaliert deutlich besser, ist aber leider in der Spezifikation nicht vorgesehen. Das ist wirklich schade und schon ein großer Überlegungsfehler.
Andere Schwäche: Der Mix. Es muss ein XML-RPC-Request geschickt werden. Alle Responses sind dann nicht mehr XML-RPC sondern String-Responses. Das ist sehr inkonsistent und wird begründet mit der Einfachheit, so wenige Libraries bei der Implementierung benötigen zu wollen. Aber dann hätte ja auch ein PUT oder POST-Request gereicht, dem man z.B. sourceURI und targetURI als Parameter hätte mitgeben können. Auch, dass man die Parameter-Reihenfolge im XML-RPC einhalten muss und nicht die namentlichen Parameter-Angaben gewählt hat, zeigt, dass man nicht darauf bedacht war, fehlertolerant zu sein.
Blog jetzt mit Pings
gepostet in Internet am 12.02.2010 um 23:39
So, ein Stündchen Arbeit und endlich kann das Blog automatisch und asynchron pingen. Unterstützt wird erstmal nur XMLRPC wie bei Ping-O-Matic & Co. und auch Pubsubhubbub funktioniert. Testweise erstmal mit dem Standard-AppEngine-Hub, aber weitere lassen sich natürlich schnellstens und einfach hinzufügen.
Googles großer Fehler
gepostet in Internet am 11.02.2010 um 09:23
Immer wenn man den Namen "Google" erwähnt, schwirrt der Begriff "Datenkrake" in den meisten Köpfen. Wenn ich mir das mal genauer anschaue, ist der größte Fehler, den Google gemacht hat: Transparenz.
Google sagt: Ja, wir speichern alles was ihr tut. Wir geben eure Daten sogar weiter, aber völlig entpersonalisiert, sodass wir wissen, wer ihr seid, andere aber nur irgendwelche Userprofile haben.
Nehmen wir mal Google Mail als Grundlage, ergibt sich da ein interessantes Bild. Bemängeln viele Datenschutzmöchtegernexperten, dass Google die Mails automatisiert indexiert (was übrigens auch jedes E-Mailprogramm macht) und entsprechend Werbung einblendet. Aber Google ist so ehrlich und schreibt es wenigstens in seine Datenschutzhinweise.
Vergleicht man das mal mit einem anderen großen deutschen Webmailer GMX, bekommt man da schon etwas mehr Panik:
Adress- und Negativdaten werden an andere Konzernunternehmen und eine zentrale Datei übermittelt, die von der United Internet AG zum Zwecke des Schutzes aller Konzernunternehmen geführt wird. Anderen Konzernunternehmen werden diese Daten bei berechtigtem Interesse zweckgebunden zur Verfügung gestellt.
GMX weist den Kunden ausdrücklich darauf hin, dass der Datenschutz und die Datensicherheit für Datenübertragungen in offenen Netzen wie dem Internet nach dem derzeitigen Stand der Technik nicht gewährleistet werden kann. Der Kunde weiß, dass der Provider die auf den Webservern gespeicherten Daten des Kunden aus technischer Sicht jederzeit einsehen kann. Auch andere Teilnehmer am Internet sind unter Umständen technisch in der Lage, unbefugt in die Netzsicherheit einzugreifen und den Nachrichtenverkehr zu kontrollieren. Für die Sicherheit und Sicherung der von ihm ins Internet übermittelten und auf Webservern gespeicherten Daten trägt der Kunde vollumfänglich selbst Sorge.
Argh! Das heisst also: Ihre Daten sind und scheißegal, sie sind selbst dafür zuständig ihre Daten zu schützen. "Wir geben Ihre Daten auch gerne in unserem nicht grad kleinen Konzern weiter."
Zwar ist es für Google einfacher, komplexere Profile eines Menschen zu erstellen, da der Umfang der Dienste, die durch die Benutzer verwendet werden können, deutlich größer ist, aber dann kommt auf der anderen Seite der "Pöbel", der gerne so wenig wie möglich denken möchte.
Nehmen wir z.B. Amazon: Da freuen sich die Leute, dass sie Vorschläge bekommen, was ihnen gefallen könnte. Was schätzt ihr wohl, worauf sich diese Daten beziehen? Aus den Profilen, die sie durch euer Kaufverhalten erstellen. Inzwischen gibt es einkaufbare Shopsysteme, die ähnliche Funktionen bieten und schon ist man selbst eine Datenkrake, weil man seinen Besuchern/Kunden etwas Gutes tun will.
Fazit: Alle wollen Statistiken, aber niemand will sie befüllen. Will heissen, dass jeder Komfort will, aber nicht nicht dran teilnehmen will, dass dieser Komfort erfüllt werden kann. Am Lautesten brüllen eh diejenigen, die in der Werbebranche sind und dieses System tagtäglich ausnutzen.
Buzz ist besser als der erste Eindruck
gepostet in Internet am 10.02.2010 um 23:21
Meine Twitter-Follower werden es mitbekommen haben, aber ich meine Tweetdichte war doch heute nicht so hoch, weil ich natürlich direkt Buzz näher ausprobieren musste.
Mobile: Es begann mit Google Maps für mein Nokia E71 (Symbian S60). Schnell die neue Version 4.0 installiert und schon war die Karte um mich herum voll mit Sprechblasen, an dessen Punkte schon Leute ihre Buzzes abgelegt haben. Nicht nur, dass man mit Hilfe von Latitude sieht, wo seine Freunde grad sind, sieht man auch, welcher Buzzer (Benutzer von Buzz) grad in der Nähe ist. Da ergeben sich gleich neue Bekanntschaften und man hat sowas wie einen Check-In auf Foursquare, nur ohne den Game-Faktor. Gleichzeitig kann man seinem Buzz auch noch ein Photo mitgeben, um dem Ganzen noch ein I-Tüpfelchen aufzusetzen.
Der Alltagstest: Hier wird's schwieriger und ich muss etwas ausholen. Ich bin jetzt seit ca. 1 Jahr dabei, meine täglich genutzten Tools und Programme ins Web zu verlagern, um bei Einzug eines Web-OS wie ChromeOS nichts zu vermissen. Dieser Plan ging bisher nicht so gut auf, weil die Twitter-Website eine kleine Katastrophe ist und sich nicht automatisch aktualisiert und ich dafür einen guten Client brauchte. Hootsuite und Seesmic find ich absolut unbenutzbar und somit blieb mir bisher Tweetdeck. Jetzt kommt Buzz ins Spiel, welches dieses Spiel mitspielt. Die Buzzes fließen alleine rein und auch die Kommentare erscheinen von alleine. Außerdem kommt ein weiteres Feature direkt dazu: Ich hab die Mailoberfläche zusammen mit dem Microblogging-Dienst und ich spare mir dadurch ein Browsertab/-fenster.
Wie viele andere Leute heute noch, habe auch ich früher meine E-Mails mit einem Mailclient wie Thunderbird abgeholt. Diese Zeiten sind bei mir inzwischen vorbei und ich hoffe, dass sich dieser Trend mit den Web-basierten Betriebssystemen durchsetzt. Aber derzeit braucht es hier noch einen Workaround bzw. extra Client für die Nutzer, damit Buzz beliebter wird.
Dann sind da noch die Kommentare. Beim Markus Angermeier ging in einem Buzz vorhin doch eine krasse Party ab, mit vielen Kommentaren. Da kann (oder muss) man dann einfach auf "Mute" drücken, damit sich der Information-Overflow in Grenzen hält. Daran muss man sich erst einmal gewöhnen, aber hier kommen wir zum nächsten Punkt: Buzz ist nicht Twitter. Man kann nicht wie auf Twitter einfach erstmal jedem folgen und hoffen, dass diejenigen nichts schreiben. Wenn jemand zu viel "Mist" buzzt, wird er halt entfolgt oder alle Buzzes nach dem Posten direkt ge-mute-d. Aber hier werden sich die User schon einen Workflow überlegen.
Was nur gar nicht funktioniert: Buzz direkt nach dem ersten Login verfluchen ist wie einen Menschen im Vorbeigehen komplett beurteilen zu wollen. In ein Auto kann man auch beim ersten Mal nicht einsteigen und direkt damit fahren. Man muss sich erstmal damit beschäftigen und, leider kommt der Mensch hier nicht drumherum, vergleichen ist auch eine schlechte Idee. Ich habe heute schon zu oft Dinge lesen müssen, dass Leute meinte, dass es kein Twitter oder kein Facebook sei, oder ZU Facebook sei. Aber wie auch bei anderen Diensten gilt: Es gibt immer einen Anwendungsfall. Wenn Ihr nicht dieser Fall seid, lasst es sein.
Was ihr aber nicht tun solltet: Einloggen - Rummeckern - Ausloggen - Losbashen
Besser: Einen halben Tag damit beschäftigen. Wenn es euch immer noch nicht gefällt, könnt ihr gerne meckern oder die Kritik direkt an Google leiten, denn ihr werdet nicht gehört, wenn ihr in die Menge brüllt, sondern nur, wenn ihr in den Dialog tretet.
Wenn dieser Beitrag etwas wirr aussieht: Hach ja, mein Kopf ist halt nicht immer komplett aufgeräumt. ;-)
