qrios

@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 ausgewiesene Algorithmus-Expertin 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 unverhersagbarer 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.

Der Datenschutz und besonders die deutschen Datenschützer sind einer kleinen aber wortgewaltigen Gruppe von Firmen und Selbständigen offensichtlich ein Dorn im Auge. Sie werden nicht müde, zu betonen, dass die Verantwortlichen den Bezug zur Realität verloren haben. Vollkommen weltfremde Forderungen würden gestellt. Es wird das Menetekel einer Online-Wüste Deutschland an die Wand gemalt.

Mit einem vollkommen absurden Rant hat sich Nico Lumma grade hervorgetan. Er zitiert dazu eine größere Passage des jüngsten Beschlusses der Datenschützer in der im Kern folgende Punkte stehen:

1. Der Betreiber einer WebSite ist für den Schutz der Daten seiner User verantwortlich.
2. Die Sozialen Netzwerke geben keine oder nur ungenügende Auskunft, welche Daten durch ihr PlugIn erhoben werden und was mit diesen Daten geschieht.
3. Der Betreiber einer WebSite muss seine Nutzer über diesen Umstand informieren und gegebenenfalls davor schützen.

Keiner dieser Punkte ist jedoch in irgendeiner Form anzuweifeln. Es ist geltendes Recht in Deutschland. Und wenn man sich die aktuellen Entwürfe aus Brüssel ansieht wird es auch demnächst geltendes Recht in Europa. Read the rest of this entry »

Google Analytics zählt weiter fleissig Browser, die den Do-Not-Track-Header senden.

“‘Wissen Sie, ich hab’s Ihnen ja gesagt’ trifft es nicht so ganz.” ist eines meiner Lieblingsfilmzitate. Und so verwende ich es gerne und oft. Jetzt gibt’s wieder die Möglichkeit dazu:

Google Analytics ist das mit Abstand verbreitetste Tracking-Tool im Netz. Und obwohl Google der Do-Not-Track-Initiative eine eigene entgegengestellt hat, sollte man erwarten, dass Google den Wunsch der User respektiert. User, die in ihrem Browser die Option eingeschaltet haben (z.B. in Firefox oder in Safari mit Hilfe der Developer-Tools) wägen sich unbeobachtet, sind es aber nicht.

Bei eingeschalteter Option sendet der Browser bei jedem Request einen Header mit dem Namen ‘dnt’ und dem Wert ’1′. Eigentlich dürfte ein Tracking-Tool oder ein Ad-Server dann die Session-Daten nicht speichern. Damit dürften sie in den Statistiken von zum Beispiel Google Analytics nicht auftauchen. Allerdings erscheinen sie dennoch.

Besonders interessant dabei ist, dass in der Hilfe zu Google Analytics das Do-Not-Track-Verfahren als eine Möglichkeit für Site-Betreiber genannt wird, die eigenen Besuche auszusparen.

Google schweigt derzeit noch dazu, wann sie planen das Feature vernünftig zu unterstützen. Und es hilft sicher nicht, die Partner vorzuschicken und den Usern Sand in die Augen zu streuen in dem man behauptet, bei Do-Not-Track ginge es doch gar nicht um die Daten für Web-Analytics.

Mit dem vorhergesagten Ende von Flash auf mobilen Geräten und dem damit ebenso vorhergesagten Ende von Flash auf den meisten anderen Geräten hat die Content-Industrie plötzlich ein Problem, das sie eigentlich als schon gelöst angesehen hatte:

Wie vertreiben wir unseren Content im Netz ohne jegliche Kopiermöglichkeit?

Die drei wichtigsten Distributionskanäle (Kino, Silberscheibe, TV) sind alle – trotz hartnäckiger Bemühungen – geknackt. Daher finden sich alle dort veröffentlichten Filme innerhalb kürzester Zeit auf allen Verbreitungsplattformen im Netz.

Ein sicherer Channel im Netz hätte die Chance geboten, wenigstens die Filme die es nicht ins Kino schaffen, weil sie dort keinen großen Erfolg versprechen, längere Zeit im Netz laufen zu lassen, ohne dass die Kunden andere als die kostenpflichtigen Quellen nutzen könnten. Das hätte eine schier unerschöpfliche Quelle ewigen Reichtums sein können.

Nun ist Flash tot und ausser Apple hat nur Microsoft ein qualitativ hochwertiges Video-Format wie H.264 im Bundle mit einem halbwegs sicheren DRM. Daher verwundert es nicht, wenn die Content-Leute auf die abstruse Idee kommen, von den Distributions-Plattformen zu verlangen, dass nun Silverlight verwendet wird. Nach Netflix wird auch Lovefilm Silverlight verwenden. Ob diese Entscheidung Microsoft wirklich freuen kann, darf ernsthaft bezweifelt werden. Denn eigentlich steht Silverlight bei MS schon länger auf der Abschussliste.

Die User von Lovefilm sind offensichtlich verärgert über diese Entscheidung und so hat es diese Dinosaurierindustrie mal wieder geschafft, an den Bedürfnissen der User vorbei Entscheidungen durchzusetzen und sich ins Abseits zu manövrieren.