Herr meiner Daten

Was ich bei den sozialen Netzwerken, und Facebook insbesondere, ja nicht verstehe, warum darf ich nicht Herr meiner eigenen Daten sein? Warum wird es mir zum Beispiel so schwierig gemacht, meine Privatsphären-Einstellungen anzupassen, so dass ich und Andere sie auch verstehen? Ok, die Frage nach dem Warum stellt sich eigentlich ja nicht, weil wir alle wissen, Facebook und Co. wollen ja genau das nicht, dass wir es verstehen und damit nichts mehr nach außen preisgeben.

Warum ist es aber nahezu unmöglich, dafür zu Sorgen, dass meine Daten nicht an Dritte, die ich und die mich nicht kennen, weitergeleitet werden? Wieso muss ich in mühsamer Kleinarbeit dafür sorgen, dass der Klick auf ein „Gefällt mir“ nicht Wellen mit so weiten Kreisen schlägt, wie ich mir das vorher gar nicht denken konnte? Klick seit kurzem bei Facebook auf „Gefällt mir“ bei einem Beitrag auf der Pinnwand eines Freundes auf „Gefällt mir“ und all Deine Freunde, auch wenn Sie Ihn nicht kennen, werden es lesen können und wenn die auf Gefällt mir klicken, deren Freunde und so weiter. Jetzt mal ernsthaft, im realen Leben frage ich doch meine Freunde auch nicht nach deren Freunde, die ich nicht mal im Ansatz kenne und umgekehrt. Bei Facebook werden mir aber durch die neuen Einstellungen Personen aufgedrängt, die ich nicht kenne, zu denen ich keinen Bezug habe und gleichzeitig kann ich mir nicht mehr sicher sein, wer meine Inhalte alles zu Gesicht bekommt.

Wo soll der Sinn darin liegen, ausser das jeder für Jeden transparent erscheint?

Wieso kann ich nicht meine Daten unwiderruflich löschen? Wieso meinen die Betreiber der sozialen Netzwerke, dass Daten auf ewig bestand haben müssen, selbst wenn ich das nicht möchte? Klar, hier könnte man behaupten, was du einmal zu wem gesagt hast, vergisst der vielleicht nicht. Aber seien wir ehrlich, in der Realität wächst gerade bei den zwischenmenschlichen Beziehungen irgendwann über das Meiste Gras. Irgendwann kräht kein Hahn mehr danach, was ich letztens auf einer Party zu irgendwem gesagt habe, oder das ich irgendwen aus irgendwelchen Gründen mal nicht leiden konnte. Facebook und Co. vergessen aber nichts, und wollen das auch nicht, selbst wenn ich das wünsche. Damit wird man zu einem gewissen Grad unmündig. Was ich mich in diesem Zusammenhang letztens fragte, war: Was passiert eigentlich mit Bildern die dritte von mir bei Facebook hoch laden? Mir ist zwar bewusst, dass Bilder, die ich hoch lade, laut den AGBs Facebook zur unbeschränkten Nutzung berechtigen, aber hier liegt ja auch eine Willenserklärung von mir vor, da ich es eben aktiv unterstützt habe. Aber wie ist das nun, wenn ein Freund ein Bild von mir hoch lädt, auf dem vornehmlich nur ich zu sehen bin. Habe ich dann noch die Möglichkeit, es wirklich löschen zu lassen? Schließlich sichert mir das deutsche Recht das Recht an meinem eigenen Bild zu, um solche Fälle zu vermeiden?

Hat also mal wer versucht, Bilder entfernen zu lassen, die er selbst nicht zur Verfügung gestellt hat?

Wenn man übrigens mal sehen will, was Facebook von einem so alles speichert (und wirklich nicht löscht, auch wenn man es glaubte, weil man es in Lösch-ähnlichem Prozess entfernte), dem empfehle ich folgenden Blog-Eintrag: http://gutjahr.biz/blog/2011/09/facebook-so-holst-du-dir-deine-daten/

Abschließend möchte für mich noch mal klarstellen, ich habe nichts dagegen, dass solche Seiten über mich alles mögliche speichern wollen und zum Teil auch müssen und von mir aus auch niemals löschen wollen, damit die Dienste mit „Sinn“ und „Leben“ gefüllt werden, nur die Herrschaft über meine Daten, sollten immer bei mir liegen. Zumindest sollte die öffentliche zur Schau Stellung meiner Inhalte unterbunden werden, wenn ich dies nicht mehr möchte. Ich bin der Herr meiner Daten.

 

 

IE7,8 Bug mit Problem aus iFrames

Ab und an muss man noch mit iFrames arbeiten, vor allem, wenn man eigene Inhalte auf Facebook Fanseiten zu Verfügung stellen möchte. Mitunter möchte man auch schon mal Daten persistent von einem Tab zum Nächsten beim User speichern, z.B. für eine Sprach- oder Ländereinstellungen. Klar denkt man dann sofort an Cookies.

Wenn man, wie ich, überwiegend mit Chrome oder Firefox testet und den Internet Explorer nur am Schluss zur Überprüfung des Layouts, mit all seinen Tücken, für die letzte Qualitätssicherung hinzu zieht, kann man gerade bei Cookies, die in einem iFrame gesetzt werden, eine Überraschung erleben. Obwohl die Standard-Sicherheitseinstellungen das Speichern des Cookies zulassen müssten, entdeckt man plötzlich ein kleines Warnsymbol in der Statusleiste des IE, mit dem Hinweis, dass der Cookie geblockt wurde. Zuerst dachte ich dann, wird der Cookie in den anderen Browser etwa auch geblockt, aber das kann ja nicht sein, da dort alles einwandfrei funktionierte.

Jedenfalls gibt es beim W3C ein Projekt Namens Platform for Privacy Preferences (P3P). Und dieser quasi Standard des W3C sorgt unter anderem dafür, dass Cookies im IE7 und IE8 nicht wie erwartet funktionieren.

In einem Blog-Eintrag von Adam Young habe ich dann die Lösung (PHP) für das Problem gefunden: http://adamyoung.net/IE-Blocking-iFrame-Cookies

Siehe da, nun klappt es auch im IE.

Double Opt-In ohne Datenbank

Wenn man von Nutzern Daten in irgendeiner Art erhebt, in der Regel via eines Online-Formulars und man Aufgrund des angestossenen Vorgangs reagieren möchte, zum Beispiel dem Versenden von Newslettern, kommt man um ein sogenanntes Double Opt-In nicht drum herum, wenn man sich nicht mit Schadensersatzansprüchen des Nutzers herumschlagen möchte, weil dieser vielleicht unerwünschte E-Mails oder Anrufe erhalten hat.

Wir haben bisher immer alle Benutzerdaten bei diesem Prozess in Datenbanken gesichert, was natürlich bedeutet, dass man den Nutzer zusätzlich auf Datenschutz-Bestimmungen hinweisen muss. Je nach Formulierungen ein weiterer juristischer Knackpunkt. Auf der technischen Seite wird man gezwungen eine Datenbank aufzusetzen, diese Daten zu pflegen und gegebenenfalls per definiertem Regelwerk den Datenbestand wieder zu bereinigen. Wie man sieht, im laufe der Zeit nicht wenig Aufwand, den man sich damit einfängt.

Ich muss zugegeben, es gibt Szenarien, wo man nicht darum herum kommt, die oben genannten Punkte alle zu berücksichtigen, aber wir hatten letztens den Fall, dass Daten via eines Bestellformulars für Probefahrten direkt an ein CRM (Customer-Relationship-Management) weitergeleitet werden sollen und wir die Datenvorhaltung lediglich für das Double Opt-In benötigen. Da kam ein ehemaliger Kollege von mir auf die Idee, doch alles via E-Mail inkl. der Daten per Get-Parameter zu übergeben. Da in diesem Fall sämtliche Daten in dem Link für das Double Opt-In innerhalb der E-Mail sind, benötigen wir hier keine weitere Instanz, um die Daten zu speichern.

Damit nicht jeder sofort erkennt, was da versendet wird, sollte man den Wert des Get-Parameters maskieren, zum Beispiel mit der PHP-Funktion base64_encode. Noch besser wäre es, das ganze zu verschlüsseln, wobei sich hier in PHP die mcrypt-Library eignet. Aus dem ganzen könnte dann folgende Klasse entstehen:

Nun braucht man einen passenden String, den man mit der oben aufgeführten Klasse verschlüsseln möchte. Ich fand einen JSON Formatierten String für diesen Zweck ideal, da man ja am Ende die Daten wieder irgendwie nach Keys und Values auflösen möchte. Hier kann man entweder mit entsprechenden Libraries einen JSON String erstellen (JSON Encode), oder, da das Format recht überschaubar ist, den String selbst erstellen.

Ich habe mich für Letzteres entschieden und am Ende sollte das dann so oder ähnlich aussehen. Das Ergebnis wird dann für das Double Opt-In via E-Mail an den User gesendet. Die Daten kommen aus einem vorher ausgefüllten Formular:

Ich habe den String vor allem selbst erstellt, um die Möglichkeit zu haben, die Key-Namen um einiges zu verkürzen, damit der String bei mehreren Feldern nicht zu lang wird. URLs sollten eine länge von ca. 2000 Zeichen nicht übersteigen und da beim Verschlüsseln, trotz des komprimierens die Länge etwas zunimmt, schadet es nicht, dort zu sparen, wo es geht und Sinn macht.

Der User erhält eine E-Mail, wenn er korrekterweise der richtige Empfänger ist, wird er auf den Link klicken und auf der Zielseite wird der verschlüsselte Wert wieder dekodiert, das JSON Objekt wieder in ein Array umgewandelt und die Daten dann weiter verarbeitet, zum Beispiel an ein externes CRM geschickt.

Wie man sieht, kommt man so um eine eigene Datenhaltung herum und spart sich eine Menge Aufwand.