Schlagwort-Archive: Cookies

Gut gemeint

Großen Anteil am schlechten Ruf des Datenschutzes haben die Cookie-Zustimmungsdialoge, ohne die sich kaum noch eine Website ins Netz wagt. Mit wenigen Ausnahmen offen manipulativ heischen sie um Einwilligungen und gehen im Namen des Datenschutzes allen auf den Wecker: den einen, weil ihnen Cookies egal sind, den anderen, weil das Ablehnen Arbeit macht. Weder die einen noch die anderen können ausdrücken, was sie eigentlich sagen wollen.

Vordergründig scheinen die Rollen klar verteilt: hier die wackeren Datenschützer, die Grundrechte verteidigen, dort die gierigen Datenkraken, die diese Rechte nonchalant mit Füßen treten. Mit Dark Patterns, schmutzigen Tricks in der Benutzerführung, führen Websites ihre Besucher zur Einwilligung, deren Wirksamkeit freilich fraglich bleibt. Hin und wieder gehen Datenschutzbehörden dagegen vor, wie vor einiger Zeit in Dänemark.

Doch so klar lassen sich Schuld und Unschuld nicht zuweisen, sonst wäre der Datenschutz dieser Seuche längst Herr geworden. Tatsächlich sehen wir hier eine Wechselwirkung zweier unabhängig voneinander entworfener Systeme, von denen jedes für sich einen Sinn ergibt, die aber nicht aufeinander abgestimmt sind. Das eine System ist das World Wide Web als Plattform für alle möglichen Anwendungen sowie als Ökosystem der Arbeitsteilung und daraus resultierender Beziehungen. Das andere System ist der Datenschutz mit seiner eigenen Vorstellung, wie die Welt funktioniere und zu funktionieren habe.

Bei ausgewogener Betrachtung zeigen sich nicht nur gegensätzliche Interessen, ohne die der Datenschutz als Regelwerk und Kontrollsystem überflüssig wäre, sondern auch Schwächen des Datenschutzes, die zum Problem beitragen: eine nur teilweise Risikoorientierung, Blindheit für die Verhaltensökonomie der Verantwortlichen und Verarbeiter, sowie die Fehlallokation von Zuständigkeiten im Ökosystem.

Die Risikoorientierung des Datenschutzes ist eine gute Idee: Der Aufwand für Schutzmaßnahmen orientiert sich an den Risiken, die aus der Datenverarbeitung erwachsen. So müssen zum Beispiel die Gesundheitsdaten von Millionen Krankenversicherten stärker geschützt werden als die Mitgliederkartei Gesangsvereins. Dazu orthogonal verläuft jedoch die Frage, ob beziehungsweise auf welcher Erlaubnisgrundlage die Daten im Einzelfall überhaupt verarbeitet werden dürfen, denn die Verarbeitung erfordert stets eine gesetzliche oder individuelle Erlaubnis. In dieser Dimension gibt es keine Risikoorientierung, die Verarbeitung personenbezogener Daten kann nicht alleine wegen Harmlosigkeit erlaubt sein. Deswegen fragen uns Websites für jedes Cookie, das sich die Betreiber nicht als unbedingt erforderlich zu deklarieren trauen, nach unserer Einwilligung oder einem eventuellen Widerspruch.

Verhaltensökonomie versteht der Datenschutz auf der Betroffenenseite, jedenfalls soweit es um Einwilligungen geht. Einwilligungen müssen freiwillig erfolgen und mit etwas Analysearbeit kann man die Freiwilligkeit bezweifeln, wenn Benutzerführungen manipulativ wirken. Weniger Aufmerksamkeit widmet der Datenschutz der Verhaltensökonomie auf Seiten der Verantwortlichen und Verarbeiter. Für sie ist Datenschutz ein Compliance-Problem: Sie möchten ihre Geschäftstätigkeit möglichst ungestört ausüben, müssen dabei jedoch gesetzliche Bestimmungen einhalten und riskieren andernfalls Strafen.

Dies gibt Unternehmen einen Anreiz, mit möglichst geringem Aufwand möglichst umfassend korrektes Handeln zu dokumentieren, um Strafen zu entgehen. Das Heischen um Einwilligungen dient diesem Zweck, es soll dokumentierte Einwilligungen in die beabsichtigte Datenverarbeitung produzieren. Hierin liegt die Ursache manipulativer Gestaltung und mithin teils im Datenschutz selbst, der tatsächlich oder vermeintlich zu wenig Spielraum für die einwilligungsfreie Verarbeitung bietet. Organisationen sind tendenziell ängstlich und neigen dazu, Verantwortung abzuschieben – in diesem Fall auf die Nutzer als Betroffene, die doch bitte selber wollen sollen, was eine Website sollen will.

Zu guter Letzt entspringt die Seuche der Cookie-Einwilligungs-Dialoge auch einer Fehlallokation von Verantwortung im Ökosystem World Wide Web. In Wirklichkeit geht es gar nicht um Cookies, sondern um von Dritten bereitgestellte Dienste, die eine Website einbindet und zu denen deshalb Nutzerdaten fließen. Dazu gehören zum Beispiel Statistikdienste wie Google Analytics, Werbeplattformen, Einbettungen fremder Inhalte sowie technische Unterstützungsdienste.

Die Auswahl unterscheidet sich von Website zu Website, doch letztlich handelt es sich um eine relativ überschaubare Menge von Hintergrunddiensten, denen Nutzer auf verschiedenen Websites immer wieder begegnen. Zum Teil ist das ausdrücklich gewollt, etwa bei Werbeplattformen, die einzelne Nutzer über viele Websites hinweg wiedererkennen und verfolgen möchten. Zwar arbeiten die Hintergrunddienste unabhängig voneinander, aber jeder für sich ist zentralisiert und zusammen bilden sie eine Plattform, derer sich Websites bedienen.

Für den Datenschutz sind jedoch in erster Linie die einzelnen Websites zuständig. Sie tragen die Verantwortung dafür, ihre Besucher über die Datenverarbeitung zu informieren und nötigenfalls deren Einwilligung einzuholen. Das ist gut gemeint – Warum sollten sich Besucher einer Website mit den Zulieferern des Betreibers beschäftigen? – aber es passt nicht zur Struktur des Ökosystems. Da jede Website für sich und ihre Zulieferer verantwortlich ist, fragt auch jede für sich nach: Darf Werbeplattform X dich auf spiegel.de verfolgen? Darf Werbeplattform X dich auf heise.de verfolgen? Darf Werbeplattform X dich auf handelsblatt.de verfolgen?

Nicht Werbeplattform X fragt also nach einer Einwilligung, sondern jede Website, die damit arbeitet. Es gibt auch keine Möglichkeit, einmal festzulegen, dass man nie und nirgends etwas mit Werbeplattform X zu tun haben möchte. Damit aber wird die aktive Bitte um Einwilligung selbst zum manipulativen Dark Pattern, denn sie verursacht beim Nutzer Aufwand pro Website. Schlimmer noch, ausgerechnet bei Verwendung des Private- bzw. Incognito-Modus oder anderer Mechanismen zum Löschen von Cookies wird nicht einmal die Entscheidung pro Website gespeichert. Der Aufwand, sich mit einem Cookie-Einwilligungs-Dialog auseinanderzusetzen, fällt dann sogar pro Website-Besuch an, obwohl man es am Ende immer mit denselben paar Hundert Hintergrunddiensten zu tun hat.

Ganz gleich wie die Einwilligungs-Dialoge im Einzelnen gestaltet sind, die aktive Bitte um Cookie-Einwilligungen pro Website wirkt alleine bereits als Dark Pattern. Nutzerseitig entstehen fortlaufend Verhaltenskosten, die bei Verwendung von Datenschutzmechanismen zunehmen. Mechanismen für eine effiziente Selbstbestimmung über Hintergrunddienste fehlen. Dem Datenschutz ist es bis heute nicht gelungen dieses Defizit zu beheben oder auch nur eine Lösung zu skizzieren. Im Endeffekt besteht der Datenschutz auf Compliance zu Lasten der Betroffenen, weil er zu unbeweglich und sein Horizont zu eng ist.

Cookies, Clients und die Cloud

Politiker und Bürokraten wollen die Verwendung von Cookies gesetzlich regulieren, erst die EU (mit unklarem Regelungsgehalt und schleppender Umsetzung), ein paar Jahre später nun auch die SPD. Warum ist das blöd? Ich hole mal etwas weiter aus:

Persönliche Computer, PCs, waren in den 70er und 80er Jahren des letzten Jahrhunderts eine große Sache. Jedem seinen eigenen Computer, klein genug für den Schreibtisch und mit verschiedenen Anwendungsprogrammen für vielerlei Zwecke einsetzbar, das hatte es vorher höchstens als Vision gegeben. Aus dieser Frühzeit der Jedermann-IT stammen viele Vorstellungen, die wir noch heute hegen, darunter die Wurzeln unseres Datenschutzes.

Auf den ersten Blick hat sich seitdem wenig geändert. Aus dem PC auf Arbeit wurde ein Gerätezoo für alle Lebenslagen aus PCs, Note- und Netbooks, Smartphones, Tablets, Internetradios, Spiekonsolen und so weiter, technisch im Grunde genommen immer noch persönliche Computer, nur schöner und kleiner und schneller. Seit den 90er Jahren folgte dem Jedermann-Computer das Jedermann-Netz und im folgenden Jahrzehnt wurde dieses Netz mobil und sozial. Allen Schichten gemein ist, dass ihre Nutzer in Selbstbedienung nach Bedarf Dienste einkaufen, die nach dem Umfang der Nutzung bzw. den zugesicherten Ressourcen abgerechnet werden. Dienstanbieter stellen aus einem Pool an Ressourcen ohne Zeitverzug die jeweils nachgefragten Dienste bereit.

Die jetzige Dekade wird das Jahrzehnt des Cloud Computing. So wie der PC in den 70ern entstand und in den 80ern seinen Namen bekam und sich verbreitete, ist Cloud Computing keine ganz neue Sache, sondern längst erfunden, einsatzbereit und zum Teil auch schon etabliert. Neu ist nur, dass es jetzt einen Namen dafür gibt und alle ein Geschäft wittern, nachdem die Early Adopters vorgemacht haben, dass es funktioniert.

Cloud Computing bedeutet, dass ein Großteil der IT als Dienst ins Netz wandert. Das kann auf verschiedenen Abstraktionsebenen geschehen. Infrastructure as a Service (IaaS) bietet virtuelle Maschinen und Speicher, Platform as a Service (PaaS) liefert Anwendungsplattformen und Software as a Service (SaaS) schließlich macht Anwendungssoftware zu einem Dienst. Ein Beispiel für SaaS ist wordpress.com, wo dieses Blog gehostet wird. Die Schichten lassen sich stapeln, ein SaaS-Anbieter kann auf PaaS-Dienste zurückgreifen, die sich ihrerseits auf IaaS stützen. Die unteren Schichten IaaS und PaaS sind vor allem für Unternehmen interessant, während SaaS in Form von allerlei Webdiensten längst Teil unseres Alltags ist und die klassische Nutzung von Anwendungssoftware auf einem PC teils ersetzt, teils ergänzt.

Geht es um Sicherheit und Datenschutz im Cloud Computing, starren alle wie gebannt auf die Dienstseite. Daten wandern ins Netz, ob aus dem Rechenzentrum eines Unternehmens oder vom heimischen PC, und man weiß nicht genau, wo sie eigentlich gespeichert und verarbeitet werden. Das macht Angst und wirft technische, organisatorische und rechtliche Fragen auf. Hinzu kommt, dass der Übergang von Software in Kartons zu Diensten im Netz in Verbindung mit agilen Entwicklungsmethoden die Softwareentwicklungs- und -lebenszyklen verändert. Es gibt kein Google 3.0, das ich kaufen und dann ein paar Jahre verwenden könnte, sondern Änderungen am Dienst im Wochen-, Tage-, Stunden- und sogar Minutentakt. Continuous Deployment und DevOps nennen wir diese bewusste Vermischung von agiler Entwicklung und Produktivbetrieb.

Ein SaaS-Dienst ist nicht in sich abgeschlossen und unabhängig vom Rest des Netzes, sondern es handelt sich, für Nutzer manchmal schwer erkennbar, um eine Aggregation mehrerer Anwendungs- und Hilfsdienste, ergänzt um spezifische Funktionen des aggregierenden Hauptdienstes. Like-Buttons, Widgets, Videos, RSS-Feeds, Analytics, Werbebanner, Nutzerkommentare, Payment, Fonts und so weiter stützen sich auf Fremddienste, die, oft clientseitig, in den Hauptdienst integriert werden. Hilfsdienste haben meist ihren eigenen Betreiber und sie werden in viele verschiedene SaaS-Dienste eingebunden.

Weniger Aufmerksamkeit erhält beim Blick auf die Cloud die irdische Hälfte des Systems, die Client-Seite. Cloud-Dienste besitzen praktisch immer ein Webinterface, mindestens fürs Management, oft auch – und bei SaaS sowieso – für den eigentlichen Dienst. Der Nutzer bekommt damit eine universelle Client-Umgebung, bestehend aus einem Browser mit generischen Plugins (Flash, Java, Silverlight) und Unterstützungsanwendungen (PDF-Viewer, Office, iTunes) auf dem klassischen PC oder aus einem Browser und anwendungsspezifischen Apps auf mobilen Gadgets wie Smartphones oder Tablets.

Nach dieser langen Vorrede nun zurück zu den Cookies. Das Konzept des Cookies wird demnächst volljährig, es handelt sich ursprünglich um kleine Datenhäppchen, die eine Website einer Browserinstanz zur Speicherung übermittelt. Der Browser merkt sich diese Daten und schickt sie für einen festgelegten Zeitraum bei jeder weiteren Interaktion mit der Website dorthin zurück. Heute gibt es darüber hinausgehende Persistenzmechanismen auch für größere Datenmengen im Browser selbst sowie in verbreiteten Plugins, zum Beispiel im Flash Player.

Jeder Dienst in einer SaaS-Aggregation kann Cookies setzen und mit Hilfe dieser Cookies Daten über das Nutzerverhalten über alle Dienstnutzungen hinweg erfassen und sammeln. Die aggregierten Hilfsdienste erhalten dabei Daten aus verschiedenen SaaS-Anwendungskontexten verschiedener Anbieter und sind gleichzeitig für den Nutzer schwer zu identifizieren. Datenschützer stellen zu Recht die Frage, wie die Dienstnutzer unter diesen Bedingungen wirksam von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen können. Sie geben darauf aber die falschen Antworten.

De jure und traditionell wäre das Problem durch Kommunikation und Vereinbarungen des Nutzers mit jedem einzelnen involvierten Dienstanbieter zu lösen. Aggregierte Hilfsdienste als Auftragsdatenverarbeitung unter einer Vereinbarung zwischen dem Nutzer und dem Anbieter des Hauptdienstes zu subsumieren, wie es etwa für Analytics-Dienste diskutiert wurde,  vereinfacht die Sache wegen der Mehrfacheinbettung der Hilfsdienste in verschiedenste SaaS-Anwendungen nur scheinbar. Außerdem ändert sich permanent irgendwo irgendwas, so dass wir als Nutzer am Ende nur noch mit Zustimmen beschäftigt wären, wenn uns keine Generalvollmacht diese Mühe abnimmt. Erforderlich sind Lösungen, die die Architektur von SaaS-Mashups und der Client-Plattform als gegeben hinnehmen und darauf effektive Mechanismen für den technischen Datenschutz bereitstellen.

Cookies sind dabei nur ein wenig kritisches Randphänomen. Da sie clientseitig gespeichert werden, lässt sich ihre Speicherung und Übermittlung auch clientseitig effektiv steuern. Verbesserungsbedarf gibt es dabei vor allem in der Usability. Wünschenswert wäre zum Beispiel ein einheitliches User Interface für Einstellungen über alle Teilsysteme (Browser, Plugins, Apps, etc.) des Clientsystems hinweg anstelle getrennter, inkonsistenter Management-Schnittstellen für Cookies, Persistent DOM Storage und Flash-Cookies. Sinnvoll fände ich auch eine Möglichkeit, meine Datenschutzeinstellungen zwischen meinen fünf regelmäßig genutzten Clientsystemen zu synchronisieren statt fünfmal dasselbe konfigurieren zu müssen. Aber Clientsysteme und ihre Eigenschaften kommen in der Diskussion oft gar nicht vor. Soll ich ernsthaft mit dreiundzwanzig Diensten Vereinbarungen treffen, statt mir einmal eine Policy zusammenzuklicken, die meine eigene Technik für mich durchsetzt? P3P hatte zwar Schwächen und hat sich nicht durchgesetzt, aber damals hat man doch immerhin noch das Gesamtsystem angeschaut und eine Komponente an die richtige Stelle gesetzt, nämlich in den Client.

Mit formalisierten Rechtsritualen aus der Frühzeit der Alltags-IT ist das Problem nicht in den Griff zu bekommen. Gesucht sind effektive und benutzbare Mechanismen. Das ist die technische Sicht, die politische Dimension hat Benjamin Siggel vor einiger Zeit im Spackeria-Blog betrachtet.

Keksfontäne

Die einen haben Werbe- und Cookiefilter, die anderen interessiert es nicht. Was beim Besuch einer Website vor sich geht und wer dabei zuguckt, merkt deshalb kaum jemand. Bis dann mal ein Anlass kommt, mit einem jungfräulichen Browser auf eine Website zu schauen und dabei Cookies zu zählen, weil man’s für eine Metrik braucht, über die man gerade ein Paper schreibt. Der Untersuchungsgegenstand ist last.fm und nach wenigen Klicks sieht die Cookieliste so aus:

Firefox-Einstellungen mit den Cookies, die ein Besuch auf last.fm dort hinterlassen hat

Bereits der erste Seitenabruf liefert eine ganz ansehnliche Menge von Fremdcookies:

  • ice.112.2o7.net
    • s_vi
  • ad.doubleclick.net
    • test_cookie
  • googleads.g.doubleclick.net
    • id
  • lastfm.ivwbox.de
    • srp
    • i00
  • b.scorecardresearch.com
    • UID
  • dw.com.com
    • XCLGFbrowser .com.com

Klickt man dann noch ein wenig herum und hat dabei das Pech, ein Werbebanner von adrolays.de zu sehen, werden es noch viel mehr. Das Banner ist dann nämlich ein Metabanner, in dem mehrere Stück Werbung sinnlos(*) herumrotieren. Damit fängt man sich diese Cookies ein:

  • a.adrolays.de
    • RVS
    • RVSS
  • tracking.quisma.com
    • gmv30624
    • gmv31626
  • banners.webmasterplan.com
    • ASP.NET_SessionId
    • affili_4227pw
  • partners.webmasterplan.com
    • ASP.NET_SessionId
    • affili_0
    • affili_2906
  • http://www.active-srv02.de
    • apv_1
  • dslshop.vodafone.de
    • PV
  • http://www.vodafone.de
    • oshop
  • shop.vodafone.de
    • oshop
  • ad.zanox.com
    • zttpvc
    • zptpvc
  • ads4unitymedia.de
    • UM_chan_perm
    • UM_chan_temp
  • zx.alice-dsl.de
    • ALICA_HTB

Mit jeder Cookie-Quelle hat mein Browser unterwegs wenigstens einmal geredet. Kein Wunder, dass Werbeschleudern als Verbreitungsvektor für Schadsoftware immer beliebter werden (guckst Du Beispiel). Man muss ja nur irgendeine der 17 aufgezählten Sites hacken und erwischt damit unzählige Nutzer im Netz.

Unter anderem deswegen ist übrigens der gut gemeinte Sicherheitshinweis, man solle „aufpassen“ und sich von dunklen Ecken des Netzes fernhalten, völlig wirkungslos. Es kann einen überall treffen.

—————————-
(*) Irgend etwas wird man sich dabei wohl gedacht haben. Vielleicht so etwas: »Wir sind Scharlatane, aber wir haben das Glück, dass man uns nach der Zahl der Versuche und nicht nach dem Erfolg bezahlt. Warum vermieten wir ein und denselben Bannerplatz nicht einfach mehrfach und zählen den User, der das Banner ignoriert, jedem unserer Kunden einmal vor?« Das ist selbstverständlich nur eine Spekulation.