qrios

tl;dr. Unterscheidet man den Nutzen von Cookies nach ihrer Funktion für User und der Funktion für Anbieter wird deutlich, dass Cookies der Lebenssaft der digitalen Branche sind. Für die User bieten sie aber nur marginale Vorteile. Die Branche wird nicht aufhören immer mehr Daten zu sammeln, bis eine lückenlose Vorratsdatenspeicherung über jeden Nutzer existiert.

Die Firma nugg.ad (Tochter der Deutschen Post DHL) ist einer der größten deutschen Trageting-Dienstleister und lebt davon, dass auf einer Seite Cookies von einer anderen Seite gesetzt und gelesen werden können. Ist diese Funktion ausgeschaltet kann nugg.ad kein Profil erstellen.

Http ist an sich zustandslos. Das meint, dass der Aufrufende (“gib mir folgende Datei”) vom Vorhaltenden (“hier hast du die Datei”) nicht erkannt werden kann. Ohne weiteres weiß er nicht, wer da grade dieses Bild will und in welchem Kontext er sich grade befindet. Und damit fängt das Dilemma an.

Prinzipiell gibt es unterschiedliche Interessen für die (Wieder)Erkennung von Nutzern. Im Folgenden werden zuerst die Interessen der Nutzer dargestellt und danach die der Anbieter. Aus der Gegenüberstellung wird deutlich, dass Cookies im Interesse, ja sogar die Basis vieler Business-Modelle der (meisten) Anbieter sind. Für die Nutzer sind sie jedoch in den meisten Fällen ein lässliches Ärgernis und oft auch die falsche Technik.

Die Nutzerinteressen

Aus Nutzersicht ist eine Request-übergreifende (“der User folgt einem internen Link”) oder eine Session-übergreifende (“der User kommt nochmals auf die Site”) Zuordnung zu unterscheiden. Die Wiedererkennung bietet erstens eine komfortable Anmeldung oder/und die Personalisierung von Inhalten oder Formaten.

Die automatische Anmeldung ist ohne Frage eine hilfreiche Funktion. Es gibt allerdings dafür http-Authentifizierung. Ein bestimmter Bereich verlangt eine Authentifizierung und ohne ein gültiges Login und Passwort sieht man nichts. Alle Browser verfügen über einen eingebauten Mechanismus, sich auf Wunsch diese Anmeldungen zu merken. Und über https gibt es auch die maximal derzeit verfügbare Sicherheit*. Cookies sind für diese Funktion absolut überflüssig.

Personalisierung bedeutet, dass der Nutzer bewusst oder unbewusst das Verhalten, respektive das Aussehen einer Seite oder einer Site verändert.

Beginnen wir mit dem bewussten Verhalten. Sitebetreiber finden es manchmal eine gute Idee: der Nutzer habe doch bestimmt seine eigenen Präferenzen und möchte sich die Seite einrichten nach seinem Gusto. Deutlich zu sehen bei der DRadio-Wissen-Seite oder bei der letzten Version von Xing. Man kann Inhaltsboxen hin und her schieben und sich damit die “Startseite” anpassen. Diese Einstellung wäre natürlich sinnlos, wenn man beim nächsten Aufruf alles wiederholen müsste. (Nun finden lustigerweise wenig ausgewiesene Experten Personalisierung toll. Prominentes Beispiel war hier Bertelsmann mit Bol. Die hatten in New York am Time Square mal 50 Datenbankenexperten sitzen, die sich mit dem Speichern von User-Preferenzen beschäftigen sollten. Bol hat es bekanntermaßen nicht weit geschafft.)

Aber auch das unbewusste Verhalten eines Nutzers kann Einfluss auf das Aussehen und den Inhalt einer Seite haben. Allein durch die aufeinanderfolgenden Klicks oder durch Aktionen in der Vergangenheit könnte ein Nutzer vermitteln, was er eigentlich sucht und was man ihm daher anbieten soll. Dieses Verfahren wird Behavioral Targeting genannt. Prominentestes Beispiel ist Amazon mit der Liste ähnlicher Produkte. Diese Liste wird in Abhängigkeit von meinem bisherigen Verhalten momentan oder meiner Kaufhistorie variiert. Ein großer Teil von Amazons Erfolg geht auf diese Funktion zurück, die man sich damals bei der Firma Net Perceptions gekauft hat.

Innerhalb einer Session würde sowohl die Anpassung an das bewusste als auch an das unbewusste Verhalten mit Hilfe von Session-IDs funktionieren. Diese werden als Parameter über die URL von einer Seite zur nächsten übergeben**. Session-übergreifend funktioniert dieses Verfahren nicht, da nicht gewährleistet werden kann, dass die URL nach wie vor von dem ursprünglichen Browser aufgerufen wurde.

Die Personalisierung – egal ob auf der Basis von bewusstem oder unbewusstem Verhalten – ist jedoch generell problematisch. Heute nutzen die User Sites in verschiedenen Situationen. Auf der Arbeit mit dem Firmen-PC, auf dem Weg nach Hause mit dem Handy, zu Hause mit dem Tablet u.s.w. Eine Personalisierung könnte dann also nur funktionieren, wenn die Cookies mitgenommen würden. Das werden sie momentan*** nicht. Ausserdem sind die Geräte jeweils so unterschiedlich, dass die Webseiten sowieso verschieden aussehen.

Die Anbieterinteressen

Vor der Erfindung der Cookies stand die Frage von Henry Ford, welche Hälfte der Marketingausgaben denn wohl umsonst ist. Denn dass nicht jede Kommunikation bei den Empfängern auf fruchtbaren Boden fällt ist klar. Der Tampon-Spot im StarTrek-Werbeblock könnte vergebene Liebesmüh sein. Das Banner für das iX-Abo auf gofeminin scheint deplatziert.

Henry Ford würde heute feststellen, dass es doch am besten wäre, die Kommunikation für jeden einzelnen Empfänger anzupassen. Denn sicher gibt es für jeden einen bestimmten Schlüsselreiz, der ihn dazu bringt, sofort den Scheck zu unterschreiben. Was wie ein Horroszenario klingt ist nur das fertige Bild, wenn man heutige Puzzlesteine zusammensetzt.

Mit Hilfe von Cookies kann erkannt werden:

• ob ein Nutzer bereits auf der aktuellen Seite war,
• und wenn ja, was er sich angesehen hat,
• dort bereits etwas gekauft hat und wenn ja,
• was er dort gekauft hat,
• ob er irgendeine Werbung dieser Seite gesehen hat und wenn ja,
• welche Werbung dieser Site er gesehen hat und
• ob er diese geklickt hat,
• ob er (auf der Seite auf der diese Werbung ist) bisher überhaupt mal war,
• und wenn ja, welche Werbung er dort schon mal gesehen und
• möglicherweise geklickt hat,
• welche Themen er sich auf verschiedenen Seiten ansieht.

Etliche Szenarien sind nur möglich, wenn verschiedene Teilnehmer Daten austauschen. Dies geschieht schon länger. Deutlich wird, dass immer öfter Konkurrenten über ein Intermediate zusammenarbeiten. Der Vorteil der verbesserten Daten ist tatsächlich höher zu bewerten als die Tatsache, dass ein Wettbewerber Informationen erhält.

Dabei spielt es übrigens keine Rolle, ob die Daten personalisierbar sind. Im Gegenteil: personenbezogene Daten neigen zu Korrosion wenn Nutzer ihre Wohn- oder Mailadressen ändern, heiraten oder das Konto wechseln.

Cookies bieten damit ganz abstrakt die Möglichkeit einer vollständigen Vorratsdatenspeicherung aller Interaktionen eines Nutzers im Web. Und mit dieser Historie lassen sich komplette Persönlichkeitsprofile bilden, Verhaltensmuster in Cluster zusammenfassen. Basierend darauf können Kommunikationsmaßnahmen und -inhalte so gesteuert werden, dass die Response-Rate optimal ist. Also die Wirkung des Marketings nicht weiter verbessert werden kann. Dabei umfassen Kommunikationsmaßnahmen nicht nur Banner und TV-Spots.

Inhalt und Stil eines Zeitungsartikels kann genauso customized werden wie Produktname und vermeintlicher Hersteller. Es könnte ja sein, dass eine kleine Gruppe von Usern durchaus Nivea kaufen würde, wenn man sie nur in eine Steampunk-Packung füllt und sie nach Prinzessin Leia benennt. Der Makerbot im Netto um die Ecke macht es möglich.

Sicher eine lustige Vorstellung. Wenn es jedoch um Krankenversicherung, Job-Angebote, politische Meinungsäusserung und Reisefreiheit geht und damit letztlich um eine durchlässige Gesellschaft, dürfte vielen das Lachen im Halse steckenbleiben.

Und es bleibt festzustellen, dass existierende Daten immer Begehrlichkeiten wecken.

—

Über mich: In der c’t 6/96 erschien mein letzter Artikel für die Zeitschrift mit dem Titel “Faules Backwerk – Auf dem Weg zum gläsernen Web-Surfer” http://www.heise.de/ct/artikel/Faules-Backwerk-284550.html . Seitdem arbeite ich mehr oder weniger permanent als Experte für Web-Analyse. Meistens mit Tools von Drittanbietern, oft aber auch mit selbst entwickelter oder mindestens selbst entworfener Software. Jenseits von Logfile-Analyse gibt es heute keine relevante Lösung, die ohne Cookies auskommt. Eine der wesentlichen Merkmale der Branche ist nach meiner Meinung ein Wettrüsten um die Datenqualität und -granularität. Die Interessen der Nutzer vertritt in diesem Wettkampf niemand.

—

*) Zumindest mehr als derzeit mit Cookies.
**) Session-IDs in der URL haben insbesondere wg. Suchmaschinen und Bookmarks oder URL-Weitergabe einen schlechten Ruf. Das sind aber Probleme die längt gelöst sind.
***) Alle Browserhersteller arbeiten daran, die Cookies über zentrale Services zu synchronisieren.

Obwohl ACTA eigentlich dazu gedacht war, bestimmte Staaten zu einem Schutz des geistigen Eigentums zu bewegen, sind genau diese Staaten und dabei insbesondere China nicht unter den Unterzeichnern. Es sind insbesondere Staaten dabei, die sowieso schon eine ausgeprägte Rechtslage und Rechtspraxis diesbezüglich umsetzen.

Für Deutschland würden sich zum Beispiel direkt nur wenige Punkte ändern, diese wären aber grundlegend: War es für Rechteinhaber noch bis vor kurzem sehr leicht möglich, an die Identitäten von Filesharern zu kommen, weigern sich inzwischen viele Gerichte wg. solcherlei Bagatellen zu den Providern zu gehen. Nach ACTA müsste Deutschland allerdings ein Gesetz erlassen, dass dem Kläger diese Zuordnung ermöglicht.

Darüber hinaus wäre es einem Kläger im Rahmen eines Zivilprozesses neuerdings möglich, die Werkzeuge zur Vervielfältigung zu beschlagnahmen. Das könnten private Rechner ebenso sein, wie Server bei einem Provider oder sogar facebook- oder Google-Accounts. (Die Three-Strikes-Debatte entspringt übrigens genau hier, denn die Dienste-Anbieter könnten sich so vor einer (vermeintlich) viel komplizierteren Lockdown-Infrastruktur schützen.)

Es wäre zum Beispiel REM möglich, den qrios-Server zu beschlagnahmen, da der Titel dieses Posts eine zu leichte Abwandlung ihres größten Hits sei. Vielleicht würde REM davon keinen Gebrauch machen. Ich müsste allerdings damit rechnen und würde möglicherweise nach Abwägung Abstand davon nehmen.

Wenn unisono von den Regierungsvertretern der Unterzeichner und Deutschlands behauptet wird, es hätte keine Auswirkungen, kann das also so nicht stimmen. Es sei denn, man betrachtet die Tatsache, dass ACTA respektive deren Kommission keine Sanktionen machen kann als genügend. Ob diese Zahnlosigkeit jedoch so bleibt, darf bezweifelt werden. Es ist anzunehmen, dass sich die Unterzeichner nach der Ratifizierung einstimmig auf Sanktionen (z.B. empfindliche Strafzahlungen) einigen. Denn diese Einigung bedarf interessanterweise danach ja nicht mehr der erneuten Ratifizierung durch die jeweiligen Parlamente.

Wenn Deutschland also den Vertrag unterzeichnet und der Bundestag das Werk absegnet werden wir sehr schnell hören “Wir müssen unseren völkerrechtlichen Pflicht nachkommen.“

Gestern schickte @Cappellmeister den Link zu der deutschen Version von ACTA rum und nach einigem Lesen wurde mir plötzlich klar, warum ich mich mit der englischen Version so schwer tat. Der ACTA-Vertrag ist nicht MECE.

MECE kommt ursprünglich aus der Unternehmensberatung und hat sich inzwischen beim Design von XML und Datenbanken etabliert, wird aber auch in der Konzeption und (manchmal) Kreation eingesetzt. Im Kern sorgt es dafür, dass eine Struktur ausgewogen und nicht redundant ist.

Rechtsanwälte arbeiten – insbesondere bei Verträgen – natürlicherweise immer MECE. Bei ACTA wurde darauf verzichtet. Die Inkonsistenz wird deutlich in Artikel 27 Absatz 6. Zitat: “Um den hinreichenden Rechtsschutz und die wirksamen Rechtsbehelfe nach Absatz 5(*) zu gewährleisten, erlässt jede Vertragspartei(**) Schutzbestimmungen zumindest gegen folgende Handlungen:”

a) in Übereinstimmung mit ihren jeweiligen Rechtsvorschriften …

Dieser Punkt sagt also, dass man die folgenden Richtlinien so in Verordnungen und Verwaltungsforschriften einfliessen lassen sollte, dass sie mit dem gültigen Gesetz übereinstimmen. Diese Aussage ist an sich schon ein Pleonasmus. Schon in der Einleitung steht ausdrücklich, dass natürlich alles so sein sollte, dass es mit den gültigen Gesetzen und Verfassungen der jeweiligen Staaten im Einklang steht. Na gut, man kann das ja eine Selbstverständlichkeit nicht oft genug betonen.

Aber

b) die Herstellung, die Einfuhr oder den Vertrieb von Vorrichtungen oder Erzeugnissen, einschließlich Computersoftware, oder die Erbringung von Dienstleistungen,

kann man nun so lesen, dass die darunter fallenden Maßnahmen nicht mehr im Einklang mit dem jeweiligen Recht stehen müssen. Denn ansonsten hätte auch b) mit dem Hinweis auf die gültigen Rechtsvorschriften beginnen müssen.

Meiner Erfahrung nach arbeiten Anwälte immer sehr strukturiert und damit auch MECE. Es sei denn, sie wollen explizit Hintertüren in Verträge einbauen.

*) Absatz 5 sagt etwas über den den Lizenznehmern zu gebenden Rechtsschutz aus.

**) Vertragspartner sind Staaten oder ähnliches (z.B. EU).

@lewispeckover hat offensichtlich entdeckt, dass O2 in UK einen transparenten Proxy* betreibt, der bei jedem Request** die Telefonnummer des Mobiltelefons an den aufzurufenden Server schickt.

If you’re on O2′s UK mobile network (not ADSL), you’ll (probably) see a line beginning with x-up-calling-line-id - followed by your mobile phone number in plain text. Other operators may use different headers, or hopefully none at all - let me know - I’m interested to know if other networks are doing it too.

Zu Testzwecken hat er ein Script geschrieben, das die Header-Informationen auf der Seite listet. Also wer von meinen Lesern zufällig auf der Insel ist und bei O2 einen Mobilvertrag hat kann ja mal draufgehen und nachsehen, ob dort die Telefonnummer steht.

Ich hatte ja auf dem Vortrag erzählt, dass das bei bestimmten mobilen White-Label-Paketen gängige Praxis ist. Dort wird diese Information allerdings nur an bestimmte vertragsrelevante Partner-Sites gesendet und nicht an jeden beliebigen Server.

Insofern vermute ich mal einen Konfigurationsfehler. Es könnte aber auch sein, dass O2 mit größeren Ad-Server-Betreibern Deals hat und die selektive Übermittlung dadurch nicht mehr ohne weiteres möglich wäre.

*) Ein transparenter Proxy routet die Requests und kann diese gegebenenfalls modifizieren. Wird eigentlich von fast allen Mobilfunkbetreibern verwendet um zum Beispiel das Caching zu optimieren.

**) Der Request-Header oder http-Request-Header wird von dem Browser an den WebServer gesendet und enthält alle wichtigen Informationen um eine Resource anzufordern. Die Response hat ebenfalls einen Header und informiert den Browser zum Beispiel über die Größe und das Verfallsdatum der Resource.

[Update] Collin Mulliner hat sich mit dem Thema ausführlicher beschäftigt und einige interessante Fakten zu Tage befördert. Darunter wird als Beispiel übrigens Bild mobil erwähnt, über die ja auch schon mal berichtete. [/Update]

Hier und da poppt seit Jahren eine mehr oder minder starke Furcht vor Algorithmen auf. Egal ob von Meckel, Schirrmacher oder anderen Fuilleton-Natives ist der Tenor immer ähnlich: wir werden alle störben Algorithmen sind dabei den Menschen einzuschränken. Da freut es denjenigen, der sich im Studium mal intensiv mit Technikkritik beschäftigt hat dann doch, dass auch mal eine etwas kenntnisreichere Stimme zu Wort kommt. In der SZ erschien ein Artikel von Kathrin Passig mit dem Titel “Warum wurde mir ausgerechnet das empfohlen?“.

Nun ist Kathrin Passig nicht unbedingt jedem als ausgewiesene Algorithmus-Expertin bekannt, hebt sich aber durch digitale Erfahrung erfrischend von den Mahnern ab. Nur leider hat sie das Thema auch nicht verstanden. Was schade ist, da mspr0 ihr gleich zur Seite springt und ihre (Falsch-)Aussagen kunstvoll in seine These vom Kontrollverlust und der darauf zwangsläufig folgenden Postprivacy einflechtet. Warum Falschaussagen? Weil sie zum Beispiel eine Bestsellerliste einem Algorithmus gegenüberstellt. Dabei ist eine Bestsellerliste genau das: das Ergebnis eines Algorithmus. Den können zwar alle verstehen aber dadurch wird er nicht zum Nicht-Algorithmus.

Für sie ist – wie für die Mahner – ein Algorithmus etwas, das (bei genügend großer Komplexität) ein Mensch nicht mehr verstehen kann. Dazu wird ein (unverlinktes) Zitat bemüht:

Die am Wettbewerb beteiligten Teams [die Programmierer der Algorithmen] gaben in Interviews an, nicht mehr nachvollziehen zu können, wie ihre eigenen Algorithmen zu manchen Ergebnissen gelangen.

Diese Aussage kann man jetzt in mindestens drei Richtungen deuten. Die Programmierer verwenden Code, den sie nicht selbst geschrieben haben (Framework, Compiler) und dies führt zu einem Black-Box-Verhalten, die Programmierer haben Code geschrieben, der sich selbst verändert oder die Programmierer kennen nicht mehr alle Werte, der zu diesem Ergebnis geführt hat.

Der erste Fall kommt recht häufig vor ist aber sicher nicht gemeint, da die konkrete Implementierung egal ist, solange das gewünschte Ergebnis produziert wird. Sollte mein Code trotz eingehender Prüfung nicht mehr das tun, was ich gerne hätte, würde ich überprüfen, ob die beteiligten Frameworks nicht das tun, was ich erwarte und im letzten Schritt, ob der Compiler merkwürdige Seiteneffekte produziert. (Aber normalerweise würde ich erst mal schlafen gehen, weil sich das Problem am nächsten Tag meistens in Luft aufgelöst hat.)

Der zweite Fall ist schon etwas komplizierter. Selbstveränderlichen Code gibt es bereits und wird insbesondere von Virenprogrammierern eingesetzt. Dabei geht es aber nicht um eine Veränderung der prinzipiellen Funktionsweise im Sinne von Evolution sondern lediglich um Mimikri. Ein solcher Code würde im Idealfall tatsächlich dazu führen, dass selbst die Entwickler ihn nicht mehr ohne eingehendes Studium von jedem anderen Code unterscheiden könnten und nicht sagen könnten, was der Code tut. Und dies obwohl sie ihn selbst geschrieben haben.

Es ist mit hoher Wahrscheinlichkeit in dem Zitat der dritte Fall gemeint. Eine Liste von Eingabewerten wird immer wieder durch die Maschine geschickt und kalibriert die vorgegebenen Schwellwerte an Hand von Erfolg und Misserfolg. Dabei kommt in den einzelnen Zwischenschritten viel Stochastik zum Einsatz und ab und zu wird mal der Zufallsgenerator angeworfen, um das ganze System vor der zwangsläufigen Stasis zu beschützen. Die eingesetzen Algorithmen sind in den meisten Fällen mit den mathematischen Fähigkeiten eines Realschülers zu verstehen. Die anscheinende Komplexität entsteht nur aus der Anzahl der Eingabedimensionen und der Anzahl der Iterationen.

Wichtig an diesem Punkt ist besonders der Begriff des Schwellwertes. Denn hierbei handelt es sich nicht um ein einzelnes Bit, dass gesetzt ist oder nicht. (Aber selbst bei solchen Systemen kommen schon komplexe Verhalten zu Stande. Dazu möge man sich die dreißig Jahre alten Arbeiten über zelluläre Automaten von Stephen Wolfram ansehen.)

Schwellwerte werden normalerweise als Fließkomma implementiert. Computer und damit auch Algorithmen sind allerdings recht ungenau im Umgang mit Zahlen wie 1/3 oder Wurzel aus 2. Da es sich um endlose Zahlen handelt muss eine CPU diese Werte runden. Und je nach dem, in welchen Zustand (z.B. in welchem Speicher sich die Werte befinden) kommt eine etwas andere Zahl bei der Operation raus. Genau genommen haben wir es hier mit einer Heisenbergschen Unschärfe zu tun.

Da ein Algorithmus jedoch nichts anderes ist als eine Aneinanderreihung von Operationen ist, werden selbst bei exakt bekannten Eingangswerten die Ergebnisse um so unvorhersagbarer je öfter eine solche Rundung stattfindet.

Einer der wichtigsten aktuell im Einsatz befindlichen Algorithmen ist die Page-Rank-Berechnung von Google. Obwohl bisher nicht nach aussen gedrungen ist, wie er exakt aufgebaut ist, basiert darauf die ganze SEO-Branche. Für viele handelt es sich um reines Google-Voodoo. Dabei kann man an Hand unterschiedlicher Ergebnisse eine Art Verhaltensforschung betreiben. Und obwohl ich noch niemanden gehört habe, der meint, es würde sich um ein Lebewesen handeln verhält er sich dennoch anscheinend so. Ich kann ihn untersuchen an Hand möglichst vieler Parameter, die er auch (vielleicht) sieht. Seine vollständige Funktionsweise könnte ich jedoch nur ermitteln, wenn ich ihn immer wieder in den gleichen Zustand versetzen könnte, was ginge. Ich müsste allerdings auch seine Umwelt wieder in den gleichen Zustand versetzen, was nicht ginge.

Nichts desto trotz ist der Page-Algorithmus einfach und Lerry Page versteht ihn sicher nach wie vor und etliche seiner Mitarbeiter auch.

(Quelle animiertes Gif: http://de.academic.ru/dic.nsf/dewiki/279011)

Die Initiatve der EU-Kommissarin Vivian Reding mit einer Verordnung zum Datenschutz eine europaweite Grundlage zu schaffen liest sich in weiten Teilen wie die Wort gewordenen Träume aller Datenschützer. Opt-In ist für die meisten Datenerhebungen Standard. Der Export der Daten und damit die Plattform-Unabhängigkeit ist vorgeschrieben. Und schliesslich müssen Systeme so gestaltet sein, dass alle personenbezogenen Daten unwiederbringlich gelöscht werden können müssen.

Allerdings findet sich an mehreren Stellen eine Regel, die das Zeug zum Dealbraker hat. Für fast alle Punkte gibt, dass Funktionen Kinder ausschliessen müssen. Mit Kindern sind alle Personen unter 18 Jahren gemeint. Unter Umständen sind die Erhebung und Verarbeitung noch gestattet, wenn das Einverständnis der Eltern vorliegt.

Damit kann eine komplette Branche nur noch dann arbeiten, wenn Clients eine minimale Information über das Alter des Nutzers an den Service sendet. Denn andernfalls muss der Betreiber damit rechnen, dass es sich möglicherweise um ein Kind handelt, dessen Daten er unter keinen Umständen erfassen und verarbeiten darf.

Solange diese Altersübermittlung nicht existiert dürfen eigentlich keine Daten mehr erhoben werden oder zumindest nicht verwertet werden bis eindeutig klar ist (z.B. durch eine Anmeldung mit Altersindiz), dass es sich nicht um ein Kind handelt. Das dürfte somit das vorläufige Ende von Bannerwerbung und Targeting sein, wie wir es kennen.

Begründet wird der besondere Schutz übrigens mit der Naivität der Kinder. Wobei ich manchmal den Eindruck habe, dass da die Politiker von sich ausgehen und annehmen, dass die Kinder noch weniger von der Technik verstehen als sie selbst. Was für ein Fehlschluss.

Im Rahmen einer Recherche habe ich mich mal eingehender mit der Funktionsweise und Browser-Kompatibilität von Cookie-Replacements beschäftigt. Als einzig sicheres, performantes und valides Verfahren stellt sich Cached-Canvas-Image dar. Hier kurz die Funktionsweise:

Beim erstmaligen Besuch einer Site wird in ein Canvas-Element ein Bild mit einem Bitmuster geladen. Dieses Bild wird vom Server on the fly generiert und mit einem Cache-Stempel weit in der Zukunft an den Browser gesendet.

Ein Bitmuster mit der ID "aeaeaec9c9c94f4f4fc3c3c3ffffffcccccc1d1d1d919191ffffffaaaaaa"

Beim späteren Besuch lädt der Browser das Bitmuster-Bild aus dem Cache. Danach werden mittels JavaScript die Farbwerte für die Pixel des Bildes ermittelt und daraus zusammen mit einer eindeutigen ID, die der Server in die Seite geschrieben hat, an den Server gesendet, z.B. per weiteren Image-Load. Auf dem Server werden dann die eindeutige ID mit dem Profil der ID in dem Bitmuster-Bild verknüpft.

Eine Testimplementierung ergab, dass trotz der Verwendung von Canvas der ganze Prozess auf einem aktuellen Rechner nicht mehr als 1/10 Sekunde dauert und damit keine Hürde für den weitflächigen Einsatz darstellt. Interessant ist, dass dieses Verfahren auch Site-übergreifend funktioniert und damit die Beschränkung von Cookies bzgl. Domains aushebelt.

Eine Abwandlung dieses Verfahren würde auch ohne Canvas funktionieren müsste dann aber eine erhebliche Anzahl von Requests auf ungecachte Images durchführen.

In unseren Tests zeigen die Browser Safari, Chrome und Firefox alle unisono das gleiche Verhalten: die ID wird korrekt aus dem Bitmuster ermittelt und somit der Browser ohne Cookie identifizierbar.

Anti-Tracking-Tools wie Ghostery können ein solches Vorgehen auf einer Web-Seite nicht erkennen und damit auch nicht unterbinden. Es hilft einzig das regelmäßige Löschen des Browser-Caches oder das Abschalten von JavaScript.

Während meines Vortrags “Daten-Fee oder Datenvieh” und direkt danach vor Ort und online sind etliche Fragen gestellt worden, die ich hier zusammenfassen und beantworten möchte.

Welchen Wert haben die Daten die durch facebook, Google und andere “Social Plugins” erhoben werden?

Befindet sich auf einer Seite ein aktives Social Plugin, werden Daten über den Aufruf der Seite an die jeweiligen Anbieter (facebook, G+, twitter etc.) gesendet. Dabei spielt prinzipiell erst mal keine Rolle, ob der User (mit diesem Browser) aktuell bei dem jeweiligen Dienst angemeldet ist oder ob er dort überhaupt einen Account besitzt.

Da es sich bei den Anbietern um Black Boxes handelt, ist unklar, welche Verknüpfung direkt oder später zwischen diesen anonymen oder personalisierten Trackingdaten stattfindet. Aus Sicht der Qualität des Services von G+ und facebook ist eine solche Verknüpfung natürlich sinnvoll. Bleibt aber dennoch Spekulation.

Es gilt aber wie bei Targeting und Retargeting die Aussage, dass die Daten mit jedem weiteren Datum wertvoller werden. Und es ist keine Prophetie, wenn man sagt, dass diese Daten früher oder später verkauft werden. Entweder an verschiedene Kunden oder als Asset bei einer Übernahme.

Warum sollten denn die IP-Adressen aus den Logs entfernt werden wenn sie nicht (mehr) für die Auswertung herangezogen werden? (@alvar_f)

Natürlich zunächst mal, weil es geltendes Recht ist. Vor dem Hintergrund eines Zuviels an Gesetzen könnte man vielleicht darüber diskutieren, ob dieses nicht auf die Streichliste gehört. Allerdings deckt es ja auch andere und zukünftige Situationen ab. Denn mit der Verbreitung von IPv6 (MAC-Adresse) und einer zunehmenden Diversifizierung des Browsermarktes (“Fingerprinting”) wird dieser Punkt wieder extrem relevant.

Aber bevor man über ein “Zuviel” von Gesetzen diskutiert sollte man vielleicht mal über Datensparsamkeit nachdenken und die Web-Server-Logs ein wenig ausdünnen.

Führt Opt-In nicht zu einem Wust an Kleingedrucktem, das sowieso niemand durchliest?

Unter dem Titel “Datenschutztheater: Die informierte Zustimmung” hat Kristian Köhntopp im Kern folgende Aussage gemacht: die bisherigen Verfahren, die den Schutz der privaten Daten leisten sollen sind eigentlich reine Datenverwaltungsvorschriften. Es würde nicht um den Schutz der Daten gehen sondern darum, den Erheber der Daten vor Ansprüchen seitens der User zu schützen.

Tatsächlich würde ich ihm ohne Einschränkungen zustimmen. Bisherige Einverständniserklärungen sind ungeeignet den User über die Verwendung (Erhebung und Ziel der Verarbeitung) zu informieren.

Die Forderung muss also daher sein, den Sinn und Zweck der Erhebung in einfacher Sprache zu vermitteln. Wenn das nicht gelingt dürfen die Daten eben nicht erhoben werden.

Opt-In würde die Betreiber automatisch zu Datensparsamkeit zwingen. Denn es ist wesentlich schwerer, den Nutzer zu einem Einverständnis vor der Anmeldung zu überreden als ihm implizites Einverständnis unterzjubeln. Und ich bleibe bei meiner Aussage, dass – abgesehen von Profilern – die meisten Betreiber wesentlich mehr Daten erheben als sie später sinnvoll auswerten (können).

Das Thema Zertifikate und Siegel hat vdsetal weiter recherchiert und kommt zu sehr interessanten Aussagen.

Auf dem 28C3 werde ich unter dem Titel Daten-Fee oder Datenvieh einen Vortrag halten. Im Kern geht es darum, wie, wer, woran und wieviel Geld mit den Nutzungs- und Nutzerdaten im Web verdient. Ich schlüssele den Umsatz der Online-Werbebranche von derzeit mehr als 6 Mrd. € auf und zeige, welche technischen Mittel die Branche verwendet, um die User über den tatsächlichen Datenfluss im Unklaren lässt.

[Update] Der Vortrag ist sehr gut gelaufen. Der Saal 3 war voll und das Publikum sehr interessiert und hat im Anschluss gute Fragen gestellt. Auch wenn ich nicht alle zu meiner eigenen Zufriedenheit beantworten konnte – trotz Überzug – war das Feedback nach dem Talk vor Ort und auf twitter sehr gut. Hat mich auf jeden Fall ermuntert, weiter aufklärend zu agieren.

Auf Youtube gibt es den Vortrag (noch als prerelease, Update kommt dann) hier.

Über twitter wurde ich noch auf diesen Artikel bei vdsetal zu Do-Not-Track aufmerksam gemacht.

Das Interview des Deutschlandfunk mit mir findet man in voller Länge hier (mp3) auf der 28c3-Seite.

Korrektur: Ich hatte in meinem Vortrag gesagt, dass Webtrekk eine Tochter von Axel Springer sei. Das ist nicht der Fall. (Danke für den Hinweis!)

[/Update]

CouchDB in der Version 1.2.0 respektive die Adminoberfläche Futon hat einen Bug, um den sich offensichtlich keiner kümmert, weil die ganzen Leute ja sowieso das Interface insbesondere für die Views nicht benutzen. Für mich war das allerdings nervig, weil ich die Views tatsächlich unter Futon teste. Wollte man einen View speichern kommt die Meldung:

Cannot save view because the design document language is “undefined” not “javascript”.

Nun ist Undefined tatsächlich nicht JavaScript aber daran sollte sich doch keiner stören. Egal. Hier ist der Workaround (nicht schön aber …):

Man gehe zu der Datei futon.browse.js im CouchDB-Paket. Dort findet sich in der Zeile 558 “success: function(doc) {“, man füge danach

doc.language = ‘javascript’;

ein und gleiches tue man nach der Zeile 506. Danach hat man keine Probleme mehr mit dem Sichern von Views. Ist natürlich dann auf JavaScript für die Map- und Reduce-Funktionen angewiesen.