Schlagwort-Archive: Contact Tracing

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.

Zehnerlei Corona-App

Als Phantom ist „die“ Corona-App in aller Munde, nein, Medien. Sie inszeniert sich als Gegenstand eines Expertenstreits um die Frage, welche Architektur den technischen Datenschutz am besten gewährleiste, eine „zentrale“ oder eine „dezentrale“, und wer narzisstische Bestätigung sucht, schlägt sich öffentlich auf die eine oder die andere Seite. Dreihundert Informatikprofessoren zum Beispiel sehen sich ihrer Bedeutung beraubt, weil ihren Rat gerade niemand schätzt, und die Aktivistenclubs, die auch sonst zu jedem Thema die Hand heben, stehen ihnen in nichts nach.

Ihr Horizont bleibt eng und technisch, und so meiden sie neben der grundlegenden konzeptionellen Frage, was eine Corona-App überhaupt zu leisten hätte, sogar den rechtlichen und institutionellen Teil der Datenschutz-Debatte. Auf Ideen wie die einer spezifischen rechtlichen Regelung oder einer vertrauenswürdigen Institution zur Überwachung der außerordentlichen Datenverarbeitung aus besonderem Anlass kommen sie schon nicht mehr. Letztlich wollen nur sie bei einigen technischen Entscheidungen mitreden und führen dazu den Vorwand ins Feld, genau diese Entscheidungen seien essenziell für das Vertrauen der Nutzerinnen und Nutzer.

Mit App-Konzepten und Anwendungsszenarien aus anderen Ländern haben sich diese Diskursschauspieler offenbar so wenig auseinandergesetzt wie mit Institutionskonstrukten à la Stasi-Unterlagen-Behörde, mit einer umfassenden Anforderungsanalyse so wenig wie mit dem Verlauf von Entwurfs- und Entwicklungsprozessen. Sie zweifeln nicht am Projekt der automatisierten Kontaktverfolgung, das sie ohne Diskussion als einziges denkbares Funktionsprinzip einer Corona-App annehmen, sondern sie möchten diese Kontaktverfolgung in einigen willkürlich gewählten technischen Dimensionen perfektionieren. Erwägungen jenseits der Technik beschränken sich auf die Mahnung, „die“ App müsse auf jeden Fall nur freiwillig zu verwenden sein.

Über diese Debatteninszenierung haben wir ganz vergessen, grundlegende Fragen zu klären. Tatsächlich gibt es „die“ App gar nicht, sondern ganz verschiedene Zwecke und Konzepte des App-Einsatzes in der Seuchenbekämpfung. Eine Auswahl:

(1) Kontaktverfolgung – Smartphones als persönliche und häufig am Körper getragene Geräte erfassen Daten über das Verhalten ihrer Träger, mit denen sich im Fall einer Infektion Kontaktpersonen der oder des Infizierten leichter oder zuverlässiger ermitteln lassen. Sowohl die Datenerfassung als auch ihre spätere Verwendung kann man unterschiedlich gestalten. Daten können (1.a.I) automatisch erhoben oder wie in den ersten Versionen von Stopp Corona  (1.a.II) manuell erfasst werden. Ebenso lassen sich die aufgenommenen Daten (1.b.I) automatisch verwenden, um erfasste Kontaktpersonen über eine Infektion zu informieren, oder (1.b.II) menschlichen Kontaktverfolgern anbieten, um deren Arbeit zu unterstützen. Allein daraus ergeben sich vier Kombinationsmöglichkeiten; für welche man sich entscheidet, bestimmt die Erfolgsaussichten wie auch die Art der zu erhebenden Daten.

(2) Statistische Erhebungen – Die Smartphones der App-Nutzer und daran angeschlossene Geräte wie Fitness-Armbänder und Digitaluhren werden zu einem Netz verteilter Sensoren, dessen Daten ohne Personenbezug zu wissenschaftlichen und statistischen Zwecken ausgewertet werden. Die Corona-Datenspende-App des RKI setzt dieses Konzept um.

(3) Selbstdiagnose – Eine App oder Website fragt bei Infektionsverdacht Symptome und Risikofaktoren ab und gibt daraufhin Verhaltensempfehlungen, etwa den Rat, einen Arzt anzurufen oder ein Testzentrum aufzusuchen. Zusätzlich können die gewonnenen Daten analog zu (2) der Forschung und Statistik dienen. Die Nutzung kann (3.a) freiwillig und anonym erfolgen wie bei der Website Covid-Online (zurzeit in Überarbeitung) des Marburger Universitätsklinikums und der Philipps-Universität oder (3.b) verpflichtend im Rahmen einer flächendeckenden Früherkennung.

(4) Quarantäneüberwachung – Quarantänepflichtige Personen weisen ihren Aufenthalt regelmäßig mit Hilfe Smartphones nach. Dazu muss zum einen die Bewegung des Geräts überwacht werden, zum anderen die räumliche Nähe zwischen Gerät und Besitzer. Die digitale Quarantäneüberwachung lässt Schlupflöcher, erleichtert jedoch gegenüber anderen Formen der Überwachung – zum Beispiel häufigen Hausbesuchen – die Arbeit der Gesundheits- und Ordnungsbehörden. Nutzerinnen und Nutzer müssen kooperationsbereit sein.

(5) Digitale Seuchenpässe – Das Smartphone wird zum Speicher und Träger von Nachweisen, nach deren Kontrolle Privilegien gewährt werden können. Nachgewiesen werden kann einerseits (5.a) der (wahrscheinliche) Infektionsstatus, etwa durch die Zeitpunkte und Ergebnisse von Tests oder Selbstdiagnosen (siehe Nr. 3) und das Nichtbestehen einer Quarantäneanordnung. Diesem Ansatz folgt der chinesische Health Code. Andererseits ließe sich auch (5.b) der Immunstatus nach überstandener Infektion oder später nach einer Schutzimpfung auf diese Weise bescheinigen. Dies jedoch ist umstritten, einmal aus medizinischen Erwägungen, da die Frage der Immunität nach einer Infektion noch nicht ausreichend geklärt ist, aber auch praktischen und ethischen Gründen, da ein Immunitätspass ohne verfügbare Schutzimpfung einen Anreiz schaffen kann, sich absichtlich zu infizieren oder sich auf unlautere Weise einen falschen Nachweis zu verschaffen.

Das sind fünf verschiedene Anwendungen in insgesamt zehn Varianten und diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit. In fast allen Fällen muss man sich rechtzeitig Gedanken über Alternativen für Menschen ohne geeignetes Smartphone machen. Genuin technisch und die Besonderheiten der Plattform „Smartphone“ ausnutzend erscheinen (1), (2), und (4). Können wir jetzt endlich die Phantomdiskussion um eine zentrale oder dezentrale automatisierte Kontaktverfolgung beenden und debattieren, ob und wie wir die Bekämpfung des Coronavirus digital unterstützen möchten? Danke.

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.