Maexotic

Kürzlich bin ich bei einer Recherche über radabg.com / SiteAnalytics360 gestolpert. Die in Kiev (UA) beheimatete Firma schreibt über sich selbst:

The easiest way to learn more about safety of websites
Radabg.com offers free Security Advisory Widget. Widget tells visitors when website is safe and when it's not. If webmaster submit website sitemap widget will also check safety of outgoing links (especially usefull for websites with user generated content (UGC) - forums, blog comments, etc.)

Alexa sagt über radabg.com:

Radabg.com is ranked #23,825 in the world according to the three-month Alexa traffic rankings. [...]

Das "Widget" ist natürlich wieder eines dieser unsäglichen Bilder, die man von der Site einbindet - zumindest kein Javascript.

Die Adressen der Bilder haben alle die Form
http://www.radabg.com/url/<host_domainname>/
also habe ich ein paar Sites ausprobiert um zu sehen, was der jeweilige Status ist. Und dann wurde es etwas skuril.

Das Erste, was mir aufgefallen war ist, dass alle Bilder den gleichen Zeitstempel tragen. In den Bildern steht neben dem Namen der Website "Last check: datum, uhrzeit" und diese Zeitangabe war für alle gleich. Ok, dachte ich mir, sie sammeln die Infos und dann gibt es einen job, der die Bilder anhand der gesammelten Daten rendert und da schreiben sie eben überall den gleichen Zeitstempel rein. Das ist natürlich sehr unsauber, weil niemand weiß, wann der letzte Check wirklich war. Zudem fehlt jegliche Angabe einer Zeitzone. Diese beiden Punkte machen die Zeitangabe komplett wertlos.

Bei weiterem rumprobieren bin ich dann auf eine Website einer Bekannten gestossen (siehe Bild rechts). Wie man sehen kann, haben sie diese Website (für meine Zeitzone ca. 2 Stunden) in der Zukunft überprüft und für vollkommen sicher befunden. Das eigentlich Tragische daran ist aber, dass es diese Website gar nicht (und zwar Wochen und Monate nicht mehr) gibt. Das hindert aber SiteAnalytics360 nicht daran, sie regelmäßig zu überprüfen und für sicher zu befinden.

Die Bewertung, was so eine Security Analysis und das zugehörige Site Seal wert sind, dürfte nun jeder selbst vornehmen können.

Doch das Problem ist viel breiter aufgehängt:

Site Seals

Soweit ich mich erinnere, haben die SSL-Zertifikatsverkäufer mit diesen sogenannten site seals angefangen. Die Anbieter verschaukeln damit ihre Kunden, indem sie ihnen suggerieren, dass damit die Website des Kunden "vertrauenswürdiger" wird. In Wahrheit ist es aber nur eine Marketingaktion, um kostenlos Werbung für ihren Firmennamen auf Websites von Kunden zu bekommen.

Eine Anfrage bei der Suchmaschine der Wahl fördert dann auch schnell eine (abgekürzte) Liste zu Tage:

Thawte:

Das thawte Siegel für vertrauenswürdige Websites ist ein dynamisches, auf Ihrer Website erscheinendes Bild, das Besuchern auf den ersten Blick zeigt, dass Ihre Website vertrauenswürdig ist, validiert ist und mit Ihnen absolut sichere Transaktionen möglich sind.

DigiCert:

DigiCert® SSL Site Seal Means TRUST

GeoTrust:

Ein sichtbares Zeichen von Sicherheit

RapidSSL:

Display your "Secured by RapidSSL" site seal prominently to ensure your customers are instantly assured that their details will be secured by the SSL provided by your RapidSSL certificate.

InstantSSL:

Promoting your secure site is the ideal way to help customers feel safe and confident in using your secure online services.

und viele mehr ...

Warum das so ist erklärt keiner der Anbieter. Außer Marketinggefasel findet sich dazu nichts substanzielles, und das hat auch seinen Grund: Solange diese Siegel nicht vom Browser selbst kommen sind sie vollkommen wertlos.
Dabei hat jeder Browser solche "Siegel". Als Beispiel liefert der Mozilla Firefox bei einem Klick auf den grün (starkes Zertifikat) oder blau (schwaches Zertifikat) hinterlegten Zertifikatsnamen in der Adreßleiste:

Natürlich hat jeder Zertifikatsverkäufer in irgendwelchen Klauseln stehen, dass man das Site Seal nicht mißbräuchlich verwenden darf, aber:

• wer von denen, die extrem anfällig für solche Angriffe sind, weil sie keine Ahnung haben, klickt schon auf das Siegel und vor allem, wer von denen kann dann bewerten, was er an Information erhält?
• wann haben solche Einschränkungen Kriminelle jemals abgehalten?

Was also passiert ist genau das Gegenteil von dem, was die SSL-Zertifikatsverkäufer suggerieren wollen:

Durch die Site Seals werden die Besucher in eine trügerische Sicherheit gewiegt. Sie werden davon abgehalten sich selbst anhand der Informationen, die ihnen ihr Browser liefert, ein reales Bild zu machen und im Zweifelsfall wird der Benutzer einem gefälschten Site Seal mehr Glauben schenken als der Warnung seines Browsers.

Hört also bitte - sowohl SSL-Zertifikatsverkäufer als auch Website-Betreiber - mit diesem Blödsinn auf.

★ Einmal mit Profis! ★

Das offizielle Google-Blog hat letzte Woche unter dem Titel "Search more securely with encrypted Google web search" angekündigt, dass man ab sofort "sicher" bei Google (vorerst allerdings nur google.com) suchen kann. Google unterstützt nun Suchanfragen über SSL, also mit https:// vorne dran: Google Suche via SSL.

Für die Anwender hat das drei direkte Auswirkungen:

• die Suchanfrage wird über eine verschlüsselte Verbindung übertragen und kann von Dritten nicht nur schwer mitgelesen werden. Die verwendeten Suchbegriffe bleiben damit quasi eine Sache zwischen dem Benutzer und Google.
• es geht ein ganz kleines bisschen langsamer. Zuerst muss eine Verschlüsselung zwischen Browser und Server ausgehandelt werden und danach werden die Daten verschlüsselt und übertragen und das braucht Zeit.
• da Dienste wie die Bildersuche, Maps und andere noch kein SSL unterstützen, gibt es momentan dazu auch keine Links auf den Ergebnisseiten.

Bye bye Suchbegriffe im Referrer

Ein weitere Auswirkung, die die Privatsphäre des Benutzers schützt, ist jedoch den Anbietern und hier vor allem den SEO-Leuten ein riesengrosser Dorn im Auge:

Klickt ein Benutzer auf einen Link und ruft damit eine neue Seite auf, so überträgt der Browser beim Abruf der neuen Seite, die Adresse (URL) der Seite, von der der Benutzer kommt. Dies ist der sogenannte Referrer. Kommt nun der Benutzer über eine Google Suche, sieht dieser Referrer zB. so aus:

http://www.google.de/search?q=telefonabzocke+gewinn+sofort

Der Anbieter der Seite kann also sehen, aufgrund welcher Suchbegriffe die Benutzer auf seinen Seiten landen und anhand dieser Informationen kann er (oder die SEO-Leute) versuchen die Seite zu optimieren, so dass noch mehr Leute durch eine Suche bei Google (oder anderen Suchmaschinen) auf der Seite landen.

Ärgerlich für die SEO-Leute ist nun, dass aus Sicherheitsgründen die Browser bei einem Wechsel von einer Seite über SSL auf eine ohne SSL keine Referrer-Information mitschicken. Das bedeutet, dass bei einer Suche bei Google über SSL und einem Klick auf ein Suchergebnis, das Ergebnis nicht mehr erfährt, welche Suchbegriffe verwendet wurden.

Gut für die Privatsphäre der Nutzer, blöd für die Seitenbetreiber, die natürlich auch prompt schon dicke Krokodilstränen vergiessen.

Noch ein paar erklärende Details

SSL Verschlüsselung:

Bei einer https-Verbindung handelt es sich um eine Ende-zu-Ende Verschlüsselung. Der Browser und der in der URL genannte Server handeln zuerst eine verschlüsselte Verbindung aus. Über diese läuft anschliessend die gesamte Kommunikation, also auch das Absenden der eigentlichen (Such-)Anfrage und die Antwort. Damit wird auch der URL nicht im Klartext übermittelt.

Click Tracking

Auch wenn der Betreiber der in den Sucherergebnissen angeklickten Seite keinen Referrer mehr sieht und damit keinen Hinweis auf die Suchbegriffe hat oder gar woher der Benutzer kommt, so weiss Google das natürlich immer noch!
Google verwendet Cookies, sieht die Suchbegriffe und verwendet teilweise Javascript, das ausgeführt wird, wenn ein Link in der Ergebnisliste angeklickt wird. Google weiss also trotzdem noch soviel wie vorher.
Verschwörungstheoretiker mutmassen, dass Google das nützen könnte, um seinen eigenen Analysedienst zu fördern.

Kontrolle im Browser

Im Mozilla Firefox kann man das Senden von Referrer-Information ganz leicht unterbinden. In der URL-Zeile about:config aufrufen und dann nach network.http.sendRefererHeader suchen. Der voreingestellte Wert ist 2. Dies bedeutet, dass Referrer-Information sowohl durch einen Klick auf einen Link, als auch für alle Elemente einer Seite gesendet werden. Setzt man den Wert auf 0, wird gar keine Referrer-Information mehr gesendet, setzt man den Wert auf 1 wird nur beim Klick auf einen Link, jedoch nicht für die Elemente einer Seite der Referrer mitgeschickt.
Ist der Wert 1 oder 2 wird für SSL-Zugriffe die Variable network.http.sendSecureXSiteReferrer konsultiert. Der voreingestellte Wert true bedeutet, dass bei einem Wechsel von einer https-Webseite zu einer anderen https-Webseite der Referrer mitgeschickt wird. Setzt man den Wert auf false wird dies unterbunden.
Da nicht auszuschliessen ist, dass manche Sites in einem Anflug von fehlgeleiteter (weil sinnloser) Sicherheitsprüfung einen Referrer haben wollen, sei der Vollständigkeit halber auf das AddOn RefControl verwiesen, das eine feinere Einstellung als generelles an/aus erlaubt.

"Datenschutz" ist wieder in aller Munde. Ein böser "Hacker" hat einmal mehr Daten von StudiVZ "geklaut". Na ja, nicht wirklich, er hat nur automatisiert die Daten der Benutzer abgegriffen, die diese bereit waren ihm, einem Mitglied von StudiVZ, zu geben. Getan hat er das mit einem sogenannten Crawler, also einem Programm, das sich von Webseite zu Webseite hangelt, so wie zB. Suchmaschinen das auch tun.

Es gibt eine ganze Reihe von sogenannten Personensuchmaschinen, die machen nichts anderes. Sie haben einen Crawler, der Webseiten abruft und sie haben ein data mining Programm, das diese Seiten analysiert, versucht Personeninformationen zu finden und zu extrahieren und danach werden diese Informationen - mehr oder weniger intelligent - gruppiert. Dies passiert mit den zusammengetragenen Benutzerdaten von tausenden von Webseiten. Manche dieser Suchmaschinen bieten ihre Daten öffentlich an (yasni.de, 123people, myONID.de, wink.com, spock.com), andere verkaufen diese Information für viel Geld an Personalabteilungen, die so ihre Bewerber abklopfen.

"Normale" Suchmaschinen können das auch ... vielleicht sogar noch besser. Ein Beispiel dafür ist der Social Circle von Google. Dadurch, dass sich Menschen auf verschiedenen Plattformen (XING, Twitter, Facebook, FriendFeed usw.) vernetzen und diese Informationen teilweise öffentlich sind (Friends, Followers), können Suchmaschinen diese Beziehungsinformationen auswerten, Profile erstellen und Verknüpfungsgeflechte generieren. Anhand weiterer Daten (semantisch gekennzeichnete Verweise auf Homepage, Blog, XYZ-Profil) lassen sich derartige plattformübergreifenden Profile sehr gut befüllen und so ist es dann auch nicht verwunderlich, dass, wenn ich bei Google angemeldet bin und eine Suchanfrage mache, mir Google ganz nebenbei mitteilt, dass einer meiner "sozialen Kontakte" gerade einen neuen Artikel in seinem Blog veröffentlicht hat.

Dieses data mining ist nicht nur auf Personendaten beschränkt. Manche Firmen haben sich auf Urheberrechtsverletzungen spezialisiert (PicScout), andere überwachen Markennamen (Brandwatch). Allen gemein ist, sie scannen permanent das gesamte Internet (oder versuchen es zumindest) und generieren und speichern verschiedene Arten von Profilen.

Social Networks

Der Begriff "Social Networks", wie er im Deutschen gemeinhin verwendet wird, ist falsch. "Social Networking Sites" trifft es schon viel besser und macht den organisatorischen Bezug zu den Mailboxsystemen früherer Zeiten deutlich.

Bei einer Social Networking Site handelt es sich um ein mehr oder eher weniger abgeschlossenes System.

• mehr, weil man für manches Mitglied sein muß.
• weniger, weil die Geschlossenheit keine wirkliche ist, sondern primär der Authentifizierung der Benutzer und der Generierung neuer Mitglieder dient. Jeder kann Mitglied werden, somit ist die Geschlossenheit nur formal.

Die Vertraulichkeits-Voreinstellungen solcher Systeme sind natürlich immer systemfreundlich: das ganze Internet darf nicht, alle Benutzer des Systems dürfen schon. Klar, soll ja neue Mitglieder anlocken und intern so viel wie möglich bieten. Dass der vorgegaukelte Unterschied zwischen "alle im System" und "das ganze Internet" nur formal existiert (jeder kann Mitglied werden) und gar keinen wirklichen Sinn macht, ist ein Mißverständnis, das sich für viele Teilnehmer nicht oder nur sehr spät (zu spät?) auflöst. Die Voreinstellung sollte immer so eng wie möglich sein, damit der Benutzer bewusst Rechte einräumen muß, widerspricht so aber dem Vernetzungsgedanken.

Zudem sollten solche Systeme vom Benutzer frei konfigurierbare Zugriffsbeschränkungen implementieren. Daran scheitern schon sehr viele, die meist nur drei oder vier vordefinierte Gruppen anbieten. Ein weiteres Manko ist oft die Granularität zur Vergabe der Rechte. So kann man ein Bilderalbum (thematische Gruppierung von Bildern) zwar einer Rechtegruppe zuordnen, nicht aber die einzelnen Bilder darin (nocheinmal gesondert).
Warum man das will? Beispiel: Fete. Alle Bilder des Albums "Fete" sollen für Mitglieder der Gruppe "Fete" sichtbar sein, nicht jedoch das Bild "Joe peinlich", das nur für "Joe" sichtbar sein soll.

Ein weiteres Problem tritt mit obigem Beispiel ebenfalls zutage: alle müssen Mitglieder dieses Systems sein, da sonst das System sie nicht identifizieren und authentifizieren kann. Ein "Ich habe die Bilder der Fete unter dem URL ... abgelegt. Benutzername/Passwort zum Anschauen sind ..." funktioniert nicht. Fetenteilnehmer, die nicht im System registriert sind können die Bilder nicht ansehen.

Dies führt direkt zu einem weiteren Problem dieser Systeme und der Vertraulichkeit von Daten.

Vertrauen

Daten sind immer nur so vertraulich, wie man der Person/Organisation vertrauen kann, an die man sie weitergibt.

Was nützt es Daten in einem geschlossenen und geschütztem System zu haben, wenn die Personen, die Zugriff darauf haben, (absichtlich oder nicht absichtlich) nicht vertrauenswürdig sind.

• bei "absichtlich nicht vertrauenswürdig" sollte klar sein, was es bedeutet.
• bei "unabsichtlich nicht vertrauenswürdig" besteht vielleicht Erklärungsbedarf.
  Betrachtet man obiges Besipiel der Fotos des Festes wird auffallen, dass es ziemlich unwahrscheinlich ist, dass alle Teilnehmer der Fete auch Mitglieder des Systems sind, in welchem die Fotos veröffentlicht wurden. Dies führt dann zu dem Fall, in dem ein Mitglied mit Zugriff darauf diese Fotos aus dem System "entfernt" und einem Fetenteilnehmer, der kein Mitglied ist, zB. per E-Mail zuschickt. Dem Mitglied wird in diesem Moment sicher nicht klar, dass er einen Vertrauensmißbrauch begeht, denn "die Fotos waren doch für die Teilnehmer der Fete".
  Diese Annahme ist aber falsch, denn es war für "die Teilnehmer der Fete, die Mitglieder der Gruppe "Fete" des Benutzers des Systems sind, der die Bilder eingebracht hat". Eventuell hätte dieser ja das eine oder andere Bild nicht eingestellt, wenn die externe Person ebenfalls Mitglied gewesen wäre oder er hätte die Zugriffsberechtigungen (einiger Bilder) anders gesetzt.

Durch die Entnahme der Bilder aus dem Schutz des Systems wurde die Vertraulichkeit der Daten ausgehebelt.

Ein weitergehender Verlust der Vertraulichkeit der Daten erfolgt in dem Moment, in dem die externe Person diese per E-Mail erhaltenen Bilder an eigene Freunde weiterschickt, die vielleicht gar nicht auf der Fete waren: "das sind Bilder der tollen Fete, auf der ich am Wochenende war". Der Totalverlust tritt ein, wenn die Bilder ungeschützt in zB. einer Foto-Community veröffentlicht werden.

Kopieren verboten

Mit dem Slogan "Kopieren verboten" hat eine Firma auf einem Sicherheitskongress vor ein paar Jahren ihr Produkt angepriesen und wollte damit "die Vertraulichkeit Ihrer Dokumente schützen". Sie haben damals meinen Kommentar dazu "was ich sehe gehört mir" nicht verstanden. Das Produkt hat auf Betriebssystembasis verhindert, dass man zB. PDF-Dokumente kopieren kann und sollte damit eine Vertraulichkeit des Dokuments erreichen. Das ist aber zu kurz gedacht. Niemand hat verhindert, dass

• Screenshots von jeder Seite des Dokuments gemacht werden können
• das Dokument seitenweise vom Bildschirm abfotografiert werden kann
• das Dokument per Hand auf Papier übertragen werden kann
• und nicht zuletzt: der Inhalt des Dokuments mündlich weitergegeben werden kann

What has been seen cannot be unseen.

Ein weiteres Beispiel dafür, wie schnell man die Kontrolle über "vertrauliche Daten" verlieren kann, zeigt sich beim Sexting. Damit wird das "sex texting" erotischer Fotos vom eigenen Körper bezeichnet, aufgenommen mit der Fotofunktion des Mobiltelefons und anschließend per MMS direkt verschickt.
Mag das eine Laune gewesen, als anregende Unterstützung für Cyber-/Telefonsex gedacht oder auch nur ein Vertrauensbeweis gewesen sein, kann dies schnell aus dem Ruder laufen, wenn der Empfänger diese Bilder im (meist gleichgeschlechtlichen) Freundeskreis quasi als Trophäe präsentiert oder wenn nach dem Ende einer Beziehung der/die Verlassene glaubt sich rächen zu müssen, indem er/sie die Bilder veröffentlicht.

Tolle neue Social Networks

Nach all der Kritik an den bestehenden Social Networks hat vor allem diaspora* in den letzten Tagen den vollen Medienhype erlebt. Es ist nicht das einzige Projekt, das mit dem Anspruch an den Start geht mehr Datenschutz zu gewährleisten. Eine Liste solcher Projekte wird von der Free Software Foundation (FSF) als Gegenüberstellung verwaltet.

Ein paar der Systeme habe ich mir angeschaut. Ich brainstorme selbst seit etwa 3 Jahren an so einem System, denke also ich kann mir hierzu einen Kommentar erlauben . All diese Systeme verfehlen ihre Ziele. Es ist nicht die Herausforderung ein paar hundert oder tausend Zeilen in PHP runterzuhacken und man hat was Tolles.
Die Herausforderung ist ein prinzipielles System zu entwerfen

• das verteilt ist (gib' nicht einem Anbieter alle Deine Daten)
• das trotz der Verteilung auch bei Millionen von Benutzern noch skaliert
• das Sicherheit in Form von Identifizierung und Authentifizierung enthält ("signed messages")
• das ein Reputationssystem (ala "web of trust") integriert
• das eine "Schaltzentrale" bietet, auf die man von überall her (steuernd) zugreifen kann und alle Funktionalität, die man haben will, integrieren kann (soetwas wie IMAP4 für E-Mails, das aber E-Mails, Microblogging, Bookmarks, Chat, RSS/ATOM Feeds, Blogs, Bilderalben und und und ... integriert; raindrop aus den Mozilla Labs ist schon einmal ein Stück in die richtige Richtung)
• das problemlos erweiterbar und integrierbar ist
• das plattformunabhängig ist

So ein verteiltes System muß also primär Schemata, Protokolle und Abläufe definieren, so dass die verschiedenen Knoten sauber und effizient interagieren können. Dies ist die Herausforderung - danach den Code (egal in welcher Sprache oder welchem Framework) runterzuhacken ist es nicht. Sicher kann man dazu auf bereits bestehende Dinge zurückgreifen, wie OpenID, OAuth, pubsub, ... integrieren muß man es trotzdem sauber und vieles von Grund auf neu machen.

Eingangs beschriebene Probleme mit der Vertraulichkeit oder dem Schutz der Daten werden aber auch diese Systeme alle nicht lösen, weil diese Probleme weder systemimmanent sind noch programmatisch gelöst werden können.

So, we're doomed

You can't take something off the Internet, that's like trying to take pee out of a swimming pool.
Once it's in there, it's in there.
-- NewsRadio clip, episode 2x17 "Physical Graffiti" [via YouTube]

Nein, bei weitem nicht!

So wie vor zehn oder zwanzig Jahren die wenigsten von uns damals darüber nachgedacht haben dürften, dass Artikel, die sie im USENET veröffentlicht haben und die regelmässig auf den lokalen Newsservern expired und damit veschwunden waren, plötzlich wieder auftauchen und durchsuchbar sind, so waren und sind viele im Moment noch etwas leichtsinnig, was ihren digitalen Footprint angeht. Da sowohl Soziale Netzwerke als auch für viele das Internet und nicht nur das Konsumieren in Form von Surfen, sondern gerade auch das Publizieren Neuland ist, ist dies auch keineswegs verwunderlich.

Das sind Schäden, die nicht wieder gutzumachen sind, aber solange wir alle aus diesen Schäden lernen und ein entsprechendes Bewusstsein entsteht, das anderen Neulingen hilft, diese Fehler erst gar nicht zu begehen, denke ich, ist nicht alles verloren.

Man muß sich jedoch immer vor Augen halten:

Das Internet vergisst nichts!

... und Aussagen wie "The photograph has now been removed from the internet" sind und bleiben nichts als fromme Wünsche von Leuten ohne Realitätsbewusstsein.

... get on my nerves for quite some time.

As far as I could find out they are used by Google Analytics and represent "The five dimensions of campaign tracking" (Source, Medium, Term, Content, Campaign).

As I have written in prior posts, I am not too fond of being tracked, so I wrote this little python snippet, to delete these information from URLs. I use it in a few of my gateway programs and it can be used eg. in an URL filter for the squid proxy (see redirect_program directive).

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import re

UTM_TAGS = (
    u'utm_source',
    u'utm_medium',
    u'utm_term',
    u'utm_content',
    u'utm_campaign'
    )

utm_re = list()
for ut in UTM_TAGS:
    # unescaped form: &utm_name=value
    utm_re.append(re.compile(u"([?&]"+ut+u"=[^&]*)"))
    # escaped form: &utm_name=value
    utm_re.append(re.compile(u"(&"+ut+u"=[^&]*)"))

def unUTM(url):
    # check if the URL is parameterized
    if 0 <= url.find("?"):
        # double the parameter delimiter, so we won't lose it
        url = url.replace("?", "??")
        for p in utm_re:
            url = p.sub(u"", url)
        # clean up leftover mess
        url = url.replace("??","?").replace("?&", "?").strip("?")
    return(url)

Trying to incorporate BlackJack's comments led me to the following code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import re

UTM_TAGS = (
    u'utm_source',
    u'utm_medium',
    u'utm_term',
    u'utm_content',
    u'utm_campaign'
    )

utm_re = re.compile(u''.join((
    u'(^|&(amp;)?)(',      # either at start or preceeded by '&' or '&'
    u'|'.join(UTM_TAGS),   # all tags as alternatives
    u'=)[^&]*'             # followed by '=' and all chars upto next '&'
    )))

def unUTM(url):
    # check if the URL is parameterized
    if '?' in url:
        (url, params) = url.split('?', 1)
        params = utm_re.sub(u'', params)
        if '' != params:
            params = re.compile(u'^&(amp;)?').sub(u'', params)
            url = u'?'.join((url, params))
    return(url)

Armin 'argv[0]' Gruner has probably the most elegant solution that doesn't even use regex:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from urlparse import parse_qs, urlsplit, urlunsplit
from urllib import urlencode
from cgi import escape

def unUTM(url):
    res = urlsplit(url)
    if not res.query:
        return url
    qdict = parse_qs(res.query)
    map(lambda key: qdict.pop(key), filter(lambda key: key.startswith('utm_'), qdict.keys()))
    res = list(res))
    res[3] = escape(urlencode(qdict, doseq=1))
    return urlunsplit(res)

Bild aus Die Siedler - WebKit © Ubisoft.

Die letzte Version von "Die Siedler", die ich gespielt habe, ist Die Siedler II. Durch den IGN.com Artikel The Settlers 7 Hands-on - Dominate your enemies and raise a kingdom habe ich festgestellt, dass sich in dieser Serie von Blue Byte seit dieser Zeit grafisch und strategiemässig einiges getan hat.

Leider hat sich aber Ubisoft entschlossen über das Spiel und den Spieler die totale Kontrolle ausüben zu wollen. Deshalb wurde das Spiel mit einem DRM-Schutz versehen, der das Spielen nur erlaubt, wenn der Spieler online ist. Einige Fragen diesbezüglich beantwortet die Online Services Platform Q&A von Ubisoft UK. Demzufolge muß man sich

• Online registrieren, um das Spiel spielen zu können
• während des Spielens permanent online sein
• Unterbrechung der Online-Verbindung führt zu einer Unterbrechung des Spiels
• Spieldaten werden online und offline gespeichert

Ubisoft führt als großen Vorteil an, dass man dafür das Spiel auf beliebig vielen PCs und beliebig of installieren darf/kann. Über die Seriennummer des Spiels in Verbindung mit dem persönlichen Account wird der Spieler authentifiziert und weil der Spielstand online gespeichert wird, kann (muss?) man - ohne vorher die PCs synchronisieren zu müssen - mit dem aktuellen Spielstand weiterspielen. Die Installations-CD/DVD ist zum Spielen nicht erforderlich.

Die gravierenden Nachteile sind aber:

• ohne Internetverbindung kann man das Spiel nicht spielen
• ist das DSL weg, kann man das Spiel nicht spielen
• ist man unterwegs und hat kein mobiles Internet, kann man das Spiel nicht spielen
• sind die Server von Ubisoft weg, kann man das Spiel nicht spielen
• da die Seriennummer an den Benutzer-Account gekoppelt ist, kann man das Spiel nicht weiterverkaufen
• beschliesst Ubisoft, dass die Leute jetzt gefälligst "Die Siedler 8" spielen sollen und schaltet die Server ab, kann man das Spiel nicht mehr spielen
• Ubisoft weiß immer genau, wie oft, zu welchen Zeiten, wie lange und von welchen Rechnern aus die Leute spielen. Überwachung total.
• das Speichern der Spielstände online dient natürlich nur einem Zweck: wenn zwei Mitglieder der Familie das Spiel auf verschiedenen PCs spielen wollen und jeder will seinen eigenen Spielstand, dann sollen sie auch zwei Spiele kaufen und sich zweimal registrieren.

Damit hätte Ubisoft endlich das erreicht, was die Spieleindustrie schon lange wollte: totale Kontrolle über das Produkt und den Käufer. Was den Spieleherstellern ja schon lange eine Dorn im Auge ist, dass man das Spiel einmal durchspielt und dann weiterverkauft - ohne dass der Hersteller daran nochmals verdient - hat sich damit auch erledigt.
Kann noch jemand außer mir die € und $ in ihren Augen glänzen sehen? Zumindest tun sie das noch.

Offensichtlich hat Ubisoft nichts aus dem Spore-Disaster gelernt, das Electronic Arts 2008 einstecken musste. Nachdem bekannt wurde, dass das Spiel mit dem SecuROM DRM geschützt sein würde, brachen die Verkäufe des wohl meist erwarteten Spiels für 2008 ein, Vorbestellungen wurden storniert. Die Welle der negativen Bewertungen für Spore bei Amazon, rein basierend auf der Verwendung des SecuROM DRM, taten ihr Übriges. Dafür war die gecrackte Version ohne DRM der totale Renner bei den Bittorrents. In nur einem Monat schaffte es 500000 Downloads, ein bisher für ein Spiel nie erreichtes Ergebnis. Dies schlug solche Wellen, dass sogar Forbes unter dem Titel "Spore's Piracy Problem" einen Artikel darüber brachte.

Durch die DRM Politik und die Verwendung von SecuROM, das einen extrem schlechten Ruf hat und das Verhalten von Spyware an den Tag legt, hat sich EA massivst selbst geschadet. Statt dass es die Spieler gezwungen hätte das Spiel zu kaufen, wurde es zum am meisten piratisierten Spiel aller Zeiten und das DRM wurde als Legitimisierung für die illegalen Downloads angesehen. Dazu kommt, dass die Spieler einer legalen Kopie des Spieles viel mehr Probleme mit dem Spiel aufgrund des DRM hatten, als die Spieler der gecrackten, DRM-freien Version. Damit hat EA zudem auch noch die Käufer bestraft.

Wann werden die Hersteller endlich verstehen, dass je weniger man die Konsumenten gängelt, desto kaufwilliger sind sie. DRM trägt dazu nicht bei.

Am 27. Januar 2010 hat Apple das iPad angekündigt. Die Werbe- und Hype-Maschinerie des Internet hat ihr Übriges dazu getan, dass aus dem iPad statt eines "IDontCare" ein "IMustHave" wurde.

Aber das Internet wäre nicht was es ist, wenn nicht sofort auch Spammer und andere zwielichtige Gestalten auf den Hype-Train aufspringen und versuchen würden, daraus Kapital zu schlagen.

Auf Facebook hat eine Webpage-Fanseite mit Namen "Apple iPad Giveaway – Be The First To Get One!" aktuell bisher 92,342 Fans angezogen (die Zahl im Bild rechts ist von vorgestern). Das muss man sich einmal vorstellen: 100000 Leute fallen auf solch dreiste Abzocke herein und bekennen sich auch noch dazu.
Facebook ist für derartige Angebote perfekt geeignet, da jedesmal, wenn ein Benutzer ein "Fan" wird (darum ist das auch eine Bedingung), alle seine Freunde darüber informiert werden. Dies sorgt dafür, dass sich das Angebot ganz schnell durch einen Schneeballeffekt selbst bekannt macht.

Aber wenn sie doch das iPad kriegen? Das ist in der Tat nicht einmal ausgeschlossen. Der Preis dafür wird aber wahrscheinlich den Preis des iPad um einiges übertreffen.

Wie funktioniert das?

Das System dahinter nennt sich auf neudeutsch Affiliate, was die Bedeutung von Partner oder Zweigstelle hat. Neben einigen seriösen Affiliate-Programmen großer Firmen, gibt es auch jede Menge, die an der Grenze der Legalität oder zumindest des Anstandes arbeiten.

Manche dieser Affiliate-Programme ersetzen im Internet die Drückerkolonnen von früher. Gelangt man auf so eine Webseite, ist man - ohne entsprechende Einstellungen oder Add-Ons im Browser - erst einmal in einer endlosen Reihe von immer neuen Webseiten gefangen, die alle die E-Mail-Adresse oder sogar reale Post-Adreßdaten abfragen. Natürlich muss man überall sein Einverständnis erteilen, dass man kontaktiert werden darf. Das Ergebnis sind dann Unmengen von Spam. Aber was tut man nicht alles für ein kostenloses iPad. Der Affiliate freut sich über ein paar Cent, jedesmal wenn ein Partner die E-Mail-Adresse bekommen hat.

Neben den reinen Spammern gibt es die Probeabos. Man willigt in Probeabos ein, die man sicher nicht möchte, aber es sind ja nur Probeabos. Wie so oft, verlängern diese sich allerdings automatisch in kostenpflichtige Abos mit langer Laufzeit, wenn man nicht rechtzeitig kündigt. Nicht jeder tut das und nicht mit allen Abos und schon hat die Firma gewonnen. Nicht zu vergessen, dass für den Affiliate immer ein paar Cents oder sogar Euros abfallen.

Und dann gibt es noch die Super-Sonderangebote. Ähnliche Angebote kennt man auch bei uns aus dem Werbefernsehen. Meist werden Mobiltelefone, Fernseher und Spielekonsolen "verschenkt", wenn man einen (überteuerten) Mobilfunkvertrag mit einer Laufzeit von 24 Monaten abschliesst. Und hier sind wir dann endlich am Ziel. Das iPad erhält man, wenn man sich zB. einen Plasmafernseher für € 2000 kauft, der mit guter Wahrscheinlichkeit einen Wert/Ladenpreis von € 1000 hat .

Ist man also letztendlich bei seinem "kostenlosen" iPad angelangt, hat man auf dem Weg dahin bereits einen viel zu hohen Preis dafür bezahlt.

Und der Affiliate? Wenn jeder der 100000 Fans oben mitgespielt hat, und er für jeden nur 1 Euro erhalten hat, kann sich jeder selbst ausrechnen, dass das ein ganz passabler Verdienst ist dafür, dass die Website gerade mal 2 Wochen existiert, er so gut wie keine Arbeit und auch keinen Aufwand damit hat.
Und wenn es nur 10% waren ... ist das immer noch eine nette Summe.

Meine E-Mails lese ich im mutt. Ab und zu erhalte ich aber eine E-Mail von Firmen in HTML (*seufz*), die schiebe ich dann in eine IMAP-Mailbox und lese sie mit Thunderbird. Außerdem verwende ich den Thunderbird als RSS / ATOM Feedreader.

Javascript abschalten

Was mir schon in den Release Candidates sauer aufgestossen ist, und sich in der finalen Version nicht geändert hat, ist die Tatsache, dass es im Gegensatz zu den 2er Versionen nicht mehr möglich ist über die Benutzereinstellungen Javascript abzuschalten. Leider gibt es für den Thunderbird bisher auch kein NoScript Add-On, wie für den Firefox. Da braucht es dann etwas fortgeschrittenere Magie (was für Joe User wahrscheinlich eine ziemlich hohe Hürde darstellt), denn man kann Javascript natürlich immer noch abschalten.

1. Zuerst muß man in den Config-Editor:
   Diesen erreicht man in der Menüleiste über:
   Extras > Einstellungen > Erweitert > Allgemein
   oder - je nach Version - auch über
   Bearbeiten > Einstellungen > Erweitert > Allgemein
   Dort findet sich die (im Bild rot markierte) Schaltfläche "Konfiguration bearbeiten", die man Anklicken muss.
   
2. Als nächstes erscheint ein neues Fenster und eine Warnung. Man soll bestätigen, dass man vorsichtig ist. Das geht klar.
3. Nun ist man im eigentlichen Konfigurationseditor. Oben im Fenster ist eine Eingabezeile, mit der man die Option filtern kann. Hier bitte "javascript" eintragen.
4. Dies reduziert die Anzahl der Optionen auf ein paar wenige.
   
   Die, die interessant sind, sind:

   Einstellungsname	Status	Typ	Wert
   javascript.allow.mailnews	Standard	boolean	false
   javascript.enabled	Standard	boolean	true

5. Die erste der beiden Zeilen ist leider irreführend. Der Eintrag javascript.allow.mailnews ist noch vorhanden, er wird aber von Thunderbird nicht mehr verwendet. In Thunderbird 3 ist Javascript für Mails ausgeschaltet und kann auch nicht aktiviert werden.
6. Für RSS/ATOM ist aber Javascript noch angeschaltet. Durch einen Doppelklick auf die Zeile mit javascript.enabled wird der Boole'sche Wert von true auf false umgestellt. Das Ziel ist erreicht (siehe Bild oben).
7. Als Zeichen dafür, dass der Wert vom Benutzer modifiziert wurde, wird die Zeile jetzt in Fettschrift dargestellt.

   Einstellungsname	Status	Typ	Wert
   javascript.enabled	vom Benutzer festgelegt	boolean	false

DNS-Prefetching abschalten

Wenn wir schon im Config-Editor sind, können wir auch gleich noch eine weitere Schwachstelle beseitigen. Mike Cardwell beschreibt in seinem Artikel "Prefetch Exposure on Thunderbird and Webmail" ein Angriffsszenario, das sowohl Thunderbird beim E-Mail-Abruf, als auch Firefox (ab Version 3.5) beim Zugriff auf Webmail-Systeme betrifft. DNS-Prefetching ist ein weiteres Beispiel dafür wie die Prefetching-Manie der Mozilla-Entwickler die Programme schwächt, nur um im Gegenzug ein paar Millisekunden Performance herauszuholen.

[Nachtrag] Was bedeutet DNS-Prefetching in diesem Zusammenhang? Der Browser anaylisert die geladene Seite und falls er Hyperlinks findet, führt er die entsprechenden DNS-Anfragen schon proaktiv aus, was er ohne Prefetching erst machen würde, wenn der Benutzer auf den Link klickt. Mozilla argumentiert damit, dass dies in mobilen Netzwerken zu einem starken Preformancegewinn führen würde und außerdem macht es Google Chrome auch. Dass beide Browser kein Prefetching für Hyperlinks in Seiten machen, die per HTTPS abgerufen wurden zeigt, dass den Entwicklern schon klar ist, was sie da eigentlich anstellen.
Durchaus sinnvoll wäre das in "DNS Prefetching for Firefox" beschriebende Vorgehen für Elemente, die zum Aufbau der Seite sowieso geladen würden. Dass Firefox das nicht tut ist ganz klar ein Designfehler und dass sie dieses Problem beheben ist mehr als wünschenwert. Dass sie es aber mit DNS-Abfragen für Hyperlinks mischen und dass man durch Abschalten von Letzterem auch die Behebung des Fehlers abschaltet, ist nicht akzeptabel

Zum Abschalten des DNS-Prefetching muss im Thunderbird und Firefox eine Konfigurationsoption hinzugefügt werden:

1. Mit der rechte Maustaste in das Fenster des Config-Editors klicken.
2. In dem daraufhin erscheinenden Popup-Fenster geht man auf
   Neu > Boolean
3. Nun wird man aufgefordert einen Namen für die Eigenschaft einzugeben:
   network.dns.disablePrefetch

4. Als nächstes muss man den Wert für die Eigenschaft setzen. true und false werden zur Auswahl angeboten. Da das Prefetching abgeschaltet werden soll, wählen wir
   true
5. Es sollte nun folgende Zeile angezeigt werden:

   Einstellungsname	Status	Typ	Wert
   network.dns.disablePrefetch	vom Benutzer festgelegt	boolean	true

   (falls nicht, in der Filter-Eingabezeile "javascript" löschen und ggfs. durch "prefetch" ersetzen)
   

Damit ist das DNS-Prefetching abgeschaltet. Wie man im Bild sehen kann, habe ich auch die Option für network.prefetch-next abgeschaltet. Ist diese Option angeschaltet, können Webseiten den Browser anweisen, dass er bestimmte Daten schon im Hintergrund lädt (zB. Bilder, oder weitere Webseiten). Das ist gut gemeint, ermöglicht aber dem Benutzer Daten unterzuschieben, die er vielleicht gar nicht will, also empfehle ich auch diese Option durch einen Doppelklick abzuschalten.

[Nachtrag] Dieses Prefetching wurde zB. von Google auf den Suchergebnisseiten verwendet. Google hat den Browser angewiesen die Links hinter den ersten fünf Treffern schon einmal proaktiv zu laden, damit, wenn der Benutzer sich entscheidet den Link anzuwählen, die Seite schneller lädt. Der negative Effekt ist, dass natürlich die Seitenbetreiber darüber informiert wurden (über den Referrer), nach welchen Suchbegriffen jemand gesucht hat, dass eine ihrer Seiten in den Top 5 Ergebnissen war und auch die IP-Adresse und Browserversion des Suchers, auch wenn dieser den Link nicht anklickt.
Natürlich gäbe es durchaus sinnvolle Anwendungen, etwa in Fotoalben, so dass das nächste Bild schon im Hintergrund geladen würde, während der Benutzer noch das aktuelle betrachtet. Vielleicht findet ja eine feinere Steuerung der Erlaubnis zum Prefetching, basierend auf zB. Host-/Domainnamen, einmal Einzug in das NoScript Add-On oder ein eigens dafür geschriebenes.

Die Fenster des Config-Editors und der Benutzereinstellungen können nun geschlossen werden.