Archiv der Kategorie: Datenschutz

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.

Scheinalternative Anwendungszoo

In Baden-Württemberg laufen einige Vereine und Verbände weiter Sturm gegen den Einsatz von Microsoft-Produkten in Schulen als handle es sich dabei um von Bill Gates persönlich verimpfte atomgetriebene Tunnelbahnhöfe der fünften Generation. Neben ätherischen Ideen wie WeltSchulfrieden, Datenschutz und digitaler Souveränität sowie abstrusen Prägungstheorien führen die Vereine als Argument auch angebliche Alternativen an (PDF):

„Mit Moodle (Lernplattform), BigBlueButton (Videokonferenzsystem), LibreOffice (Bürosoftware), Thunderbird (Mailprogramm) und Nextcloud (Dateiablage und Kooperation) stehen allen Schulen Anwendungen zur Verfügung, die den Funktionsumfang von MS 365 abdecken oder übertreffen.“

Eine Sprecherin des Kultusministeriums zitiert dagegen positive Erfahrungen und findet es „verwunderlich, dass die Verbände in ihrer gemeinsamen Stellungnahme die Bedürfnisse der Schulen und Praktiker vor Ort offenbar nicht zur Kenntnis nehmen und die Realitäten des Alltags verkennen.“ Ich teile ihre Verwunderung nicht, denn die Ansichten der Aktivisten lassen sich zwanglos mit einem engen Erfahrungshorizont erklären. Anscheinend hat keiner von ihnen in den letzten zehn Jahren eine moderne Office-Installation aus der Nähe gesehen.

Wer Microsoft Office hört, denkt zuerst an Word, Excel und PowerPoint. Kein Wunder, denn aus diesen Produkten schnürte Microsoft vor gut drei Jahrzehnten sein erstes Office-Paket. Bis heute sind sie in jeder Version enthalten, doch die Hauptrolle spielen sie nicht mehr. Microsoft Office heißt heute: Outlook und Skype for Business und OneNote und Teams sowie im Hintergrund in einer herkömmlichen On-Premise-Installation Exchange, SharePoint und Active Directory. Und das ist zusammen kein Zoo aus einzelnen Anwendungsgehegen, sondern eine integrierte Lösung, ein digitales Gondwanaland.

Eine Besprechung mit Microsoft Office geht ungefähr so: Zuerst sagst du Outlook, dass du gerne Leute einladen würdest, und suchst dir die Teilnehmer aus dem Adressbuch aus. Dein Adressbuch weiß, wo das Active Directory steht, deshalb findest du da jeden aus deiner Organisation. Outlook schaut dann selbständig in die einzelnen Kalender und schlägt dir Zeiten vor, die allen passen. Du schreibst deinen Einladungstext und klickst auf den Skype-Button, der einen Block mit den Zugangsdaten fürs Meeting in deine Nachricht einfügt. Das ist alles. Kein Wechsel zwischen Programmen, keine mentale Checkliste erforderlicher Fleißarbeiten – du schreibst einfach eine Einladung, der Rest geht mehr oder weniger von selbst. Wenn nicht gerade Pandemie ist und alle zu Hause bleiben, kannst du im Vorbeigehen auch einen freien Besprechungsraum suchen und reservieren.

Genauso unkompliziert legst du aus deinem Kalender einen Notizzettel in OneNote an, entweder für dich alleine oder auf dem Sharepoint-Server für alle. Auf diesem Notizzettel erscheinen von selbst die Metadaten zur Besprechung – Betreff, Datum, Uhrzeit, Teilnehmerliste und so etwas — und dann kannst du oder könnt ihr loslegen und zum Beispiel die Agenda entwerfen. Dir fällt dabei ein, dass du zur Vorbereitung unbedingt noch etwas erledigen musst? Kein Problem, aus OneNote heraus kannst du deine Outlook-Aufgabenliste befüllen und aus der Aufgabenliste kommst du selbstverständlich auch zurück zum Ursprung und ob du deine Aufgabe in Outlook oder in OneNote als erledigt abhakst, bleibt dir überlassen.

Kurz bevor die Besprechung losgeht, meldet sich Outlook mit einer Erinnerung. Daraufhin beginnst du nicht etwa hektisch im Kalender und deiner E-Mail nach den Einwahldaten zu suchen, sondern du klickst einfach den Beitreten-Button im Erinnerungsfensterchen an und setzt dein Headset auf, während Skype for Business die Verbindung aufbaut. Während der Besprechung kommt dann vielleicht mal PowerPoint zum Einsatz oder Excel oder was auch immer man gerade zum Arbeiten braucht. Das Protokoll schreibst du in OneNote, das dir die im Skype-Meeting erschienenen Teilnehmer in der Liste selbständig ankreuzt, damit du dich auf Wichtigeres konzentrieren kannst. Du berichtest im Meeting von einem Telefonat letzte Woche und kannst dich nicht mehr erinnern, wer dich da angeskypet hat? Guckst du Outlook, das merkt sich deine Chats und Anrufe aus Skype for Business.

Du bist oft unterwegs und willst lieber mit dem Smartphone? Dann nimmst du halt Outlook und OneNote und Skype for Business für Smartphones. So wird nicht nur die Cloud als Backend auf einen Schlag plausibel, sondern du bekommst auch noch gratis Office Lens dazu, das dir  Whiteboards und Flipcharts und Visitenkarten und Dokumente nach OneNote fotografiert und sie dabei entzerrt und zuschneidet. Und ja, wenn es sich um Drucksachen handelt, macht OneNote unaufgefordert OCR und du kannst später nach dem Inhalt suchen.

Das, und nicht Word/Excel/PowerPoint, ist ein zeitgemäßes Officepaket: eine integrierte Lösung für die Organisation, Kommunikation und Zusammenarbeit im Arbeitsalltag. Wer ganz oder teilweise im Manager Schedule arbeitet, viele verschiedene Vorgänge im Blick behalten muss oder aufgrund seiner Rolle mit vielen verschiedenen Menschen zu tun hat, erleichtert sich seine Arbeit damit ungemein. Gelungene Integration kommt unauffällig daher, hat jedoch einen großen Nutzen, denn sie beseitigt Reibungsverluste und Hürden. Fürs Wesentliche bleibt mehr Zeit, die Kommunikation und Zusammenarbeit läuft rund.  Dabei habe ich Microsoft Teams mangels eigener Erfahrung damit noch nicht einmal berücksichtigt.

In vielen Unternehmen funktioniert das so. Richtig klar wird einem das vielleicht erst, wenn man es mal selbst erlebt hat – und dann südwestdeutschen Querdünkel von Dateiablagen und LibreOffice schwärmen hört. Solche Alternativen spielen nicht in derselben Liga und auch nicht in der nächstniedrigeren. Google Workspace spielt in derselben Liga, aber das würde ihnen ja genauso wenig gefallen.

Selbstverständlich könnte man sich vornehmen, Ähnliches auf der Grundlage von Open-Source-Software selbst zu entwickeln. Vorher möge man jedoch kurz überschlagen, wie viele Jahre Vorsprung Microsoft und Google haben, wie viele Milliarden an Investitionen in ihren Produkten stecken und wie viele voraussichtlich noch hinzukämen, bevor man sie eingeholt hätte. Fünf Milliarden aus einem Digitalpakt würden dort kein ganzes und auch kein halbes Jahr reichen.

Gewiss, in die Hände von Grundschülern gehört ein digitaler Büroarbeitsplatz nicht. In die ihrer Lehrerinnen und Lehrer dagegen schon und dann bitte ordentlich, nicht als Modell 601S. Lehrerinnen und Lehrer haben nämlich allerlei zu planen, zu kommunizieren und zu organisieren. Gibt man ihnen vernünftige Werkzeuge dafür, können sie sich genau wie Büroarbeiter besser aufs Wesentliche konzentrieren. Ein paar jugendfreie Funktionen wie einfach zu nutzende Konferenzschaltungen für improvisierten Fernunterricht fallen dabei fast von alleine mit ab und vielleicht kann auch die Redaktion der Schülerzeitung etwas mit zeitgemäßen Werkzeugen anfangen. Von mir aus kann die gerne jemand anderes als Microsoft oder Google liefern, wenn es denn jemand anderes kann. Solche Diskussionen müssen aber auf dem Stand der Technik geführt werden und nicht auf der Basis von Fake News. Stand der Technik sind integrierte Lösungen, die Arbeit erleichtern, und nicht zusammengewürfelte Sammlungen halbgarer Me-too-Produkte. Mal schnell für ein paar Euro Open-Source-Software aufzusetzen, die gerade auf der Anwendungsebene oft hinterherhinkt, rettet uns nicht.


P.S. (2021-01-17) Im Golem.de-Diskussionsforum findet User Oktavian diese schöne Metapher:
„Als Bauherr möchte ich ein Haus. Der Bauträger bietet mir ein Haus gebaut nach meinen Wünschen an. Du möchtest mir einen Bagger liefern, Steine, einen Kran und Dachziegel. Daraus kann ich mir bestimmt ein Haus bauen, aber dann brauche ich noch Bauarbeiter, einen Plan, Genehmigungen, ein Grundstück, einen Architekten, einen Statiker und habe das Risiko, dass alles nicht funktioniert. Was glaubst Du wohl, wessen Angebot ich reizvoller finde?“
Und auch sonst dreht sich die Diskussion dort um die hier angesprochenen Punkte.

Scheinalternative Manufaktur-EDV

„Es gibt sie noch, die guten Dinge“, wirbt ein Einzelhändler, der sich auf altmodische, handgefertigte Haushaltswaren spezialisiert hat. Wer es geil findet, einen Tischfernsprecher W 48 – außen Bakelit®, innen solide Nachkriegselektrik, Digitalkonverter separat erhältlich – in sein Wohnzimmer zu stellen oder den Rasen seines Anwesens mit einem handbetriebenen Spindelmäher kurz zu halten, wird dort zu gesalzenen Preisen fündig.

Nüchtern betrachtet ergibt solch ein Kauf wenig Sinn. In derselben Preisklasse bekommt man als Gegenwartstechnik ein Smartphone oder einen Mähroboter und damit viel mehr Leistung für sein Geld. Der bloße Kauf eines altmodischen Manufakturprodukts mag noch wie eine Geschmackssache wirken, in der man sich willkürlich so oder so entscheiden kann. Doch über die Nutzungsdauer betrachtet zahlt man beim Manufakturprodukt verglichen mit seinen zeitgemäßen Nachfolgern fortwährend drauf. Deswegen kaufen Menschen nur dann „die guten Dinge“, wenn ihnen diese Folgekosten egal sind, etwa weil es sich um ein Geschenk mit externalisierten Kosten handelt oder weil sie mit einem Statussymbol unaufdringlich Vermögen demonstrieren möchten.

„Es gibt sie noch, die guten Dinge“, behaupten auch Technik- und Kulturpessimisten, denen der Fortschritt zu schnell fortschreitet und ob das denn nötig sei und nicht am Ende unsere Jugend verdürbe. Die guten Dinge, das sind ihnen Telefonate statt Videokonferenzen, selbst betriebene Open-Source-Anwendungen, Endgeräte und Anwendungen ohne Telemetrie und dergleichen mehr. Der Rest der Welt hat sich derweil an Videokonferenzen gewöhnt, wartet sehnlichst darauf, dass öffentliche Einrichtungen wie Schulen und Ämter endlich in der IT-Gegenwart ankommen, und nutzt selbstverständlich Anwendungen und Plattformen aus der Steckdose.

Die angeblich guten Dinge ähneln ihren Vorbildern aus dem Reich der Haushaltswaren. Wäre das Telefon eine ebenbürtige Alternative zur Videokonferenz, gäbe niemand Geld für Videokonferenzdienste aus. Dass es doch alle tun, liegt daran, dass es sich eben nicht nur um eine Art Bildtelefon handelt, sondern um Anwendungen für multimediale 1:n- und m:n-Kommunikation. Wo das Telefon genügt, greifen Menschen von alleine zu diesem, aber das Telefon kann im Vergleich zur Videokonferenz ungefähr so viel wie ein Tischfernsprecher W 48 im Vergleich zum Smartphone.

Auch Telemetrie und Cloud Computing entspringen nicht etwa einem gemeinen Weltherrschaftsplan amerikanischer Überwachungskapitalisten, sondern schlicht technisch-ökonomischem Fortschritt, der selbst und autark betriebene Anwendungen nach und nach zu einem Thema für die Geschichtsbücher macht. Dahinter steckt ein Prozess der Kommoditisierung, den jede Infrastrukturinnovation durchläuft. Anwendungen wandern im aus denselben Gründen von eigenen Servern in die Cloud, aus denen einst Dampfmaschinen in Kraftwerke und die Inhalte von Sparstrümpfen auf Bankkonten wanderten: Weil es möglich wurde und sich als effizienter erwies.

Die Vorteile sind offensichtlich. Dieses Blog hier zum Beispiel läuft komplett in der Cloud, bei wordpress.com. Ich muss mich um nichts anderes kümmern als die Inhalte: keine Server betreiben, keine Software installieren, keine Updates einspielen, kein Backup machen, nicht nach Einbrüchen aufräumen. Ich muss mir nur mein Passwort merken und, wenn ich es schön haben möchte, jedes Jahr ein paar Euro bezahlen. Alles selbst zu machen, wäre in der Summe teurer bei einem schlechteren Ergebnis, deshalb lasse ich das.

Dass dieses Geschäft funktioniert, liegt an Skaleneffekten: Durch Massenproduktion sinken die Kosten pro Stück. WordPress.com betreibt mein Blog nicht auf dieselbe Weise, wie ich es tun würde, also mit einem dedizierten und individuell administrierten Server, sondern auf einer eine Plattform mit Millionen von Blogs und Benutzern. Die Grenzkosten für ein einzelnes Blog verschwinden praktisch. Deshalb kann wordpress.com jeden Aufwand unterbieten, den ich für die Leistung „funktionierendes Blog“ in derselben Qualität betreiben müsste. Manufaktur ist teurer als Massenproduktion, in der Anschaffung wie im Betrieb.

Der Trend zum Software-Service betrifft nicht nur Anwendungen, sondern auch das, was wir früher Betriebssystem nannten und was heute den Charakter eine Managed Platform hat. Früher baute man seine Computersysteme selbst: schaffte Hardware an, installierte Betriebssysteme darauf und schließlich Anwendungsprogramme, organisierte den Betrieb des teuren Geräts zum Beispiel mit regelmäßigen Datensicherungen und Virenscans. Wer wollte, konnte den Computer später für einen anderen Zweck verwenden, indem er diesen Prozess mit demselben oder einem anderen Betriebssystem und neuen Anwendungen erneut begann.

Heute sind Geräte austauschbar und Betriebssysteme eine Dienstleistung. Wir haben Benutzerkonten bei Apple/Google/Microsoft, die wir mal mit diesem, mal mit jenem Gerät nutzen. Kommt mal ein Gerät weg, tritt man es online aus allen Diensten raus, stellt ein neues hin und macht dort weiter, wo man aufgehört hatte. An der Software der Endgeräte herumzubasteln, macht noch weniger Sinn als ein eigener Anwendungsbetrieb.

Themen wie Telemetrie in Windows und Office oder auch Apples automatischer Sicherheitscheck beim Programmstart, der neulich einen kurzen Aufruhr auslöste, muss man in diesem Kontext betrachten. Es hat keinen Sinn mehr, sich über „nach Hause telefonierende“ Software zu erregen. Der Normalfall ist, dass Software in der Cloud läuft und dort betreut und weiterentwickelt wird; teilautonome Endgeräte werden stattdessen als Näherungslösung so an die Cloud angeschlossen, dass man ihren Benutzern trotzdem Stress mit der Systemadministration ersparen kann. Und das ist gut, denn inzwischen kann man auch Laien einen Internetapparat anvertrauen, ohne ständig auf sie aufpassen zu müssen.

In der konsequentesten Umsetzung bekommt man am Ende einen Thin Client wie Googles Chromebook als Interface zur Cloud, bei dem lokale Anwendungen keine Rolle mehr spielen. Dann bereitet das einzelne Gerät praktisch keinen Administrationsaufwand mehr, weil es nur noch einen Browser booten muss, der durch ein Benutzerlogin an einem Cloudservice personalisiert wird. Damit lässt sich zum Beispiel ein Laptopverleih organisieren, wie ihn die ULB Darmstadt anbietet. Einige sind der Ansicht, dass dies auch für den Schulbetrieb genau der richtige Ansatz sei.

Wer unbedingt in einem Gefühl digitaler Souveränität schwelgen möchte, kann das alles auch nachbauen. Das wird jedoch voraussichtlich ein teures und zeitraubendes Projekt. Man bekommt eben nicht dasselbe, indem man mal schnell einen Linux-Server mit ein paar Open-Source-Paketen aufsetzt, sondern müsste schon das ganze System und dessen Betrieb replizieren und außerdem in die Weiterentwicklung investieren wie ein etablierter Cloudversorger. Das kann man tun, aber es ist nicht die beste Idee, wenn man gerade etliche Jahre verschlafen hat und einen nun auch noch eine Viruspandemie zu schnellem Handeln zwingt. Obendrein hält ein in der Hinterhofwerkstatt aus Subprime-Software zusammengefrickeltes System in Sachen SIcherheit und Datenschutz nicht unbedingt, was seine Verfechter versprechen. So fiel die häufig genannte Videokonferenzsoftware Big Blue Button kürzlich mit langen Reaktionszeiten auf gemeldete Sicherheitsmängel auf. Dort hätte man also nachzuarbeiten.

Es gibt sie noch, die guten Dinge, doch sie sind gar nicht gut, sondern alt, rückständig, umständlich produziert. Dennoch empfohlen werden sie als Scheinalternative von Akteuren, denen niemand die Kosten ihrer Ratschläge in Rechnung stellt, die sich jedoch eigene – nicht-monetäre – Gewinne erhoffen. Datenschutzbeauftragte sollen schnellen Fortschritt in der IT nicht fördern, sondern bremsen und ihre Arbeit beruht auf Gesetzen und Traditionen, welche die Datenverarbeitung unter den Generalverdacht der Grundrechtsgefährdung stellen. Vereinsinformatiker können sich umso wichtiger fühlen, je komplizierter Informationstechnik zu nutzen ist, je exklusiver also ihre Expertise bleibt. Verbraucherschützer benötigen einen Antagonisten, und sei es ein erfundener wie die „Prägung“ von Schülerinnen und Schülern auf Microsoft-Produkte und die angebliche Vermarktung ihrer Verhaltensdaten durch Microsoft. All jene, die tatsächliche Kosten gegen den tatsächlichen Nutzen abwägen müssen, sind mit zeitgemäßen Services besser bedient als mit Manufakturalternativen. Wer nicht möchte, dass deren Anbieter Microsoft oder Google heißen, muss konkurrenzfähige Alternativen als Dienstleistung anbieten und nicht Software zum Selbermachen empfehlen.

A (Trolley Problem) Trolley Problem

Algorithm ethics as a trolley problem:

There is a runaway trolley barrelling down the railway tracks. Ahead, on the tracks, there is a trolley problem waiting. The trolley is headed straight for it, burdening you with an ethical dilemma to decide:

[There is a runaway trolley barrelling down the railway tracks. Ahead, on the tracks, there are five people tied up and unable to move. The trolley is headed straight for them. You are standing some distance off in the train yard, next to a lever. If you pull this lever, the trolley will switch to a different set of tracks. However, you notice that there is one person on the side track. You have two options: (1) Do nothing and allow the trolley to kill the five people on the main track. (2) Pull the lever, diverting the trolley onto the side track where it will kill one person. What is the right thing to do?]

You are standing some distance off in the train yard, next to a lever. If you pull this lever, the trolley will switch to a different set of tracks. However, you notice that there is an equivalent trolley problem on the side track. This other trolley probem will be decided not by you, it will be decided by an algorithm.

You have two options:

  1. Do nothing and allow the trolley to make you the sad hero of a trolley problem.
  2. Pull the lever, diverting the trolley onto the side track where an algorithm will take care of the problem job for you.

What is the right thing to do?

(Trolley problem description based on Wikipedia. Reductio ad absurdum inspired by this tweet.)

Dialektik des Datenschutzes

Bereits das bloße Gefühl, beobachtet zu werden, könne Unwohlsein verursachen und Menschen dazu bringen, ihr Verhalten zu ändern, argumentieren Datenschutzaktivisten gerne. Selbst der bloße Anschein einer Beobachtung sei daher problematisch.

Dieselben Aktivisten finden es völlig in Ordnung, wenn nicht gar erforderlich, mit riesigen Schildern auf Videokameras zur Beobachtung des öffentlichen Raumes hinzuweisen, auf dass auch niemand den gebückten Gang vergesse. Passt das zusammen?

***

Wenn von Überwachungs- und Repressionstechnologie die Rede ist, denken wir an Videokameras, an künstliche Intelligenz, an Drohnen und so weiter. Auch Maßnahmen dagegen verhandeln wir oft in Gestalt technischer oder organisatorischer Bausteine wie Anonymisierung, Verschlüsselung und so weiter.

In den chinesischen Healthcode-Systemen, die zur Bekämpfung der jüngsten Corona-Pandemie aufgebaut wurden, spielen QR-Codes eine wichtige Rolle. QR-Codes als technischen Baustein werden jedoch praktisch nie thematisiert, wenn es um Datenschutz oder die Auswirkungen neuer Technik auf unsere Freiheit geht. Warum nicht?

***

Videokonferenzen werden von Datenschützern kritisch beäugt. Wer nicht davon lassen kann, muss allerlei Datenschutzvorschriften beachten. Auf klassische Weise telefonieren darf man einfach so. Woran liegt das und wäre es auch so, hätte man den Datenschutz vor dem Telefon erfunden und nicht umgekehrt?

***

Silicon-Valley-Konzerne gelten hierzulande traditionell als „Datenkraken,“ als von „Datensammelwut“ befallene Halbverbrecher. (Obendrein bildeten sie Monopole und würden zu mächtig, heißt es, aber das ist kein Datenschutz-Thema.) Dagegen, dass Apple und Google als Plattformbetreiber das Herzstück der Corona-Warn-App bereitstellen, regt sich jedoch kein Widerspruch. Ebenso wenig dagegen, dass an ihrer Lösung kaum ein vernünftiger Weg vorbeiführt. Sind sie doch nicht so böse, wie immer wieder behauptet wurde, oder haben wir den Kampf verloren?

***

Der Datenschutz verdankt seine Entstehung dem Aufkommen des Computers. Heute widmen sich Datenschützer mit Hingabe auch mit Formen der Datenverarbeitung, die damals längst normal waren, wie der Fotografie oder der Erfassung von Kontaktdaten mit handgeschriebenen Formularen und Listen. Gehen sie sich damit nicht manchmal selbst auf den Wecker?

***

Die Wichtigkeit des Datenschutzes wird in Deutschland und Europa gerne mit dem Holocaust begründet, den die Erfassung persönlicher Daten erleichtert, wenn nicht gar ermöglicht habe. Datenschutz diene nicht zuletzt dazu, eine Wiederholung zu verhindern.

Man könnte ganz ähnlich über die Bedeutung von Landkarten im Zweiten Weltkrieg reden, ihre Schlüsselfunktion in der Zerstörung von Warschau, Stalingrad, Coventry, Rotterdam und vieler anderer Städte und in der Kriegsführung generell. Dies tut jedoch niemand. Meinen wir das Argument ernst oder ist es nur vorgeschoben, um sich unangenehmen Diskussionen zu entziehen?

***

Wer als Datenschützer hartnäckig vor der Nutzung von WhatsApp warnt, ohne jemals dadurch verursachte Schäden nachweisen zu können, genießt gesellschaftliches Ansehen.

Wer als Bürger hartnäckig von den Gefahren des Mobilfunks raunt, ohne jemals dadurch verursachte Schäden nachweisen zu können, gilt als irrationaler Paranoiker und Verschwörungstheoretiker.

Gibt es dafür eine andere nachvollziehbare Erklärung als unterschiedliche Positionen der jeweiligen Sprecher in der gesellschaftlichen Machthierarchie?

***

Seit der EuGH das Abkommen „Privacy Shield“ zwischen der EU und den USA gekippt hat, ist die Übermittlung personenbezogener Daten in die Vereinigten Staaten von Amerika nicht mehr ohne weiteres zulässig. Auf diese Weise werden die Rechte und Freiheiten der betroffenen Europäerinnen und Europäer geschützt.

Weiterhin keinen Einschränkungen unterliegt hingegen – abgesehen von vorübergehenden Regelngen aufgrund der COVID-19-Pandemie – der Export ganzer Personen ins Ausland durch Fluggesellschaften und Reiseveranstalter. Gefährdet die Übermittlung unserer Daten in die USA unsere Rechte und Freiheiten stärker als eine Reise dorthin?

***

Deutsche Datenschützer und europäische Politkommisarinnen preisen Datenschutz als Digitalisierungsmotor und Wettbewerbsvorteil an.

Datengetriebene Unternehmen wie Verisk, ein amerikanischer Anbieter von Risikomanagementlösungen insbesondere für Versicherungen, benennen neben dem Verlust des Datenzugangs verschärfte Datenschutzregulierung und die DSGVO als Geschäftsrisiken. Zugleich ist Irland mit seiner zahmen Datenschutzaufsicht ein beliebter Standort für die Europa-Niederlassungen von Internetunternehmen.

***

In Restaurants werden zurzeit Kontaktdaten der Besucher gesammelt, um die Kontaktverfolgung im Fall von Coronavirus-Infektionen zu erleichtern. Wenn die Daten schon einmal da sind, werden sie manchmal auch von der Polizei für Ermittlungen genutzt. Das ist wahrscheinlich legal.

Datenschützer protestieren. Sie protestieren jedoch nicht gegen diese – gesellschaftlich akzeptierte – Vorratsdatenspeicherung, sondern gegen die Nutzung der gespeicherten Daten durch die Polizei: Solche zusätzlichen Datennutzungen aus vergleichsweise nichtigen Anlässen schade der anscheinend sehr wertvollen Vorratsdatenspeicherung und untergrabe das Vertrauen der Bürgerinnen und Bürger in sie.

***

Gesundheitsämter in Baden-Württemberg dürfen im Rahmen der Kontaktverfolgung bei Coronavirus-Infektionen keine unverschlüsselten E-Mails an Kontaktpersonen schicken, es sei denn, ihnen liegt eine ausdrückliche Einwilligung vor. Eine Infrastruktur, über die Ämter mit allen Bürgerinnen und Bürgern verschlüsselt kommunizieren könnten, liegt nur theoretisch in Form des selten genutzten Dienstes De-Mail vor, so dass die Verwendung von E-Mail in diesem Zusammenhang praktisch ausgeschlossen ist.

Unverschlüsselte E-Mail ist bis heute die Regel, weil fast niemand ein Sicherheitsproblem hat, das sich durch E-Mail-Verschlüsselung adäquat und zu einem angemessenen Preis lösen ließe. Fast niemand hat also das Problem, das der Datenschutz hier zu lösen versucht.

***

Gesichtserkennung ist schlimmer als Rachepornos. Weil sie Begehrlichkeiten wecke.

CoronApp-News (2020-07-19)

Neue Regierungen bekommen hundert Tage Zeit, neue Apps nur vier Wochen:

  • Einen Monat nach ihrem Start zieht das RKI eine positive Zwischenbilanz und meldet knapp 16 Millionen Downloads. Wie viele Menschen die App tatsächlich benutzen, bleibt unklar. Etwa 500 positiv Getestete hatten bisher die Möglichkeit, eine Warnung ihrer Kontakte auszulösen. Wie viele Warnungen an wie viele Kontaktpersonen tatsächlich verschickt wurden, weiß man jedoch nicht.
  • Die Entwicklungsarbeit an der Corona-Warn-App geht weiter. Neben Fehlern und den zugangsbeschränkenden Systemanforderungen der App – neben alten Smartphones bereitet auch das neueste iOS 14 Probleme – bleibt die Anbindung der Testlabore kritisch. Als Folge davon wurde noch kein einziger Corona-Test auf dem eigentlich vorgesehenen Weg per QR-Code in der App registriert. Die alternativen Meldewege führen zu Verzögerungen.
  • Zweifel gibt es weiter an der Verlässlichkeit der Bluetooth-Entfernungsmessung, die in die Risikobewertung von Kontakten einfließt. Auch funktionale Fragen tauchen immer wieder auf.
  • Auf sich warten lässt die EU-weite Integration der nationalen Warn-Apps. Auf der Smartphone- und Bluetooth-Seite gibt es wenig Integratioshindernisse zwischen jenen Apps, die ich auf das Exposure Notification Framework von Apple und Google stützen, doch die Vernetzung der Backends braucht offenbar etwas länger.
  • Langsam dämmert auch den Letzten, dass sich die Bundesregierung im April nicht so sehr für eine datenschutzfreundliche dezentrale Architektur entschieden hat, sondern tatsächlich wohl vor allem für das Framework von Apple und Google. Pragmatisch war das unter den gegebenen Umständen nahezu alternativlos, aber es handelt sich eben nicht um eine freie, souveräne Architekturentscheidung.
  • Zu guter Letzt bleibt jenseits der Coron-Warn-App das Thema Kontaktdatenerfassung in Restaurants etc. auf der Tagesordnung. Einige sind überrascht davon, dass in einigen Fällen die Polizei die gesammelten Daten für Ermittlungen nutzt, aber das ist wahrscheinlich erlaubt. Auf eine Erweiterung der Corona-Warn-App zur Erfassung solcher Besuche warten wir hingegen vergebens, ebenso auf einen flächendeckenden digitalen Ersatz für manuell ausgefüllte Formulare.

Bis nächstes Wochenende.

CoronApp-News (2020-07-12)

Eigentlich könnten wir uns in Sachen Corona-App zurücklehnen und abwarten, aber die Debatten gehen weiter:

Voraussichtlich wird es auch nächste Woche wieder Neues zu melden geben.

CoronApp-News (2020-06-21)

Habemus Appam! Vielleicht genau zur rechten Zeit, denn die Fallzahlen steigen wieder.

Wie angekündigt ist die Corona-Warn-App seit Dienstag verfügbar und wurde nach Angaben des RKI bis gestern mehr als zehn Millionen Mal heruntergeladen. Falls sie danach auch von allen aktiviert wurde, entspricht das einem Verbreitungsgrad von 13%, womit jeder 65. zufällige Kontakt erkannt werden könnte. Den Datenverkehr der App wollen die Mobilfunk-Provider kostenlos spendieren. Wie man die App aktiviert und benutzt, erklärt unter anderem Heise Online. Eine Datenschutzfolgenabschätzung wurde kurz vor der App selbst veröffentlicht.

Die Bundesregierung ist stolz wie Oskar, weil die Entwicklung seit der Entscheidung für Apple, Google, SAP und Telekom ziemlich gut funktioniert hat, und das Projekt wird auch von anderen gelobt. Jedoch verstummt die Kritik nicht ganz. Der Verein Digitalcourage hält die App für ein Plazebo mit Nebenwirkungen, das Twitter-Echo darauf fiel jedoch eher negativ aus. Der Chef des VZBV empfiehlt die App, warnt jedoch noch einmal vor App-gestützten Einlasskontrollen. Diese Befürchtung wurde zum Release vielfach geäußert, hat sich bislang jedoch offenbar kaum bewahrheitet. Alvar Penning, Jonas Höchst und Bernd Freisleben kritisieren die relative Offenheit der Entwicklung als halbseiden, da ein wichtiges Teilsystem von Apple und Google bereitgestellt werde und eben nicht offen sei. So ganz Made in Germany ist die App eben doch nicht und anderswo fühlt man sich gar von Apple und Google bevormundet.

Wie sehr wir uns vor der Corona-Warn-App fürchten und warum, untersucht der Der Lehrstuhl Sozialpsychologie: Medien und Kommunikation der Universität Duisburg-Essen mit einer Umfrage.

Die App-Entwicklung ging manchen zu langsam und verlief anfangs holprig, wenn nicht gar als Drama mit entgleister Debattenkultur. Im Vergleich zu anderen öffentlichen IT-Projekten erscheint der Weg zu App dennoch recht reibunglos. Allerdings blieb sich auch die Komplexität vergleichsweise gering, nachdem die Smartphone-Plattformen den Lösungsweg und zentrale Komponenten vorgegeben hatten.

Einige Probleme gibt es dennoch. So klagen die Gesundheitsämter seit dem Start der App über unzählige Anrufe verwirrter Nutzerinnen und Nutzer. Auch im Hintergrund läuft noch nicht alles rund, denn viele Testlabore und Gesundheitsämter müssen erst noch angebunden werden, um App-Nutzern direkt Testergebnisse übermitteln zu können. Hier macht sich der Digitalisierungsstau im Gesundheitswesen und in der Verwaltung bemerkbar.

Auch sonst ist die Entwicklung der Corona-Warn-App noch lange nicht abgeschlossen. Neben Meldungen über Fehler und Unzulänglichkeiten sammeln die Entwickler auch Ideen für weitere Funktionen und zeigen ihre – noch recht knappen – Pläne für künftige Verbesserungen. Auch die europaweite Integration der nationalen Lösungen steht noch aus und wird einige Schwierigkeiten mit sich bringen.

International steht Deutschland plötzlich als leuchtendes Beispiel da. Fast zeitgleich mit dem Start hierzulande musste Norwegen seine schon länger bereitstehende App Smittestopp wegen Datenschutzbedenken auf Eis legen. Amnesty International hielt die norwegische App für eine der gefährlichsten weltweit und stellte sie in eine Reihe mit denen aus Bahrain und Kuwait. Das brexitanische App-Projekt versinkt unterdessen im Chaos und verschiebt seinen Release-Termin auf den nächsten Winter. Nachdem eine von Apples und Googles Exposure Notification Framework unabhängige Lösung bereits im Testbetrieb war, setzt man nun doch auf die Plattform-Lösung und stuft zugleich die Priorität der App herab. Die französiche App StopCovid, die ebenfalls ohne das Framework auskommt, scheint eher ein Flop zu werden.

Zu guter Letzt hat der Chef eines mittelständischen Betriebs in Köln so viel Angst vor der App, dass er sie seinen Beschäftigten rundweg verbietet.

 

In der Doppelbotschaft verheddert

Wer WhatsApp oder Facebook nutze, könne bedenkenlos auch die Corona-Warn-App installieren, tönt es durchs Netz – das stimmt zwar vielleicht trotz der Bedenken um Einlasskontrollen, ist aber dennoch kein gutes Argument.

Einige Schlaumeier erklären uns gerade, wer WhatsApp et al. nutze, könne getrost auch die Corona-Warn-App installieren oder wer angesichts der Corona-Warn-App Überwachungsangst verspüre, müsse konsequenterweise auch auf WhatsApp et al. verzichten. Hier zum Beispiel:

und da und dort. Das ist nett gemeint, führt jedoch nicht weit, denn es handelt sich um eine widersprüchliche Doppelbotschaft. Ihre Adressaten sollen entweder die Harmlosigkeit der Corona-Warn-App anerkennen und dann auch WhatsApp benutzen dürfen, oder sie sollen die Gefährlichkeit von WhatsApp anerkennen und dann auf beide verzichten. Unausgesprochen, weil sie nicht so gut ins Argument passt, bleibt die Option, die Corona-Warn-App zu nutzen, WhatsApp jedoch nicht.

Wahrheitstabelle der Implikation WhatsApp → CWA

Formallogisch scheint zunächst alles in Ordnung. Es handelt sich um die Implikation: „wenn WhatsApp dann Corona-Warn-App“. Widersprüche tun sich erst beim Versuch auf, den so als falsch deklarierten Fall zu rechtfertigen, dass jemand WhatsApp nutzt, aber die Corona-Warn-App ablehnt. Das geht, aber man muss dazu diese Implikation zurückweisen. Mehrere Möglichkeiten bieten sich an.

Man könnte trotzig antworten, man wolle halt das eine und das andere nicht. Dabei stünde man immerhin mit beiden Beinen fest auf dem Boden der informationellen Selbstbestimmung, die genau diese Entscheidungsfreiheit gewährt und keine Begründung verlangt. Gehört man selbst nicht zur Gruppe derjenigen, die WhatsApp nutzen, aber die Corona-Warn-App ablehnen, könnte man auch mit der empirisch-statistischen Frage antworten, ob die angesprochene Gruppe überhaupt in einem nennenswerten Umfang existiere. Möglicherweise sind die meisten Aluhutträger tatsächlich so konsequent, auch einen anderen Messenger als WhatsApp einzusetzen, oder tragen ihren Aluhut erst, seit sie Telegram für sich entdeckt haben.

Man könnte auch analytisch antworten, die Verengung auf das Merkmal Datenschutz sei unangemessen, In Wirklichkeit handele es sich um eine mehrdimensionale Kosten-Nutzen- und Risiko-Nutzen-Abwägung, welche in diesem Fall so und in jenem anders ausfalle. Schließlich verspricht WhatsApp einen erheblichen persönlichen Vorteil, während der Nutzen der Corona-Warn-App vorwiegend als externer Effekt in der Gesellschaft eintritt.

Wer dezente Gemeinheit nicht scheut, kann zu guter Letzt auch sein Gegenüber im eigenen Argument einwickeln: Man habe jetzt jahrelang immer wieder die Gefahren von WhatsApp gepredigt, ohne dass viel passiert sein – wo solle nun die Glaubwürdigkeit herkommen, zumal man über die Corona-Warn-App auch noch das genaue Gegenteil  sage? Oder anders verpackt in Abwandlung des gestrigen Tagesthemen-Kommentars:

„Diejenigen, die die App kategorisch empfehlen, weil sie zu Recht keine Gefahren befürchten, sollten bitte auch mal kurz prüfen, ob sie WhatsApp oder Facebook ablehnen.“

Wendet das Gegenüber daraufhin ein, dies sei doch etwas völlig anderes, nickt man nur noch andächtig und sagt: „Genau.“ Wer mag, kann noch einen Treffer landen mit der Frage, wieso angesichts der Corona-Warn-App jetzt auf einmal die Gefahr und die (Un-)Zulässigkeit von Einlasskontrollen anhand der App diskutiert werde, während WhatsApp über ein Jahrzehnt nie jemanden auf diese Idee gebracht habe.

Nein, dass jemand WhatsApp nutzt, ist kein gutes Argument dafür, auch die Corona-Warn-App zu nutzen. Dass viele Menschen WhatsApp nutzen, ohne sich große Sorgen zu machen und wohl auch, ohne objektive Nachteile aufgrund mangelnden Datenschutzes zu erleiden oder zu verursachen, sollte uns hingegen Anlass sein, unser Verständnis und unsere Prioritäten nachzujustieren. WhatsApp und andere zeigen, dass Erfolg auch gegen die Kritik der Datenschützer möglich ist. Die Corona-Warn-App wird uns zeigen, wo die Grenzen mit dem Segen der Datenschützer liegen. Statt Populismus zu betreiben, sollten wir uns mehr mit den tatsächlichen, vieldimensionalen Erfolgsvoraussetzungen von Anwendungen beschäftigen und mit den Gestaltungsprozessen, die Anforderungen erkunden, abwägen und umsetzen.

CoronApp-News (2020-06-06)

Die Corona-App-Nachrichten der Woche:

Bis nächste Woche.

Nachtrag:

Datenschutz reicht nicht

Datenschutz gilt im Zusammenhang mit der Corona-Warn-App als überragend wichtig. Zugleich zeigt er jedoch gerade daran seine Grenzen.

Im engeren Sinn steht Datenschutz für Maßnahmen, die informationelle Selbstbestimmung ermöglichen. Mit einigen Ausnahmen soll jede selbst entscheiden dürfen, wer was über sie erfährt und zu welchen Zwecken ihre personenbezogenen Daten verwendet werden. Aus dieser klassischen Perspektive geht es vor allem um die Zugriffs- und Verwendungskontrolle von Daten. Der moderne europäische Datenschutz vertritt dagegen einen umfassenderen Anspruch und möchte allgemein Gefahren für die Rechte und Freiheiten natürlicher Personen durch die Datenverarbeitung abwehren. An Grenzen stößt er, wo nicht mehr das zentralisierte Sammeln und Auswerten von Daten die Auswirkungen des Technikeinsatzes bestimmt, Begriffe und Werkzeuge aber auf Daten fokussiert und damit der engen Sicht verhaftet bleiben.

Persönliche Geräte und ihre Anwendungen wie aktuell die Corona-Warn-App sind so ein Fall. Sie begleiten uns überallhin und interagieren mit uns, nicht nur reaktiv als benutzergesteuerte Geräte, sondern auch aktiv mit Nachrichten und Aufforderungen. Die Corona-Warn-App hat sogar ausdrücklich zum Ziel das Verhalten ihrer Benutzerinnen und Benutzer zu beeinflussen, denn diese sollen sich auf eine Nachricht der App hin in Quarantäne begeben. Eine auf den „Spion in der Tasche“ und mögliche Missbräuche zentraler Datensammlungen reduzierte Betrachtung wird den daraus resultierenden Fragen und Problemen nicht gerecht.

Der unnötigen zentralen Aufbewahrung personenbezogener Daten und dem Missbrauch zentral vorliegender Daten schieben die Corona-Warn-App und die zugrundeliegenden Plattformmechanismen von Apple und Google einen effektiven Riegel vor. Nur im Fall einer nachgewiesenen Infektion erhalten die zentralen Server überhaupt Informationen und dann nur über praktisch anonyme Kontakte der infizierten Person in einem begrenzten Zeitraum. Zur Massenüberwachung taugt das System daher kaum, weil dafür geeignete Daten gar nicht in ausreichendem Umfang anfallen.

Dieses Zugeständnis an den Datenschutz fällt leicht, denn das Wirkprinzip der Corona-Warn-App beruht eben nicht auf Überwachung, sondern auf gezielt übermittelten Verhaltensmaßregeln. Zu ihrer näheren Verwandtschaft gehören nicht Überwachungskameras, Datenbanken und die Rasterfahndung, sondern das Microtargeting der Online-Werbung und die Prompts, mit denen alle möglichen Apps um Aufmerksamkeit und Streicheleinheiten betteln. Aus dem Prinzip der teilautomatisierten Verhaltensbeeinflussung ergeben sich ungeklärte Fragen sowie Missbrauchsmöglichkeiten.

Ungeklärt bleibt bis heute, wie es für Kontaktpersonen nach einer Benachrichtigung weitergeht, wie etwa aus der Bitte um freiwillige Selbstisolation eine dafür nötige Arbeitsbefreiung wird und welche Konsequenzen es hat, wenn jemand in Kenntnis einer erhaltenen Warnung Kontakt mit anderen Menschen hat. Zugunsten der Freiwilligkeit mag man hinnehmen, dass Warnungen ignoriert werden, wenn der Selbstisolation Hindernisse im Weg stehen, zumal die herkömmliche Kontaktverfolgung parallel weitergeht. Folgenlos bleibt dies jedoch nicht, denn wenn die Warn-App den versprochenen Nutzen hat, führen ignorierte Warnungen zu vermeidbaren Ansteckungen, übrigens unabhängig davon, ob und wie die unnötig Angesteckten selbst die App nutzen. Von hier ist es nicht mehr weit zum Vorwurf der Körperverletzung, wenn jemand nach Erhalt und in Kenntnis einer Warnung Kontakte pflegt und dabei jemanden ansteckt. Vor der forensischen Untersuchung des betreffenden Smartphones schützt die Datensammelbremse des Systems dann wohl nicht mehr.

Gleichermaßen liege Missbrauchspotenziale im System selbst und nicht nur in seinen Daten. Bereits vielfach diskutiert und von einzelnen Politikern sogar befürwortet wurden dezentrale Kontrollen der App-Nutzung beispielsweise am Arbeitsplatz oder Supermarkteingang; das bekäme man mit der DSGVO vielleicht noch in den Griff. Aber auch die Kernfunktion – Kontakterfassung und Benachrichtigung – lässt sich zweckentfremden. Technisch gesehen erfasst die Corona-Warn-App gemeinsame Aufenthalte ihrer Benutzerinnen und Benutzer an einem Ort von einer gewissen Dauer. Dass es dabei um Ansteckungsrisiken mit dem Corona-Virus gehe, bleibt letztlich eine Konvention. Deren Einhaltung garantiert nicht das System selbst, sondern seine Anwendungsumgebung. Ohne große Umstände könnte man mit derselben technischen Infrastruktur all jene für zwei Wochen in Quarantäne bitten, die letzte Woche im Puff waren oder sich mit einem Datenschutzbeauftragten getroffen haben. Dass dies tatsächlich jemand versuchte und mehr noch, dass es ungestraft gelänge, halte ich in einem demokratischen Rechtsstaat für sehr unwahrscheinlich, aber dabei handelt es sich um externe Faktoren und nicht um inhärente Zwänge im System.

Was hier zu klären ist, reicht über den Horizont und Instrumente des klassischen Datenschutzes hinaus. Weder das allgemeine Datenschutzrecht noch der technische Datenschutz können alle Fragen, die eine Corona-Warn-App aufwirft, befriedigend beantworten. Ich schließe mich deshalb der verschiedentlich geäußerten Auffassung an, dass die Corona-Warn-App eine spezifische Rechtsgrundlage erfordert. Allgemeiner und auf lange Sicht stehen wir auch vor der Frage, nach welcher Regulierung zentral steuerbare, aber dezentral agierende Geräte- und Anwendungsökosysteme jenseits des Datenschutzes verlangen.

 

 

CoronApp-Links (2020-05-16)

Das Wetter ist zu schön, um das Wochenende vor dem Computer zu verbringen. Trotzdem hier eine Auswahl der Links rund um Corona-Apps und verwandte Themen, die sich während der vergangenen Woche angesammelt haben:

Bei so viel Text wünscht man sich fast eine Quarantäne, um genügend Zeit zum Lesen zu haben.

Geschichten erzählen

Das deutsche Corona-Warn-App-Projekt hat einen ersten Anforderungskatalog vorgelegt. Von den politischen Belastungen seiner Vorgeschichte kann es sich nicht lösen. Die Entwickler skizzieren ein Minimum Viable Product ausgehend von den bekannten willkürlichen Festlegungen. Auf eine ergebnisoffene Einbindung der Stakeholder in die Anforderungsanalyse warten wir weiter vergebens.

Für die deutsche Corona-Warn-App, die im Auftrag der Bundesregierung von SAP und der Telekom entwickelt wird, liegt jetzt ein erster Anforderungskatalog vor. Große Überraschungen finden sich darin nicht, die Entwickler bleiben in den politisch vorgezeichneten Bahnen. Das ist verständlich, aber schade, denn so unterbleibt weiter die Auseinandersetzung mit dem Anwendungskontext und den realen Bedürfnissen der Nutzer und Stakeholder. Dass die Anforderungen als User Stories formuliert sind, lässt die daraus resultierenden Defizite deutlich hervortreten.

Eine User Story beschreibt eine funktionale Anforderung an ein System in der Form: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“, oder ähnlich. Das Wie spielt zunächst keine Rolle. Als Informationsobjekte werden User Stories im Entwicklungsprozess zu verschiedenen Zwecken verwendet. Entwickler und Designer knüpfen daran ihre Entwurfsarbeit, das Produktmanagement kann damit in Abstimmung mit den Stakeholdern Ziele und Prioritäten festlegen und das agile Projektmanagement steuert mit Hilfe eines priorisierten Backlogs noch nicht umgesetzter User Stories die Entwicklungsarbeit.

Damit User Stories gut werden, muss man sich bei ihrer Formulierung ernsthaft mit seinen künftigen Nutzern auseinandersetzen, das heißt intensiv mit ihnen interagieren. Dazu gibt es eine Reihe von Methoden von Fragebögen über Interviews  und Workshops bis zu frühen Usability-Tests mit Papierprototypen. Ohne diese Interaktion läuft man Gefahr, spekulative Vorstellungen zu entwickeln, die sich später als falsch erweisen. In der echten agilen Entwicklung muss man allerdings nicht alles vorher klären, weil man den Nutzern regelmäßig neue Versionen einer Anwendung zur Verfügung stellt und sich dazu jeweils Feedback holt.

Die veröffentlichten User Stories für die Corona-Warn-App (in der Fassung vom 14. Mai 2020) zeigen drei Auffälligkeiten:

(1) Geringe Nutzerorientierung. Die Entwickler wandeln die Schablone ab zu: „Als <Stakeholder> möchte ich <Handlung durchführen>, um <gewünschtes Ergebnis zu erzielen>.“ Aus dem Ziel wird eine Handlung, aus dem Nutzen ein gewünschtes Ergebnis. Dieses subtil abgewandelte Format erleichtert es, aus der Luft gegriffene Gestaltungsideen den Stakeholdern gewissermaßen in den Mund zu legen, indem man sie als User Story ausgibt.

Das tun die Entwickler auch sogleich und formulieren zum Beispiel: „Als App-Nutzer möchte ich beim erstmaligem Applikationsstart über die Nutzungsbedingungen und Datenschutzbestimmungen (Data Protection Screen) informiert werden und meine Zustimmung geben, um über den Umgang mit meinen Daten innerhalb der Anwendung aufgeklärt zu sein.“ (E01.02) oder: „Als App-Nutzer möchte ich das Impressum der Applikation einsehen können, um zu sehen, wer für Entwicklung und Inhalte der Applikation verantwortlich ist.“ (E02.04). Das ist Käse, Datenschutz-Formalia und Impressum wollen nicht die Nutzer haben, sondern die Daten- und Verbraucherschützer. Nutzer freuen sich darüber so sehr wie über ein Cookie-Banner auf einer Website.

In diesem Stil geht es auch bei den Kernaufgaben der App weiter: „Als App-Nutzer möchte ich, dass bei Vorliegen meines positiven Testergebnisses nach meiner Zustimmung die pseudonymisierten IDs, unter denen ich an den vergangenen Tagen für andere App-Nutzer sichtbar war, an den Warn Server übermittelt werden, damit Kontaktpersonen durch ihre Apps gewarnt werden können.“ (E06.03), oder: „Als App-Nutzer möchte ich die Möglichkeit zur Eingabe einer TAN innerhalb der App haben, damit ich die mir telefonisch mitgeteilte TAN zur Zuordnung meines Testergebnisses zu der von mir genutzten Instanz der App nutzen kann.“ (E06.05). Das sind keine lösungsneutralen Ziele realer Nutzer, sondern Gestaltungsideen der Entwickler.

(2) Fehlende Stakeholder. Als Stakeholder sind nur App-Nutzer, Hotlines sowie das Robert-Koch-Institut (RKI) genannt. Hingegen fehlen die zuständigen Gesundheitsämter sowie auch der verantwortliche Betreiber der gesamten Anwendung und damit mittelbar die Öffentlichkeit.

Zu den seit dem Aufkommen der App-Idee geflissentlich ignorierten Anforderungen der Gesundheitsämter hat sich der Landkreistag vor einiger Zeit bereits geäußert. Von dort bekäme man User Stories wie: „Als Beamter einer Gesundheitsbehörde möchte ich Kontaktpersonen identifizieren, um ihnen Empfehlungen und Anordnungen zu übermitteln.“, oder: „Als Beamter einer Gesundheitsbehörde möchte ich Quarantäneanordnungen aussprechen, die einer gerichtlichen Prüfung standhalten.“ Dass es solche Anforderungen gibt, heißt nicht, dass man sie zwingend umsetzen müsste. Wer sie gar nicht erst erfasst, drückt sich jedoch davor, wichtige Aspekt des Problems überhaupt zur Kenntnis zu nehmen.

Um die Errichtung oder Beauftragung einer verantwortlichen Betreiberinstitution drückt sich seit ebenso langer Zeit die Bundesregierung. Ein verantwortlicher Betreiber hätte unter anderem die Aufgabe, den Systembetrieb zu überwachen und die Öffentlichkeit darüber auf dem Laufenden zu halten, wie gut oder schlecht die automatische Kontaktverfolgung funktioniert. Von einem Verantwortlichen bekäme man User Stories wie: „Als Verantwortlicher möchte ich die Arbeit des Systems fortlaufend überwachen, um Fehler und Probleme schnell zu erkennen.“, „Als Verantwortlicher möchte ich täglich aktuelle Statistiken über die verteilten Warnungen erhalten, um die Öffentlichkeit zu informieren.“, oder: „Als Systembetreiber möchte ich Nutzerfeedback einholen, um die App fortlaufend verbessern zu können.“ Hier läge übrigens auch der passendere Kontext für Anforderungen wie das Impressum oder den unvermeidlichen Datenschutz-Sermon.

(3) Unvollständige Anforderungen. Während sich viele User Stories mit sekundären Themen wie dem Installationsprozess, der Konfiguration und der Barrierefreiheit beschäftigen, bleibt der Kern der App sehr dünn. Ausführlich und mit zu vielen technischen Details wird der Erhalt eines Testergebnisses und das darauf folgende Auslösen einer Warnung beschrieben. Allerdings fehlt die Möglichkeit zur Entwarnung etwa für den Fall, dass ein Testergebnis falsch gemeldet oder zugeordnet wurde.

Für den Kontaktfall – ein App-Nutzer wird über eine mögliche Ansteckung irgendwie, irgendwo, irgendwann benachrichtigt – müssen hingegen ganze zwei User Stories genügen. Im Wesentlichen sagen sie: Der Nutzer erhält eine Nachricht und kann daraufhin Verhaltensempfehlungen aufrufen. Aus Nutzersicht gibt es an dieser Stelle noch einiges zu klären. Grundidee der Corona-Warn-App ist, dass sich die Informierten umgehend selbst isolieren, bis klar ist, ob sie sich angesteckt haben, also entweder ein verlässliches negatives Testergebnis vorliegt oder aber Symptome auftreten.

Ich vermisse hier User Stories wie: „Als Kontaktperson eines Infizierten möchte ich schonend und mitfühlend erklärt bekommen, dass ich möglicherweise mit einem potenziell tödlichen Virus infiziert bin, damit ich mich nicht mehr als unvermeidlich aufrege.“, „Als Kontaktperson eines Infizierten möchte ich wissen, wo ich mich testen lassen kann, um möglichst schnell Klarheit über eine Ansteckung zu erlangen.“, oder: „Als benachrichtigter App-Nutzer, der sich umgehend in Quarantäne begibt, möchte ich einen Nachweis zur Vorlage bei Arbeitgebern, Behörden und Gerichten abrufen, um meine Abwesenheit beziehungsweise verpasste Termine zu entschuldigen.“

Neben solchen praktischen Fragen stellen sich an dieser Stelle auch grundsätzliche. Eine Befehlsgewalt über Menschen erhält das Smartphone nicht, da alles freiwillig sein soll. Wie aber muss eine Benachrichtigung aussehen, damit sie für die Nutzer plausibel ist und die daran geknüpften Verhaltensempfehlungen freiwillig befolgt werden? Ich könnte mir vorstellen, dass das mit ein paar Details besser funktioniert: „Jemand aus Ihrer Sportgruppe, die sich am Montag getroffen hat, ist infiziert.“, oder: „Sie saßen vorgestern im ICE von Frankfurt nach Mannheim im gleichen Wagen wie ein Corona-Infizierter.“ Solche Aussagen sind konkret und der persönliche Bezug nachvollziehbar, während die Warnungen der geplanten App vage bleiben.

Nun muss man bei agiler Entwicklung nicht von Anfang an alles richtig machen. Ausgehend von einer vagen Idee kann man die Einzelheiten und allerlei unerwartete Fragen nach und nach entdecken, denn agile Entwicklung ermöglicht und impliziert eine empirische Anforderungsanalyse über die gesamte Entwicklungszeit hinweg. Angesichts der Vorgeschichte sowie des Zeitdrucks – einige sprechen schon vom „digitalen BER“ (https://www.mdr.de/nachrichten/politik/inland/corona-tracing-app-warten-100.html), obwohl das weit übertrieben scheint – habe ich jedoch den Eindruck, dass man hier einfach mit politisch geformten Vorgaben in einen kleinen Wasserfallprozess geht. Daran ändert ein an User Stories erinnerndes Gerüst für die vorbestimmten, an willkürlichen technischen Entscheidungen ausgerichteten Anforderungen wenig.

Schon vor einem Monat, als das Projekt der Stunde noch PEPP-PT hieß, war zu erkennen, dass ein nur auf perfekten technischen Datenschutz fokussierter Ansatz die Anforderungsanalyse zu kurz kommen lassen würde. Nicht zuletzt den am Projekt Beteiligten selbst fiel dies anscheinend auf und sie verabschiedeten sich vom dezentralen Extremismus. Genaueres weiß die Öffentlichkeit nicht, denn PEPP-PT erlaubte keine Einblicke in den Entwicklungsprozess. Zumindest dies hat der zweite Anlauf verbessert. Ob das bloße Vorzeigen jedoch etwas am absehbaren Ergebnis ändert, bleibt offen.

CoronApp-Links (2020-05-09)

Auch diese Woche haben sich allerlei Meldungen und Artikel zum Thema Corona-App angesammelt:

Die deutsche App soll nach aktuellem Stand im Juni erscheinen. Das Thema wird uns also noch eine Weile begleiten.

Dezentrale Engstirnigkeit, zentraler Realismus

Auch in der automatischen Kontaktverfolgung per Smartphone-App traut sich Großbritannien, einen eigenen Weg zu gehen. Dort beginnt gerade der Testbetrieb einer Corona-App, der eine zentrale Datenverarbeitung zugrunde liegt. Die Briten verfolgen damit in jeder Hinsicht das Gegenteil des deutschen Ansatzes: Während dort eine zentrale Lösung weitgehend einsatzreif ist, hat man hier gerade dezentral von vorne angefangen, nachdem das bereits laufende Projekt PEPP-PT mit seiner Entscheidung gegen eine streng dezentralisierte Lösung politisch in Ungnade gefallen war. Die hierzulande mitschwingenden paneuropäischen Großmachtphantasien fanden auf der Insel naturgemäß ohnehin keinen Raum.

Die Gretchenfrage: „Zentral oder dezentral?“ entstand als Artefakt einer öffentlichen Debatte, weil sie zu Positionierungen einlud, ohne Sachkenntnis zu verlangen. Den Anschein überragender Bedeutung erlangte sie zum einen durch die im Nachhinein ungeschickt wirkende Ankündigung von PEPP-PT, den technischen Datenschutz in den Mittelpunkt zu rücken, zum anderen durch das eigennützige Handeln einiger Beteiligter. Während PEPP-PT im Laufe seiner Entwicklungsarbeit offenbar das Problem und den Lösungsraum besser verstand und sich vom dezentralen Extrem verabschiedete, spitzten dreihundert Professoren die ohnehin zu enge Fokussierung auf technischen Datenschutz noch zu. Als ginge es darum, unter idealisierten Voraussetzungen zwischen zwei einander widersprechenden Hypothesen die richtigere auszuwählen, konstruierten sie ein Entweder-Oder zwischen zentral und dezentral und gaben sogleich ohne Experiment die Antwort, selbstverständlich müsse es dezentral sein. Unterdessen sprangen Apple und Google auf den bereits abfahrenden Zug auf und präsentieren sich seither so geschickt als Retter der Privatsphäre, dass sogar Margrethe Vestager darauf hereinfällt und galant darüber hinwegsieht, wie das Duopol seine Plattform-Macht ausspielt.

Welche Erfolgsaussichten die Kontaktverfolgung per Smartphone und Bluetooth insgesamt hat, bleibt unabhängig von der technischen Architektur vorerst unklar. Setzt man diese Idee jedoch um, und sei es nur als Experiment, sollte man sich dabei um die bestmögliche Lösung bemühen. Was eine Lösung gut oder weniger gut macht, bestimmt dabei nicht ein zentrales technisches Detail, sondern der reale Nutzen im Anwendungskontext.

Für zentrale Elemente wie in Großbritannien spricht einiges. Erstens ist eine komplett dezentrale Architektur ohnehin nicht realistisch. Zum einen braucht man selbst bei Datenspeicherung auf den Endgeräten irgendeine zentrale Instanz zur Nachrichtenverteilung und Koordination, wenn man zugleich jede Datensammlung anonym halten und nicht Adressen wie zum Beispiel Telefonnummer für die spätere Benachrichtigung speichern möchte. Zum anderen gehören zu den verwendeten Plattformen unvermeidlich zentrale Instanzen wie Appstores und Telemetrie. Ausgehend von einem Aluhut-Bedrohungsmodell können sich Nutzerinnen und Nutzer in solch einer Umgebung sowieso auf keine Eigenschaft einer App verlassen, denn jederzeit könnte eine neue Version automatisch installiert werden, die alles ganz anders macht.

Zweitens gehören Feedbackmechanismen heute zum Stand der Technik. Seit Software nicht mehr auf Datenträgern in Pappschachteln, sondern online vertrieben und auf vernetzten Geräten benutzt wird, haben Entwickler die Möglichkeit, Telemetriedaten aus der Software selbst sowie Nutzerfeedback unmittelbar zu erhalten und auszuwerten. Das erleichtert und beschleunigt die Fehleerkennung und -behebung sowie die Weiterentwicklung enorm und erlaubt sogar interaktive Experimente mit realen Benutzerinnen und Benutzern. Beim Einsatz einer noch wenig getesteten Technologie sind Feedbackmechanismen besonders wichtig, denn sehr wahrscheinlich erlebt man Überraschungen und muss unerwartete Probleme lösen. Eine letztlich experimentelle App im Zuge der Pandemiebekämpfung einfach herauszugeben und dann sich selbst zu überlassen, wäre grob fahrlässig, zumal über das neue Coronavirus noch zu wenig bekannt ist.

Drittens kollidieren Anforderungen aus dem Anwendungskontext mit extremistischen Datenschutzkonzepten. Die Kontaktverfolgung ist kein belang- und folgenloses Smartphonespiel wie Pokémon Go, sondern sie soll reale Konsequenzen haben. Beim herkömmlichen Vorgehen gehören zu diesen Konsequenzen Quarantäneanordnungen der Gesundheitsämter. Solche Anordnungen benötigen einen Adressaten und im Rechtsstaat müssen sie auch begründet sein, um ggf. einer gerichtlichen Prüfung standzuhalten. Im Sozialstaat ist darüber hinaus geregelt, wer welchen Teil der Lasten trägt und wie beispielsweise eine quarantänebedingte Arbeitsunfähigkeit abgefedert wird. Die Verfechter eines dezentral-anonymen Ansatzes haben bis heute keine Vorschläge unterbreitet, wie das eine oder das andere funktionieren soll. Weder können die Gesundheitsämter damit irgend etwas durchsetzen, noch erhalten Betroffene eine ausreichende Begründung oder gar eine Bescheinigung zur Vorlage bei Vertragspartnern und öffentlichen Stellen.

Viertens drängen sich Nebenfunktionen einer für den Masseneinsatz bestimmten App geradezu auf. Eine offensichtliche ist die Erfassung statistischer Daten, um den Gesundheitsbehörden ein klareres Bild des Pandemieverlaufs zu vermitteln. Dazu muss man doch wieder Daten an eine zentrale Stelle übermitteln und es kann gut sein, dass sich dann aus einem integrierten Ansatz schnell Synergieeffekte ergeben.

In Großbritannien hat man sich offenbar mit den Anforderungen der Anwendung auseinandergesetzt, während Deutschland kontextarm über Technik stritt. Dort möchte man zum Beispiel besonders gute Virenverteiler anonym ausfindig machen und darauf Risikoeinschätzungen stützen. Ob das funktionieren kann, wird sich zeigen; um eine an der Oberfläche nicht offensichtliche Idee handelt es sich allemal. Ein zentralerer Ansatz ist auch nicht automatisch ein Zeichen für Nachlässigkeit oder Primitivität der Implementierung, er kann für alle realistischen Belange einen gleichermaßen effektiven Datenschutz gewähren. Nur eines haben die Briten ebenso versäumt wie die Bundesregierung: die entwickelte Technik rechtlich und organisatorisch mit vertrauensbildenden Maßnahmen zu flankieren. Ich wünsche ihnen dennoch viel Erfolg. Schneller fertig werden sie schon mal, wie auch einige andere Länder, die dem dezentralen Extremismus eine Absage erteilten.

Links zur Corona-App (2020-05-02)

Statt eines eigenen Kommentars heute einige Links zum Thema Kontaktverfolgung und Corona-App, die sich in der vergangenen Woche angesammelt haben:

Das sollte fürs Wochenende genügen.

Eristische Datenschutzdialektik

An der auf automatische Kontaktverfolgung und Datenschutz verengten Debatte um eine Corona-App kann man die Kunst, Recht zu behalten studieren. Datenschutzaktivisten gehen mit Axiomen und Finten in die Diskussion, die, so man sie akzeptiert, vernünftigen Argumenten kaum eine Chance lassen.

Datenschutzaktivisten unterstellen, jede Verarbeitung personenbezogener Daten gerate gewissermaßen von selbst außer Kontrolle. Es gebe eine „Datensammelwut“ und jede Datenverarbeitung wecke unweigerlich „Begehrlichkeiten“, denen man dann hilflos ausgeliefert sei. Aus diesen Gründen müsse man rechtzeitig vor allem über den Datenschutz sprechen und über nichts anderes.

Genau dies ist im Fall der Corona-App geschehen: Datenschutz galt der öffentlichen Debatte als sehr wichtig, während konzeptionelle Fragen und Anforderungen keine Rolle spielten. Der Ansatz der automatischen Kontaktverfolgung wurde als einzig möglicher und deshalb als gegeben angenommen. Mit den Stakeholdern, insbesondere den Gesundheitsdiensten sowie den Bürgerinnen und Bürgern, redete niemand.

Vernachlässigte Stakeholder melden sich jedoch häufig von selbst und machen ihre Bedürfnisse geltend. So auch hier, wo die Landkreise für ihre Gesundheitsbehörden anstelle der diskutierten Datenschutztechnik den Zugang zu und die Verarbeitung von Identitätsinformationen forderten. Diese Forderung ist ohne weiteres nachvollziehbar, wenn man sich mit der Arbeit der Gesundheitsämter im Zusammenhang mit einer meldepflichtigen Infektion beschäftigt.

Für Datenschutzaktivisten jedoch stellt die unaufgeforderte und verzögerte Äußerung unerwarteter Bedürfnisse genau das dar, wovor sie die ganze Zeit schon gewarnt haben: Begehrlichkeiten, Datensammelwut, Maßlosigkeit, die schiefe Bahn. Wahrscheinlich ist ihnen nicht einmal bewusst, dass sie damit alle und auch sich selbst hereinlegen und einer tautologischen Selbstbestätigung aufsitzen.

Auch um diesen Irrtum zu vermeiden, sollten Debatten stets beim Problem und den Anforderungen an technische Lösungen oder Lösungsunterstützung beginnen und nie bei der Datenschutztechnik.

Echte Corona-App: SORMAS

Wie sehr sich das digitalpolitische Berlin mit seiner Debatteninszenierung um eine „zentrale“ oder „dezentrale“ App zur Kontaktverfolgung blamiert hat, macht eine existierende Lösung deutlich:

Das Surveillance Outbreak Response Management & Analysis System (SORMAS) aus dem Helmholtz‐Zentrum für Infektionsforschung (HZI) unterstützt Gesundheitsdienste beim Kontaktpersonen- und Fallmanagement. Es ist ausgelegt auf die Nutzung mit mobilen Geräten auch in Ländern mit schwacher Infrastruktur, das heißt vielen Funklöchern.

SORMAS hat mehr als fünf Jahre Entwicklungsarbeit und Einsatzerfahrung hinter sich. Die Lösung wurde unter anderem in der Bekämpfung von Ebola-Ausbrücken erfolgreich eingesetzt und ist mittlerweile in mehreren afrikanischen Ländern dauerhaft im Einsatz.

SORMAS steht bereits seit Anfang März auch in einer eingedeutschten und an Covid-19 angepassten Version zur Verfügung. Die Open-Source-Software kann von allen Gesundheitsdiensten kostenfrei genutzt werden.

Keiner der Spezialexperten, die sich in den vergangenen Wochen die automatisierte Kontaktverfolgung zum Thema der Stunde erklärt und sich zum Randaspekt Datenschutz öffentlich einen runtergeholt haben, hat SORMAS je erwähnt. Ich schließe mich da ein, ich hatte es auch nicht auf dem Radar und bin erst heute in einer LinkedIn-Diskussion darauf gestoßen.


PS: In Berlin wird SORMAS seit einigen Tagen eingesetzt.

Aufs Glatteis geführt

Seit Mitternacht schweigen nun an einer Front die Waffen: Die Bundesregierung kapituliert bedingungslos vor dem Aufschrei einiger Datenschutztechnikexperten und entscheidet sich für eine dezentrale Architektur zur Kontaktverfolgung. Nur dies schaffe das nötige Vertrauen, lässt sich Kanzleramtsminister Braun zitieren. Inwieweit sich damit die Anforderungen der Praxis erfüllen lassen, bleibt unterdessen unklar, denn mit solchen Fragen hat sich offenbar niemand beschäftigt. Die Regierung hat sich in Sachen Digitalisierung wieder einmal aufs Glatteis führen lassen. Das Projekt Corona-App wird voraussichtlich die Misserfolgsgeschichten der Gesundheitstelematik, des elektronischen Personalausweises und der Blockchain-Strategie fortsetzen. Das liegt nicht an der Technik, sondern an mangelnder Kompetenz in der Technikgestaltung.

Begonnen hatte alles vor einigen Wochen mit den öffentlichen Auftritten von DP-3T und PEPP-PT, anfangs noch in einer Allianz und scheinbar am gleichen Strang ziehend. Damit begann eine von Anfang an verzerrte Debatte über „die Corona-App“. Zum einen stand unvermittelt ein spezifischer Ansatz im Raum, nämlich die automatisierte Kontaktverfolgung und Benachrichtigung von Kontaktpersonen. Sinnhaftigkeit, Erfolgsaussichten und Erfolgsbedingungen dieses Ansatzes sowie andere Wege der digitalen Seuchenbekämpfung wurden kaum diskutiert; alle wollten an unsere wundersame Rettung durch Technomagie glauben. Nur ein Kritikpunkt ließ sich nicht umschiffen: Die automatisierte Kontaktverfolgung würde nur funktionieren, wenn fast alle mitmachten. Ausgerechnet Datenschützer mit ihrem Faible für Selbstbestimmung wiesen früh darauf hin, dass dies bei freiwilliger Nutzung unrealistisch sei, ohne deswegen freilich einen Zwang zu fordern. Ein kleinerer Zweig der Debatte dreht sich daher um die Frage der Freiwilligkeit.

Den Schwerpunkt hingegen setzte PEPP-PT selbst: In Voraussicht auf typisch deutsche Technikkritik und den Hang einiger Akteure, die Verarbeitung personenbezogener Daten für eine Risikotechnologie mit nuklearem Gefahrenpotenzial zu erklären, rückte man statt des Anwendungsentwurfs den technischen Datenschutz in den Mittelpunkt seiner Selbstdarstellung. Wie und wie gut der eigene Ansatz funktionieren würde, wusste man bestenfalls ungefähr, was ist in frühen Phasen der Entwicklung auch völlig normal und unvermeidlich ist. Jedoch werde die eigene Lösung auf jeden Fall perfekte technische Datenschutzvorkehrungen umfassen, denn nur so sei bei den Bürgerinnen und Bürgern das nötige Vertrauen zu gewinnen. Dass Kanzleramtsminister Braun dem Projekt PEPP-PT später mit genau diesen Worten den Todesstoß versetzen würde, war da noch nicht absehbar – dass jemand auf dem Holzweg war, hingegen schon. Im weiteren Verlauf der Entwicklungsarbeit, die immer auch ein Lernprozess ist, musste man sich anscheinend von diesem anfänglichen Extremismus verabschieden, auch dies nicht ungewöhnlich.

Unterwegs gingen zwei Dinge schief. Erstens hatte man sich den Weg zu einer offenen Anforderungsanalyse verbaut, denn alles musste sich nun dem Datenschutz-Ideal unterordnen. Mit den Gesundheitsämtern vor Ort zum Beispiel redete – anders die Entwickler von TraceTogether in Singapur oder vermutlich auch jene der südkoreanischen Lösung – anscheinend niemand und so macht der Deutsche Landkreistag seine Vorstellungen in einem Brief an den Gesundheitsminister und das Kanzleramt geltend (paywalled).  Statt einem Weg, anonyme und folgenlose Nachrichten in den Cyberspace zu rufen, hätte man dort gerne Namen und Orte. Ob das es am Ende so umgesetzt werden sollte, sei dahingestellt; auf jeden Fall stecken hinter solchen Forderungen Bedürfnisse, die ein Entwicklungsprojekt erfassen und berücksichtigen muss. Vermutlich hat PEPP-PT so etwas sogar versucht oder einfach unterwegs das Problem besser verstanden, doch von dem öffentlich eingeschlagenen Pflock „perfekter technischer Datenschutz“ kam man nicht mehr los.

Zweitens verselbständigte sich die Datenschutzdiskussion und wandelte sich schnell zu einer Glaubensfrage. Zwar lagen zumindest der Öffentlichkeit weiter nur vage Ideen einer App zur Kontaktverfolgung vor, die irgendwo vom Himmel gefallen waren, doch statt über grundlegende konzeptionelle Fragen zu reden, positionierten sich alsbald allerlei Personen und Einrichtungen in einem der Lager „zentral“ oder „dezentral“. Teils handelte es sich um ehrliche, aber überfokussierte Eiferer wie den CCC, teils waren wohl auch handfeste Interessen im Spiel wie bei den Professoren, die sich nach der Abkehr vom Forschungsprototypen DP-3T ihrer Bedeutung beraubt sahen. Obendrein mischten sich auch noch Google und Apple, trotz interessanter technischer Ansätze als Plattformanbieter Inbegriffe der Zentralisierung, mit eigenen Angeboten ein und weckten teils Vertrauen in ihre Fähigkeiten, teils aber auch antiamerikanische Instinkte.

Schnell schoss sich die Szene medienöffentlich auf die Forderung nach einem dezentralen Ansatz ein,  während dagegen sprechende Anforderungen nur langsam zu Tage treten. Unterdessen hielt die Bundesregierung ihre Füße still und ließ der Debatte freien Lauf, ohne selbst etwas beizutragen. Sie zweifelte nie an der unbelegten These von der Vertrauen durch Datenschutztechnik und verzichtet bis heute darauf, öffentlich die rechtlichen und organisatorischen Rahmenbedingungen für den Einsatz einer Corona-App zu klären. Dabei ist die kritiklos übernommenen Ursprungsidee nicht einmal plausibel, denn zum einen versteht kaum jemand die technischen Details, zum anderen zeigen die (wahrscheinlich zu Recht) ungehört verhallenden Mahnungen der Datenschützer vor massenhaft genutzten Diensten wie Google, Facebook, WhatsApp oder aktuell Zoom, dass Vertrauen gerade nicht durch den Segen von Datenschützern und Aktivisten entsteht.

Statt das Ihre zur Vertrauensbildung zu tun, ergibt sich die Bundesregierung nun einer überschaubaren öffentlichen Erregung und schließt sich der Forderung nach (scheinbar) perfektem Datenschutz an, während eine Debatte über Anforderungen und Anwendungsentwürfe weiter unterbleibt. Damit tritt das Projekt Corona-App in die Fußstapfen wenig erfolgreicher Vorgänger. Die Gesundheitstelematik – ihr Konzept inzwischen so altbacken wie die Bezeichnung – sollte das Gesundheitswesen vernetzen und dabei Gesundheitsdaten perfekt kryptografisch vor unbefugtem Zugriff schützen. Nach fünfzehn Jahren Entwicklungszeit ist kaum mehr herausgekommen als ein VPN sowie ein Stammdatendienst. Wenig später sollte der elektronische Personalausweis allen Bürgerinnen und Bürgern einen Identitätsnachweis fürs Internet verschaffen. Seine Datenschutzmechanismen sind nahezu perfekt, doch da man Anwenderbedürfnisse ignoriert und das Konzept über die vergangenen zehn Jahre auch kaum weiterentwickelt hat, benutzt fast niemand die eID-Funktion. Bei der Blockchain schließlich ging es zwar nicht um Datenschutz doch auch hier stand eine Technik im Mittelpunkt, von der man Wunderbares erwartete. Diesen Glauben ließ man sich in Berlin nicht von geringer Plausibilität der Anwendungsideen erschüttern. Darüber hinaus brachten die Blockchain-Evangelisten das Schlagwort „dezentral“ ins Spiel und verkauften es unbegründet als Qualitätsmerkmal. Sollte hier die wahre Wurzel der Entscheidung liegen?

Am Beispiel der Corona-App zur Kontaktverfolgung zeigt Deutschland erneut, wie es an politisch belasteten Digitalprojekten scheitert. Mit Ruhm bekleckert hat sich keiner der Beteiligten. An entscheidenden Stellen mangelt es an Kompetenz, hinzu kommen Meme aus der EDV-Steinzeit, die sich niemand zu beerdigen traut. So wird das nichts. Dass es wieder etwas länger dauern wird, steht schon mal fest.


PS: Ich frage mich auch, ob eine Projektstruktur tragfähig ist, in der technische Entscheidungen nach politischer Wetterlage von Ministern getroffen werden, wobei der Gesundheitsminister hü sagt und das Kanzleramt wenig später hott. Ich frage mich außerdem, wieso die Gematik als Projektgesellschaft für die Digitalisierung des Gesundheitswesens in der ganzen Diskussion nicht einmal vorkommt. Eigentlich sollte sie prädestiniert sein, ein Vorhaben wie die Corona-App voranzutreiben und umzusetzen. Tatsächlich ist sie es wohl nicht.

PS (2020-04-28): Seit heute gibt es zumindest eine Projektstruktur, von deren Tragfähigkeit allerdings nicht alle restlos überzeugt sind.

Privacy by Design or Poor Requirements Engineering?

Privacy – or security or any other desirable, ethereal property – by design sounds like a great thing to do. Alas, design is complicated and hard to guide or control as a process. One common misunderstanding has become obvious in current efforts to develop and deploy contact tracing technology contributing to epidemic control. Some of these efforts such as DP^3T, TCN, or Apple’s & Google’s announcement promote privacy to the top of their list of objectives and requirements. This is wrong. It would be appropriate in an R&D project developing experimental technology, but contact tracing is an actual, real-world application and must fulfill real-world requirements. Premature optimization for technical privacy protection does not help its cause.

First and foremost, an application needs to support a basic set of use cases and provide the necessary functions in such a way that the overall approach makes sense as a solution of the given problem(s). For contact tracing, essential use cases include:

  • contact identification,
  • contact listing, and
  • contact follow-up.

In addition, any large-scale application of contract tracing needs to support:

  • safeguards against abuse, and
  • monitoring and governance.

Each use case entails requirements. Contact identification must be sufficiently reliable and comprehensive; it must also take place quickly after an infection has been detected. Contact listing needs some form of risk assessment, a method to notify contacts, and a way to justify mandatory quarantine requests. Contact follow-up needs some idea how and when to interact with listed contacts. Underlying the whole design must be some conception of which contacts matter, what an identified contact implies, what to do with or require from identified contact persons, and what to achieve through contact tracing. There needs to be some definition of success and failure for the system and individual cases, and some monitoring of how well the system operates. One also has to think about possible abuses and misuses of the system such as evasion, manipulation, or exploitation, and find ways to prevent them or to deal with them when they occur.

Such questions are to be answered in the high-level design of a contact tracing system. They can and should be pondered at the level of paper prototypes, forcing developers to get specific but allowing quick modification and user testing. Technology has to be considered at this point primarily as a constraint: What is realistically possible or available and would the design be feasible to implement? However, some fundamental design decisions have to be made at this level after evaluating alternatives, for example, which parts of the system to automate and which ones to leave to humans, or which technologies, platforms, and devices to consider and use.

Like any design process, this high-level system design may take any number of iterations before converging toward something that might work when implemented. New questions will likely come up in the process. If, for example, the system is to leave tracing to humans, how much time can they spend per case, how many of them will be needed, how will they work, and which types of data and support would really help them?

Secondary requirements like performance or privacy can and should already be considered at this stage. Privacy by design means just that, to consider privacy protection as dimensions of the design spaces from the beginning on. However, privacy is a dependent design dimension and like all other requirements it is subject to trade-offs. Dependent means that any design decision can affect the privacy properties of a system. One cannot delegate privacy to a system component or function that would take care of it comprehensively regardless of the design of any other aspect of the system. Trade-offs occur when once has to choose between design alternatives; each option will likely have some advantages over the others but also some disadvantages, so that one has to compromise and keep a balance.

Misunderstanding privacy by design as privacy technology über alles, demonstrated by current proposals for privacy-preserving contact tracing, is a recipe for disaster. Starting with perfect technical privacy protection as the primary requirement constitutes a premature optimization that de-prioritizes all other requirements and design dimensions, delays important design decisions while arbitrarily constraining them without impact assessment, and prevents well-considered trade-offs from being made. The most likely result is a system that performs well at most in the privacy dimension, reflecting the priorities of its designers.

As a symptom, none of the proposals for privacy-preserving contact tracing has yet answered question like the following: How does it assure the reliability of the data it collects or produces? Which failure modes and error rates does it produce? How is the system to be monitored for problems and abuses? In which institutional framework is it designed to operate? How does it distribute responsibilities between involved parties? How are outputs of the system to be interpreted and used in the real world, which consequences should they have and which ones are not desirable? How can its operation become transparent for its users? Should participation be mandatory or voluntary and how can the design be optimized for either case? If participation is mandatory, how would this be enforced, how can the system be made universally accessible for everyone, and how may people evade it? If voluntary, which incentives does the system create and which features let users trust or distrust the system? Such questions need to be discussed and addressed long before the technical minutiae of data protection.

Placing technical privacy protection in the center of attention can make sense in a research project, where one develops new technology to evaluate its properties and capabilities. The stakes are low in such a project, where the results are prototypes and research papers. Developing a real-world system, especially one to be used at the intended scale of contact tracing apps, requires a broader perspective and comprehensive requirements analysis.


P.S. (2020-04-18): Government Digital Services of Singapore with their TraceTogether app apparently got their requirements analysis and design process right:

One thing that sets TraceTogether apart from most private efforts to build a Bluetooth contact tracer, is that we have been working closely with the public health authorities from day 1. (…) The team has shadowed actual real-life contact tracers in order to empathise with their challenges.

P.S. (2020-04-19): The closest to a requirements document I have seen so far is this: Mobile applications to support contact tracing in the EU’s fight against COVID-19,  Common EU Toolbox for Member States (via).

P.S. (2020-04-22): The Ada Lovelace Institute published a quick evidence review report titled: Exit through the App Store? A rapid evidence review on the technical considerations and societal implications of using technology to transition from the COVID-19 crisis, which makes a number of reasonable recommendations.

 

Datenschützer im eigenen Saft

Unsere Datenschützer zeigen in der Krise, was sie können: Memetik, Bürokratie und Realitätsverlust. In der Tradition der 1970er/80er Jahre halten sie die elektronische Datenverarbeitung für eine Risikotechnologie vergleichbar der Kernkraft, die es mit allen Mitten einzudämmen gelte. Über die Jahre haben sich vorläufige Antworten auf einst berechtigte Fragen zu Memen verselbständigt, die man nur noch unreflektiert wiederkäut. Als Begründung des eigenen Treibens hat man sich in den ätherischen Wert unserer Rechte und Freiheiten verirrt, der alles und nichts begründen kann und jede Falsifikation zu Lasten der Datenschützer ausschließt, ihnen zugleich jedoch die Illusion vermittelt, stellvertretend für uns unsere Grundrechte wahrzunehmen.

Die aktuelle Corona-Pandemie stellt vieles auf den Kopf und lässt uns keine andere Wahl als unseren Digitalisierungsrückstand endlich zu verringern. Mehr Kartenzahlung, mehr Fernarbeit, mehr digitale Kommunikation und Kollaboration, Corona-Apps, Hackathons und vielleicht irgendwann sogar mehr E-Government – wir machen nach einer langen bleiernen Zeit gerade einen großen Sprung in Richtung Gegenwart. Nicht alles wird funktionieren wie erhofft oder versprochen, aber nach einem Vierteljahrhundert Internet für alle dürfen wir guten Gewissens überwiegend positive Auswirkungen erwarten.

Auch Datenschützer können dieser Entwicklung einiges abgewinnen, gibt sie ihnen doch – publish or perish – reichlich Gelegenheit, sich mahnend zu äußern. Davon machen sie effizient Gebrauch und wiederholen ihre ewiggleichen Meme, ohne sich um lästige Einzelheiten wie Kohärenz oder nachvollziehbare Begründungen zu kümmern.

So veröffentlicht etwa der Berliner Datenschutzbeauftragte eine mahnende Handreichung nebst Checkliste für die „Durchführung von Videokonferenzen während der Kontaktbeschränkungen“. Der Inhalt überzeugt nicht. Während seine Handreichung die Bedeutung einer verschlüsselten Übertragung herausstreicht, rät die Checkliste, das mit den Videokonferenzen am besten ganz zu lassen und möglichst zu telefonieren. Wie man jedoch verschlüsselt telefoniert, erklärt der Beauftragte nicht und wenn er es täte, lachten wir ihn aus, denn gemessen an Aufwand und Nutzen haben verschlüsselte Telefonate nur in Ausnahmefällen einen Sinn. Warum das bei einer Videokonferenz anders sei, erläutert er nicht und auch eine praktisch relevante Risikoreduktion durch die empfohlenen Maßnahmen kann er nicht belegen.

Überhaupt fehlt den Papieren eine plausible Risiko- und Bedrohungsanalyse und damit die Begründung. Stattdessen stecken alte Meme darin. Videokameras gelten den Datenschützern traditionell als verdächtig, wenn auch zuvörderst beim Einsatz zur Videoüberwachung. Später kam der Trend hinzu, Laptop-Kameras ostentativ zuzuklebensinnlos, aber sichtbar und leicht nachzuahmen. Auch der digitale Veganismus – der Datenschutzbeauftragte rät, existierende Dienste zu meiden und besser selbst einen aufzusetzen – hat eine lange Tradition.

Wie sehr diese Meme und Phrasen in der Vergangenheit verhaftet sind, wird deutlich, wenn man sie mit dem Stand der Technik abgleicht. Wenig haben die Offiziellen etwa zum gemeinsamen Bearbeiten von Dokumenten zu sagen. Das ist zwar seit vielen Jahren Stand der Technik und mindestens so nützlich wie Videokonferenzen, bei den alten Männern mit Röhrenbildschirmen in den Datenschutzbüros jedoch noch nicht angekommen. Schließlich wollen sie Vorbild gemäß ihrem Weltbild sein und agieren im Umgang mit der IT daher so übervorsichtig, dass es einer Selbstblockade gleichkommt. Dasselbe empfehlen sie allen anderen.

Wo sich der IT-Einsatz nicht ganz verhindern lässt, versucht man ihn in Bürokratie zu ersticken. Dies demonstrierten vor einigen Tagen Datenschutz-Aktivistinnen im Namen des Forums InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF): Zur laufenden Diskussion um den Einsatz von Smartphone-Apps zur Kontaktverfolgung im Rahmen der Seuchenbekämpfung legten sie eine sage und schreibe hundertseitige Datenschutz-Folgenabschätzung vor – für ein Phantom, denn bisher liegt kein ausgereiftes Einsatzkonzept für eine solche App vor, auf das sich eine qualifizierte Diskussion stützen könnte. So weit es sich beim Überfliegen dieses Konvoluts mit normativem Anspruch einschätzen lässt, steht darin kein relevanter Einwand, den nicht Susan Landau oder Ross Anderson knapper formuliert hätten. Auf die Idee, Datenschutzprobleme institutionell zu dämpfen, wie es bei der Erhaltung und Verharmlosung der Stasi-Akten gelungen ist, kommen die Aktivistinnen wohl gar nicht erst.

♠♠♠

Falsch abgebogen ist der Datenschutz früh in seiner Geschichte und sein Geburtsfehler wurde nie richtig korrigiert. Als der Datenschutz vor vier, fünf Jahrzehnten das Licht der Welt erblickte, entdeckte die Welt gerade die Schattenseiten damals moderner Großtechnologien wie der Kernenergie. Etwa zeitgleich mit den ersten Schritten zum Datenschutz entwickelte sich die Technikfolgenabschätzung, schrammte ein Kernreaktor in Harrisburg knapp an einer größeren Katastrophe vorbei, malte Robert Jungk den dann doch nicht eingetretenen Atomstaat an die Wand. Nebenbei herrschte noch kalter Krieg, der jederzeit in einen heißen letzten Weltkrieg münden konnte.

In diese Zeit fiel die zunehmende Verbreitung der elektronischen Datenverarbeitung (EDV) in Wirtschaft und Verwaltung. Auf dem Weg ins EDV-Zeitalter, so hofften viele, würde man alles besser machen als bei der Einführung anderer Großtechnologien, in die man scheinbar euphorisch und blind für ihre Gefahren hineingestolpert war.

Seither gehört zum Fundament des deutsch-europäischen Datenschutzes der Glaube, die elektronische Verarbeitung von (personenbezogenen) Daten sei eine Risikotechnologie vergleichbar der Kernkraft; man müsse sie ähnlich streng regulieren und überwachen sowie sorgfältig und umfassend technisch absichern. Genau genommen müsste man sie sogar verbieten, und genau davon geht der Datenschutz bis heute aus – die Verarbeitung personenbezogener Daten sei in der Regel verboten, sofern die nicht ausnahmsweise doch erlaubt sei. Diese Grundannahme erklärt, warum Datenschützer zum Beispiel so ein Theater um WhatsApp und dessen Nutzung persönlicher digitaler Adressbücher machen, obwohl sich außer ihnen kein Mensch daran stört und wohl auch niemand tatsächlich dadurch gefährdet wird. Für Datenschützer steht die IT traditionell unter Generalverdacht.

Heute steht Deutschland kurz davor, seine letzten Kernkraftwerke abzuschalten, während sich das Verbrennen von Kohle als eine viel größere und schwerer zu bändigende Gefahr erwiesen hat. Daneben meldet sich die Natur mit einem neuen Coronavirus, welches im Gegensatz zur EDV Menschenleben bedroht und mangels Impfstoff oder Heilmittel Vorsichtsmaßnahmen verlangt, die tief in unser gewohntes Leben und unsere bürgerlichen Freiheiten eingreifen. Doch unverdrossen verkauft uns eine Allianz aus Aktivisten, Datenschutzbeauftragten und Opportunisten den Datenschutz als Supergrundrecht und die Datenverarbeitung als explosive Risikotechnologie, von der man am besten die Finger lasse.

Anders als bei jeder anderen Risikotechnologie, deren Schäden sich als Sach- und Personenschäden quantifizieren lassen, fehlt dem Datenschutz und der fundamentalen EDV-Kritik jedoch ein klarer Risikomaßstab. An seine Stelle trat die radikale Vorsorge eines generellen Verbots der personenbezogenen Datenverarbeitung mit Ausnahmen, vergleichbar den Regeln für den Betrieb kerntechnischer Anlagen, die einer Genehmigung bedürfen.

Die Entscheidung über Ausnahmen legte man teils in die Hände des Gesetzgebers und teils in die der Betroffenen. So ward die informationelle Selbstbestimmung geboren, die das Bundesverfassungsgericht 1983 in seinem Volkszählungsurteil in den Rang eines Grundrechts erhob. In den folgenden Jahrzehnten unterblieben nötige Modernisierungen des Datenschutzes weitgehend und auch die DSGVO hat noch viel mit dem alten (west-)deutschen Bundesdatenschutzgesetz gemein.

Die IT entwickelte sich schnell weiter und entfernte sich nach und nach von den Voraussetzungen des etablierten Datenschutz, was man ihr nicht verübeln kann. Zugleich eigneten sich die Träger des Datenschutzes, die Beauftragten und Aktivisten, das Grundrecht der Betroffenen an und beanspruchen seither dessen stellvertretende Wahrnehmung. Mit dieser Waffe in der Hand müssen sie keine Kritik mehr fürchten, denn zum einen bleiben die Grundrechte zu abstrakt, um damit direkt und einfach argumentieren zu können, und zum anderen bedarf die Inanspruchnahme von Grundrechten – im Regelfall anders als im Datenschutz durch ihre Trägerinnen selbst – keiner Rechtfertigung. Begleitend entstand über die Jahre mit Anbietern von Compliance-Dienstleistungen ein Wirtschaftszweig, der von möglichst willkürlichen und bürokratischen Anforderungen profitiert und der deshalb um so andächtiger nickt als die Nachfrage nach seinen Angeboten steigt.

Deswegen werden wir jetzt vor Videokonferenzen gewarnt, besonders vor den einfach zu nutzenden. Ob jemals eine Videokonferenz jemandem ein Haar gekrümmt hat, bleibt offen, denn auf reale Risiken kommt es dem Datenschutz nicht an. Er begründet sich aus sich selbst und immunisiert sich damit gegen Kritik, ja sogar gegen die bloße Sinnfrage.

 

PS (2020-05-06): Microsoft weist die Warnungen des Berliner Datenschutzbeauftragten für seine Produkte ausdrücklich zurück.

PS (2020-05-16): Microsoft geht den nächsten Schritt und mahnt Berlin ab.

#WirHabenJaSonstNichtsZuTun

Wo sind eigentlich die ganzen Schlaumeier geblieben, die bei jeder Videokamera einen Generalverdacht wittern und der automatischen Gesichtserkennung Untauglichkeit zur Fahndung nach Terroristen vorwerfen, weil sie unvermeidlich mehr falsche als wirkliche Terroristen melde?

Gegenwärtig reden wir über Ausgangssperren zur Bekämpfung eines Virus, das einen Bevölkerungsanteil in der Größenordnung von einem Promille befallen hat. Ein Corona-Soforttest mit hoher Falsch-Positiv-Rate fände vermutlich breite Akzeptanz, wenn man mit seiner Hilfe eine knappe Mehrheit – oder vielleicht sogar eine genügend große Minderheit – der Bevölkerung von Einschränkungen befreien könnte.

Von welchen Axiomen muss man ausgehen und welche Unterschiede zwischen beiden Szenarien berücksichtigen, um mit einem logisch konsistenten Weltbild eine automatische Fahndung wegen begrenzter Zuverlässigkeit abzulehnen, erhebliche Einschränkungen des öffentlichen Lebens und der persönlichen Freiheit zur Virusbekämpfung hingegen zu befürworten?

***

#WirHabenJaSonstNichtsZuTun regt zum Zeitvertreib Grundsatzdiskussionen an

Digitaler Veganismus

Kelbers wohlfeile Datenschutztipps an die falsche Adresse sehe ich als Symptom eines allgemeineren Trends. Nicht nur suchen sich amtliche Datenschützer mit den Bürgerinnen und Bürgern die falsche Zielgruppe, sie verbreiten dabei auch gerne fragwürdige Verhaltensmaßregeln, die zu ignorieren meist sehr vernünftig scheint. Ich nenne diese Maßregeln digitalen Veganismus, weil sie willkürlich sind, nur eine ideologische Begründung haben und sie den Alltag erschweren, ohne nennenswerten Nutzen zu stiften.

Veganer können nicht einfach zum Bäcker gehen und ein Brot kaufen, sondern müssen dort erst die Zutatenliste studieren, um herauszufinden, ob nicht jemand einen Schluck Milch oder einen Löffel Butter oder eine unglückliche Küchenschabe in den Teig gerührt hat. Glücklich wird, wer sich dabei einen Distinktionsgewinn einreden kann; die meisten Menschen hingegen kaufen einfach das Brot, das ihnen schmeckt und sind damit zufrieden. Als individuell gewählte Lebensweise ist das eine wie das andere völlig in Ordnung. Öffentliche Stellen, die den Veganismus empfählen, gibt es meines Wissens nicht.

Im Datenschutz hingegen geben Aufsichtsbehörden, Universitäten, Aktivist*innen und andere nur zu gerne Tipps für das, was sie gerne „digitale Selbstverteidigung“ nennen. Im Wesentlichen laufen diese Tipps meist darauf hinaus, sich allerorten von „Datenkraken“ verfolgt zu fühlen und Zuflucht in einem digitalen Aluhut in Form originellen, das heißt von den Gebräuchen des Mainstreams abweichenden Verhaltensweisen zu suchen. Das Angebot Data Kids der Berliner Datenschutzbeauftragten zum Beispiel warnt vor „diebi­schen dreis­ten Daten­wolken“ und „Krakina Kompli­zia“ und empfiehlt dagegen das Ritual, eine Abdeckung für eine Kamera zu bauen als sei der meist nur eingebildete Kameramann im Laptop ein relevantes Problem. Wie man dagegen rechtzeitig bemerkt, dass ein Kammergericht in ihrem Zuständigkeitsbereich in Sachen Sicherheit und Datenschutz nicht einmal näherungsweise auf der Höhe der Zeit ist, weiß die Beauftragte anscheinend  nicht, sonst hätte sie es ja bemerkt. Das ist freilich auch etwas anspruchsvoller als Kindern das Märchen von Krakina Komplizia und den sieben Clouds zu erzählen.

An die ewigen Warnungen offizieller Datenschützer, WhatsApp sei haram, weil es Adressbücher aus einer Cloud in eine andere hochlade, haben wir uns gewöhnt. Kein Mensch schert sich darum; WhatsApp ist so alltäglich geworden wie das Telefon, weil es umstandslos und ohne Schmerzen (naja) funktioniert. Nur wo die Datenschützer Macht haben, ist WhatsApp abweichend vom Normalen verboten – man möge bitteschön Alternativen nutzen.

Auf diesem Niveau bewegen sich die meisten Empfehlungen aus dem Reich des digitalen Veganismus: andere Messenger als die meisten Menschen möge man benutzen, einen anderen Browser, ein anderes Betriebssystem, andere Suchmaschinen und andere Landkarten. Seine E-Mail möge man verschlüsseln, die Cloud links liegenlassen und bei Bedarf besser eine eigene betreiben als hätte man alle Zeit der Welt und nichts Wichtigeres zu tun. Und wer einen Termin mit anderen abstimmen wolle, solle nicht irgendeinen Terminplaner benutzen, sondern bitteschön Nuudle, am besten mit dem Tor-Browser über das Tor-Netz (im Volksmund Darknet genannt).

Einen objektiven Nutzen hat diese Kasteiung nicht, doch kann man sich selbst dafür belohnen, indem man sich einredet, zu den Erleuchteten zu gehören und im Gegensatz zur vermeintlich blöden Masse der „Sheeple“ das Richtige zu tun. Das ist zwar ziemlich arrogant, aber wer diesen Teil im Stillen abwickelt und nach außen nur seine oberflächlich als hilfreich und wohlmeinend verpackten Ratschläge zeigt, bekommt wenig Gegenwind. Wenig Erfolg auch, denn die meisten Menschen fragen sich hier ebenso wie im Angesicht eines Zutatenlisten wälzenden Veganers, was das denn solle und bringe, warum sie sich so etwas antun sollten. Erfolg ist jedoch gar nicht gewollt, denn er würde alles zerstören: Begänne eine Mehrheit damit, den Ratschlägen zu folgen, wäre das Wohlgefühl der Ratgeber dahin.

PS (2020-04-27): Die Schattenseiten der gerne als gleichwertig hingestellten Alternativen werden im Artikel Endlich glückliche Freunde bei Golem.de deutlich. Dort geht es um den Messenger Signal, der WhatsApp im Funktionsumfang merklich hinterherläuft. Darin findet sich zudem ein Verweis auf den älteren Artikel Wie ich die Digitalisierung meiner Familie verpasste, dessen Autor beschreibt, wie er sich durch WhatsApp-Verweigerung aus der Kommunikation seiner Familie ausschloss.

PS (2020-07-06): Selbst wer keine bunten Bildchen braucht, wird mit Signal nicht unbedingt glücklich.