Schlagwort-Archive: Spackeria

Hände weg von Ostwind: Was Herr Weichert vom Wetterbericht lernen kann

Bedrohung, Datenschutz, IT, Propaganda, Risiko, Spackeria, Wolkenkuckucksheim, , ,

Das Wetter passiert einfach und wir passen uns an, damit es uns wenig beeinträchtigt. Meteorologen helfen uns dabei, indem sie das Wetter beobachten und uns Berichte und Vorhersagen liefern. So weiß ich heute schon, ob ich morgen mit dem Fahrrad zur Arbeit fahren möchte oder lieber nicht, und der Kollege vom THW kann einschätzen, ob er morgen zur Arbeit fährt oder mit Sandsäcken zum Deich. Datenschützer versuchen, anders zu orbeiten, doch das ergibt keinen Sinn.

Dem Gesetz nach ist der Datenschutz präventiv: personenbezogene Daten zu verarbeiten ist erst einmal verboten, solange nicht eine Reihe von Anforderungen erfüllt sind. In der Karteikarten-IT der 70er, in der er seine Wurzeln hat, war das kein Problem. Damals gab es noch kein Internet mit emergenten Diensten für Milliarden von Nutzern, experimenteller Softwareentwicklung im Produktivbetrieb, mit sozialen Graphen und statistischen Inferenzmodellen über große Datenmengen. Als riskant galt die damals noch junge elektronische Datenverarbeitung als solche, der man folglich personenbezogene Daten nur bedingt und kontrolliert zugänglich machen wollte.

Dem Internet konsequent Daten vorzuenthalten, ist heute weder praktikabel noch nützlich: nicht praktikabel, weil das Internet nichts anderes tut als Daten zur Verarbeitung an einen anderen Ort zu transportieren, und nicht nützlich, weil übertriebene Datensparsamkeit das persönliche Lebensrisikoprofil nur geringfügig beeinflusst. Umfang und Vielfalt der Datenverarbeitung laufen der bedächtigen Abwägung von Nutzen und Risiken in immer schnelleren Schritten davon – ohne dass wir deswegen alle stürben.

An die bloße Tatsache, dass Daten anfallen und genutzt werden, können wir unser Risikomanagement nicht mehr anknüpfen, sonst würden wir uns zu oft und zu lange mit Irrelevantem beschäftigen. Stattdessen müssen wir schnell und effizient tatsächliche Risiken identifizieren, den Rest vorerst ignorieren und Einschätzungsfehler später erkennen und behandeln. Das wäre ein beobachtender, risikoorientierter Datenschutz, der die Verarbeitung personenbezogener Daten grundsätzlich als gegeben hinnimmt und – abgesehen von einigen Grundregeln zur Abwicklung – nur dort eingreift, wo sich besondere Risiken zeigen.

Datenverarbeitung im Internet findet wie das Wetter einfach statt und lässt sich nur begrenzt beeinflussen oder gar verbieten. Wo sie uns stark beeinträchtigt, müssen wir etwas tun (oder lassen). Überall sonst können wir sie einfach hinnehmen.

In ihrer Öffentlichkeitsarbeit gehen prominente Datenschützer längst reaktiv vor: je offensiver die Facebooks und Googles dieser Welt eine Neuerung bewerben, desto lauter werden auch die amtlichen Warnungen. Der Ansatz ist richtig, aber fehlerhaft umgesetzt. Risikoorientierte Reaktionen müssen dort ansetzen, wo sich relevante und beeinflussbare Risiken empirisch zeigen. Wir haben keine Anhaltspunkte dafür, dass die PR bekannter Internet-Unternehmen mit diesen Risiken korreliert ist und sich als Auslöser für Datenschutzreaktionen gut eignet. Im Gegenteil, wir bekommen vom immer dieselbe Information: Hier ist etwas neu, seht Euch vor!

Man stelle sich vor, Wettervorhersagen gäbe es nur bei Ostwind sowie bei Sprühregen, und jedesmal erklärte uns ein Wetterbeauftragter, welche Gefahren das Wetter so mit sich bringt. Solche Wetterberichte wären nutzlos, sie kämen zur falschen Zeit und mit dem falschen Inhalt. Datenschützer informieren mich an zufälligen Zeitpunkten über allgemeine Gefahrensvisionen. Damit kann ich nichts anfangen.

Anstelle solcher Nachrichten vom Redundanzbeauftragten bekäme ich gerne eine Risikobewertung für mein Nutzungsprofil. Was droht mir voraussichtlich, wenn ich das Internet so nutze, wie ich es eben tue? Wie groß ist das Risiko absolut und im Vergleich? Welche Entscheidungsoptionen haben den größten Einfluss auf meine Risiken? Welche Risiken sind hoch, ohne dass ich sie beeinflussen kann? Statt nachrichtengetriggert immer denselben Teufel an die Wand zu malen, der in meinem Alltag keine Entsprechung findet, könnten sich Datenschützer nützlich machen, indem sie mir regelmäßig fundierte Bewertungen liefern, die ich auf mich und mein Tun beziehen kann.

Meteorologen informieren mich heute darüber, mit welchen Bedingungen ich morgen zu rechnen habe. Manchmal warnen sie auch; dann haben sie dafür einen Anlass und sie stufen ihre Warnung je nach Risiko ab. Diese Art der regelmäßigen Information ist nützlich für mich. Als Grundlage meiner informationellen Selbstbestimmung benötige ich ähnliche Nachrichten. Ich möchte wissen, wie sich einige grundlegende Parameter voraussichtlich entwickeln, um mich darauf einstellen zu können. Warnungen und besondere Unterstützung brauche ich nur im Ausnahmefall; dann, und nicht bei Sprühregen oder Ostwind, darf von mir aus gerne das Cyber-THW mit Datensandsäcken anrücken.

Das Personalchefargument

Angst, Datenschutz, Geschäft, Propaganda, Spackeria, , ,

Kommentarrecycling (dort im Spamfilter hängengeblieben):

Aus Diskussionen über öffentliche persönliche Informationen ist der googelnde Personalchef kaum wegzudenken. Gestritten wird dann darüber, was er denn nun sehen oder nicht sehen soll, damit dem Verkäufer eigener Arbeitskraft nichts schlimmes passiere. Gerne malt man sich phantasievoll die möglichen Folgen verstaubter Partyfotos aus, das gehört zu den Standards solcher Diskussionen. Doch es gibt ein grundlegendes Problem mit dem googelnden Personalchef: das Personalchefargument ist falsch, weil es von falschen Voraussetzungen ausgeht. Auf die Feinheit, ob der Personalchef nun etwas finden soll oder lieber nicht, kommt es dabei nicht an. Im Gegenteil, die Beliebigkeit in diesem Aspekt deutet auf ein grundlegendes Problem in den Axiomen hin. Wer mit einem falschen Satz von Axiomen anfängt, kann damit bekanntlich alles und das Gegenteil begründen.

Das Personalchefargument unterstellt als – regelmäßig unausgesprochene – Voraussetzung ein Unterwerfungsverhältnis zwischen Unternehmen („Arbeitgebern“) und für sie Arbeitenden („Arbeitnehmern“). Der Arbeitnehmer habe sich dem Arbeitgeber wohlgefällig zu verhalten, folgt daraus. In dieser Einseitigkeit ist das Modell falsch. In Wirklichkeit gibt es einen Arbeitsmarkt. Wie jeder andere Markt führt der Arbeitsmarkt führt der Arbeitsmarkt Parteien zusammen, die jeweils ihre eigenen Interessen verfolgen, und lässt sie Geschäfte zum beiderseitigen Nutzen machen. Dabei muss jeder dem anderen entgegenkommen, um seinen angestrebten Nutzen zu realisieren. Ich muss Zeit opfern, um Geld zu verdienen; eine Firma muss Geld opfern, um meine Zeit und meine Fähigkeiten zu bekommen. In der Ökonomie drückt man alles in Geld aus; im richtigen Leben spielen Faktoren wie das Betriebsklima auch ohne explizite Umrechnung eine Rolle.

In einem idealen Markt gibt es keine Ungleichgewichte, keine Seite kann den Markt über ihre Teilnahme hinaus zugunsten der eigenen Interessen beeinflussen. In der Realität greift man zuweilen regulierend ein, wo sich ein Markt zu weit von diesem Ideal entfernt. Regulierende Eingriffe können auch deshalb nötig sein, weil einige der theoretischen Eigenschaften idealer Märkte gar nicht realisierbar sind, zum Beispiel unendlich viele Teilnehmer auf beiden Seiten.

Das Personalchefargument ignoriert die Gegenseitigkeit des marktwirtschaftlichen Austauschs. Es postuliert Verhaltensregeln für Arbeitende, aber keine für Unternehmen, als gäbe es ein Kartell der Arbeitgeber. In Wirklichkeit muss aber jede Seite der anderen entgegenkommen, sonst finden keine Geschäfte statt, und was in einer Paarung von Marktteilnehmern nicht funktioniert, kann in einer anderen zum guten Geschäft werden.

Es mag also durchaus vorkommen, dass Personalchefs Saufbilder aus dem Internet in ihren Entscheidungen berücksichtigen. So wie es auch vorkommt, dass Firmen ihre Entscheidungen auf Horoskope oder graphologische Gutachten stützen. Das bedeutet dann aber nicht, dass jemand keine Arbeit findet, sondern lediglich, dass in einer bestimmten Konstellation kein Geschäft zustandekommt. Sind die Gründe dafür irrational, so ist das sogar zum Schaden des irrational Handelnden.

Eine Voraussetzung für einen gut funktionierenden Markt ist übrigens Transparenz: jeder Teilnehmer soll alle für rationale Entscheidungen relevanten Preise und Qualitätsmerkmale kennen. Die richtige Schlussfolgerung aus dem Personalchefargument ist deshalb nicht, dass jeder Arbeitende sein Online-Image zu polieren habe, sondern dass neben unseren Saufbildern auch die Dreckecken der Unternehmen ins Netz gestellt gehören. Wenn ich mich bei einem Unternehmen bewerbe, bewirbt sich gleichzeitig das Unternehmen bei mir. Da möchte ich schon etwas über seine Vergangenheit erfahren, und die Sommerfeste und Weihnachtsfeiern sind dabei minder relevant.

Missverständnis

Datenschutz, Philosophie, Rechtsabteilung, Regierungsviertel, Spackeria, Wolkenkuckucksheim, ,

Kommentarrecycling:

LeVampyre schreibt sich einen Wolf um zu erklären, warum sie Datenschutz gut und die Spackeria doof findet. Was sie schreibt, fühlt sich irgendwie richtig an, geht aber am Thema vorbei. Ihrem Text fehlt ein Begriff und damit der Kontext: informationelle Selbstbestimmung. Datenschutz ist nur ein Mittel zum Zweck. Wer »den Mißbrauch von Daten (…) unter Strafe stellen« möchte, braucht erst einmal einen Rahmen, in dem sich Missbrauch definieren lässt. Diesen Rahmen bildet nun nicht der Datenschutz als Selbstzweck, sondern die informationelle Selbstbestimmung als Idee: Jede soll Herrin ihrer persönlichen Informationen und Daten sein.

Informationelle Selbstbestimmung ist der Zweck, Datenschutz nur ein Instrument dazu. Vergisst man den Zweck, während man die Anwendung des Instruments optimiert, kommt Paternalismus heraus. Dann bestimme nicht mehr ich, was mit meinen Daten geschieht, sondern Beauftragte, Minister oder die Subkultur meiner Peer Group. Wenn ich Google, Facebook oder dem ganzen Internet bewusst und absichtlich Daten zur Verfügung stelle, ist das weder ein Datenverbrechen der anderen noch meine eigene Dummheit, sondern zuallererst mein gutes Recht. Der Datenschutz muss mich unvoreingenommen dabei unterstützen, dieses Recht auszuüben, ganz gleich, ob ich etwas verschweigen oder etwas mitteilen möchte.

Gleichzeitig vollziehen sich grundlegende Änderugen in der Art und Weise, wie wir – und Unternehmen – Daten verarbeiten und nutzen. Die spezifischen Regelungen des Datenschutzes stammen aus einer anderen Ära und sie können mit diesen Änderungen nur ungenügend umgehen. Das gilt im Guten wie im Schlechten: die endlose Diskussion um den Personenbezug von IP-Adressen zum Beispiel ist einerseits irrelevant für Google und Facebook, andererseits nervig für alle, die sich damit auseinandersetzen müssen.

Nach meinem Verständnis treiben diese beiden Aspekte die Spackeria, der Mismatch zwischen Idee und Umsetzung sowie der Mismatch zwischen Konzept und Realität. Das Ziel der Spackeria ist nicht, die Informationelle Selbstbestimmung abzuschaffen, sondern den Datenschutz als Mittel und Werkzeug der Realität anzupassen.

Cookies, Clients und die Cloud

Datenkrake, Datenschutz, Forschung, Freundlich zum Nutzer, Regierungsviertel, Spackeria, Wolkenkuckucksheim, Zeitmaschine, , , , , , , , ,

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.