Archiv der Kategorie: Anforderungen – Requirements

Unterschätzte Risiken: software-definiertes Eigentum

Januar 17, 2021Anforderungen – Requirements, By Design, Security, Unterschätzte Risikenblockchain, Kryptowährung, VerfügbarkeitSven Türpe

Juristen unterscheiden aus gutem Grund zwischen Eigentum und Besitz. Mein vor gut einem Jahr geklautes Fahrrad zum Beispiel ist immer noch mein Eigentum, ich besitze es nur nicht mehr. Das Eigentum ist ein Recht, welches sich aus Gesetzen, Verträgen und nötigenfalls Gerichtsbeschlüssen ergibt. Der Besitz, die Verfügungsgewalt ist eine Tatsache, deren Ausprägung rechtmäßig oder unrechtmäßig sein kann. Verleihe ich etwa ein Fahrrad, so gelangt es rechtmäßig in den Besitz eines anderen, während ich Eigentümer bleibe. Gibt der Entleiher das Fahrrad nicht wie vereinbart zurück, sondern unterschlägt es, wird sein Besitz unrechtmäßig.

Solche Begriffe und Unterscheidungen sind über Jahrhunderte gewachsen und haben sich bewährt. Nun ist jedoch die wunderbare Blockchaintechnologie angetreten, unser geachsenes Verständnis von Eigentum und Besitz zu zerreißen. Wie zu erwarten war, geht das in die Hose.

Ihr habt sicher die Geschichte von dem Programmierer gelesen, der ein Passwort vergessen hat. Dieses Passwort gehört zu einer verschlüsselten Festplatte, auf dieser Festplatte ist ein Bitcoin-Wallet gespeichert, an diesem Bitcoin-Wallet hängen quantisierte Blockchain-Ergänzungsprivilegien im Umfang von ungefähr 7.000 Bitcoin und bei den Preisen, zu denen solche Privilegien derzeit gehandelt werden, könnte man sie für ein mittleres Vermögen in echtem Geld verkaufen. Das ist blöd gelaufen und wenn etwas blöd läuft, kann man daraus lernen.

Lektion 1: Verschlüsselung ≠ Sicherheit

Unter den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit wird letztere von Security-Laien gerne als Mauerblümchen behandelt. Oft ist Verfügbarkeit wie hier jedoch das wichtigste Schutzziel. Zwischen Verfügbarkeit und Vertraulichkeit muss man meistens abwägen, gerade wenn man Daten verschlüsselt, denn je sicherer die Verschlüsselung ist, desto schwieriger wird es, die Verfügbarkeit sicherzustellen. Ob und unter welchen Rahmenbedingungen Verschlüsselung zur Sicherheit beiträgt, muss man deshalb im Einzelfall anhand einer gründlichen Bedrohungs- und Risikoanalyse herausfinden.

Lektion 2: Software-definiertes Eigentum überfordert

In der von libertären Vorstellungen geprägten Blockchain-Welt ist sich jeder selbst der Nächste. Den Unterschied zwischen Besitz und Eigentum gibt es dort nicht, nur die Verfügungsgewalt über bestimmte Schlüssel („Wallets“). Wie beim guten alten Sparstrumpf unterm Kopfkissen muss jeder selbst für seine Sicherheit sorgen, ohne Unterstützung von Institutionen zu erhalten. Das ist im richtigen Leben anders, da kann man sein Bargeld zur Bank bringen und erhält dafür eine Anspruch auf Auszahlung. Unter Umständen kann man seinen Anspruch sogar noch nach einer Bankenpleite erfolgreich geltend machen, nämlich im Rahmen der Einlagensicherung. Im Vergleich zu einer Bank ist ein Bitcoin-Wallet sehr unbequem, weil es nur Besitz und kein davon unabhängiges Eigentum gibt.

Lektion 3: Software-definiertes Eigentum überfordert doppelt

Nicht nur muss man sich mit einem Bitcoin-Wallet ganz alleine um seine Sicherheit kümmern, man hat es dabei auch noch besonders schwer. Alles hängt am Wallet. Das muss vertraulich bleiben, denn wer Zugriff auf die geheimen Schlüssel bekommt, erhält die Verfügungsgewalt über die am Wallet hängenden Transaktionsprivilegien. Nebenbei braucht man auch noch eine sichere Ausführungsumgebung für Programme, um das sicherzustellen. Ein Wallet muss aber auch verfügbar bleiben, denn sonst kann man selbst nichts mehr damit anfangen. Das alles unter einen Hut zu bringen, ist schwer. Als Bankkunde hat man viel einfacher und bekommt nebenbei noch Service dazu, zum Beispiel Karten, mit denen man bezahlen kann.

Lektion 4: Auf lange Sicht sind wir alle tot. Und Bitcoin et al. auch.

Etwas weniger offensichtlich ist ein weiteres Problem. Bitcoin-Fans erklären oft und gerne, die Gesamtzahl der in der Bitcoin-Community herstellbaren quantisierten Transaktionsprivilegien sei von vornherein auf einen Maximalwert begrenzt. Dies ist jedoch nur die halbe Wahrheit, denn mit jedem verlorenen Wallet gehen, falls die Technik wie spezifiert funktioniert, die daran gebundenen quantisierte Transaktionsprivilegien unwiderruflich verloren. Das tatsächlich verfügbare Volumen an Transaktionsprivilegien („Bitcoins“) nimmt also auf lange Sicht ab, bis keine mehr übrig sind. Geld auf der Bank kann man zum Beispiel problemlos erben, wenn man über die erforderlichen Papiere verfügt. Bitcoin nicht, wenn der Erblasser sei Passwort nicht aufgeschrieben hat. Schreibt er es jedoch auf, riskiert er den Kontrollverlust.

Vielleicht ist es das beste, Bitcoin und alles davon Abgeleitete als Aktionskunst zu betrachten. Dann macht es wenigstens Sinn.

Digitale Scharlatane

Oktober 15, 2020Anforderungen – Requirements, By Design, Digitalisierung, eBürokratie, Freundlich zum Nutzer, Regierungsviertelöffentliche IT, Bullshit, Chatbot, digitale SouveränitätSven Türpe

Chatbots gelten den EDV-Experten in deutschen Amtsstuben heute als so modern und zukunftsweisend wie einst die Blockchain-Technologie. Wieder einmal überschätzen sie banale Technik grandios, ohne sich um den Anwendungsnutzen und die Benutzerinteraktion zu scheren. Oder wissen sie, was sie tun und setzen Chatbots aus denselben Gründen auf, aus denen sich Kleinstadtbürgermeister bei feierlichen Eröffnungen neuer Spielplätze oder Radwege fotografieren lassen, nämlich um dabei gesehen zu werden? Immerhin gelten Chatbots in Deutschland als zukunftsträchtige KI, damit zeigt man sich gerne.

Die Bundesverwaltung zeigt sich aus aktuellem Anlass mit dem Chatbot C-19 zum Thema Coronavirus. Nach eigener Aussage hat man weder Kosten noch Mühen gescheut, um dieses zukunftsweisende Technologieprojekt umzusetzen:

„Hinter C-19 steht ein interdisziplinäres Team in den beteiligten Ministerien und Ämtern, beim Beauftragten der Bundesregierung für Informationstechnik und beim IT-Dienstleister des Bundes. Das Team besteht aus Programmiererinnen und Programmierern, Trainerinnen und Trainern, Redakteurinnen und Redakteuren, Softwarearchitektinnen und -architekten, Administratorinnen und Administratoren und weiteren Wegbegleiterinnen und Wegbegleitern sowie Fürsprecherinnen und Fürsprechern, die ihn mit Informationen versorgen, beim Lernen unterstützen und sich um das Wohlergehen von C-19 kümmern.“

Müsste ich raten, wo das Budget herkommt, würde ich auf die KI-Strategie der Bundesregierung tippen, denn die Bundesregierung möchte, dass wir KI-Weltmeister werden, und wenn die Regierung etwas möchte, dann ist das in den Amtsstuben Gesetz. Unter diesen Umständen kann man nicht nicht KI machen und so verspricht man das Blaue vom Himmel:

„In Form eines Chats kann C-19 mit Ihnen ein Gespräch führen und soll Ihnen als Bürgerinnen und Bürgern so den Zugang zu fachlichen Inhalten der Ministerien, Ämter und Institutionen des Bundes erleichtern. Er ist um Antworten nicht verlegen und ist sogar bereit, aus Ihren Fragen mehr zu lernen und seine Wissensbasis zu Corona stetig zu erweitern. Mit C-19 wird ein Prototyp für den Aufbau einer bürgernahen Kommunikation mit Hilfe einer lernenden Technologie entwickelt.“

Nicht nur diesem Anspruch wird C-19 nicht gerecht, sondern auch keinem anderen vernünftigen. Gespräche führen kann der „Chatbot“ schon mal nicht, das überfordert ihn:

Am besten füttert man C-19 einfach mit Stichworten wie eine Suchmaschine. Dann verhält er sich auch wie eine Suchmaschine und liefert Ergebnisse:

Eine unmittelbare Antwort auf seine Frage bekommt man selten, auch wenn man eine formuliert, sondern in aller Regel einen Link und dazu einen Sermon unterschiedlicher Länge in schönstem Bürokratendeutsch:

Manchmal bekommt man auch nur den Sermon und keinen Link dazu. Ob es sich auch um eine Antwort auf die gestellte Frage handelt, bleibt dabei Glückssache:

Irgendwann muss auch dem interdisziplinären KI-Projektteam klargeworden sein, dass es sich bei seinem Chatbot in Wirklichkeit um eine banale Websuche handelt. Bietet C-19 weitere Informationen an, kann man direkt aus einem Menü wählen, welches dann – auf dem Umweg über ein inszeniertes Selbstgespräch des Bots – das Ergebnis liefert:

C-19 ist also in Wirklichkeit eine Suchmaschine, die sich hinter einem chatartigen Interface verbirgt, dadurch umständlich zu nutzen ist und ihre Tarnung nur kurz durchhält. Das ist keine Kinderkrankheit, die sich irgendwann gibt, sondern Resultat eines Vorgehens, in dem Benutzerinteraktion und Anwendungsnutzen keine Rolle spielen. Das Entwicklungsziel lautete anscheinend nicht, eine sinnvoll und leicht verwendbare Anwendung, Funktion oder Informationsdarstellung anzubieten, sondern um jeden Preis mit einem Chatbot gesehen zu werden.

Wer sich nur ein wenig mit Interaktionsdesign beschäftigt, kommt schnell darauf, dass der Austausch wohlformulierte Sätze in natürlicher Sprache selten der geeignetste, einfachste Modus der Mensch-Maschine-Interaktion ist. Eingaben werden nicht einfacher, wenn man ganze Sätze tippt, sondern anstrengender; diese Anstrengung bleibt vergebens, wenn der Computer am Ende doch nur auf Stichworte reagiert oder schlechte Antworten gibt.

Ausgaben müssen knapp und prägnant sein und dürfen wesentliche Informationen nicht in nutzlosem Rauschen verstecken. Styleguides für Benutzerschnittstellen sind deshalb voll von Empfehlungen, wie man Rauschen entfernt. Schon die Frage: „Möchten Sie mehr erfahren?” ist als Beschriftung eines Buttons zu lang, „Mehr erfahren“ oder auch nur „Mehr“ spart allen Zeit. Selbst bei kürzeren Texten sorgt die Chatdarstellung für eine geringe Informationsdichte auf dem Bildschirm und bietet keine Möglichkeit, alle relevanten Informationen oder eine übersichtliche Aufstellung derselben auf einen Schlag auf den Schirm zu bekommen.

Mit Vorteilen hat man sich diese Defizite nicht erkauft. C-19 lässt selbst offensichtlichste Gelegenheiten zur Interaktion ungenutzt. Erklärt etwa jemand der Suchmaschine, einige Symptome einer Infektion zu verspüren, böten sich Rückfragen nach weiteren Symptomen sowie umfassende, klare Verhaltensmaßregeln an. Doch so weit wollte niemand denken:

Was stattdessen herauskommt, wenn man tatsächlich nützliche Informationen sinnvoll verfügbar machen möchte, die Benutzerinteraktion ausgehend von diesem Ziel gestaltet und über die erforderliche Designkompetenz verfügt, demonstriert Google. Dort muss man nicht einmal seine Anfrage selbst zu Ende tippen, sondern bekommt nach wenigen Wörtern den passenden Fortsetzungsvorschlag:

Dessen Auswahl liefert ein sorgfältig aufbereitetes Ergebnis: Verhaltensmaßregeln in wenigen einfachen Hauptsätzen ohne ein überflüssiges Wort oder in Stichpunkte, Verweise auf weitere Informationen sowie leichter Zugang zu Antworten auf ähnliche Fragen, alles übersichtlich aufbereitet mit einer hohen Informationsdichte und schnell zu erfassen.

Wer etwas allgemeinere Stichwörter als Suchbegriffe eingibt, bekommt so viel Information, wie sich auf einer Bildschirmseite unterbringen lässt:

Auch auf die unspezifische Symptomschilderung liefert Google zwar keine Rückfrage, aber eine passende Antwort:

Hinzu kommt, dass Google jeder kennt und dass das bis auf einige zwanghafte Nonkonformisten auch jeder dort sucht, während man vom Chatbot C-19 der Bundesverwaltung nur zufällig erfährt. Mich hat das Randgruppenmedium Twitter auf C-19 aufmerksam gemacht.

C-19 ist nutzlos. Der Chatbot ist keiner, seine Gestaltung lässt keine kompetenten Bemühungen um Nutzen und Usability erkennen und mit der Suchmaschine Google sind wir besser bedient. Das wird sich auch nicht ändern, wenn man weiter am Bot herumbastelt, denn der gewählte Ansatz ist nicht fortschrittlich, sondern unsinnig und kein Stück nutzerorientiert. Zu befürchten ist jedoch, dass man noch lange daran herumbasteln wird, aus denselben Gründen, aus denen man damit begonnen und sein Scheitern nicht bemerkt hat.

Kein Wunder, dass es mit der Digitalisierung der Verwaltung so schleppend vorangeht, wenn maßgeblichen Akteuren das Immunsystem gegen Scharlatanerie fehlt. Wir sind nicht mehr nur digital rückständig, wir verlieren langsam den Kontakt zur Realität. Zwischen dem „Chatbot“ der Bundesverwaltung und einem sinnvoll gestalteten User Interface nach dem Stand der Kunst liegen Welten und sie liegen nicht hinter, sondern vor dem Bot. So wird das nichts mit der digitalen Souveränität.

PS (2020-10-21): Wenigstens die Erfahrungen mit Karl Klammer alias Clippy sollte man kennen, wenn man was mit Chatbots machen möchte.

Attack Scenario ≠ Threat

Oktober 14, 2020Anforderungen – Requirements, Bedrohung, English, How to, Security, Videorisk assessment, threat modelSven Türpe

The below video gives an example of what some people would call a threat model. For all I can tell the video leaves out some detail but is otherwise accurate. Why does it appear hilarious or silly rather than reasonable?

As a joke the video exploits a mismatch between the sensible, even verifiable analysis it presents and the ridiculous assumptions it implies. If this attack scenario manifested itself it would play out pretty much as presented. However, the implied very narrow and specific mode of operation – firing cannon rounds at computers – does not correspond with the behavior of any reasonably imaginable threat agent. Any agent with the capability to deploy main battle tanks is facing a wide range of possible uses and targets. Shooting individual personal computers remains not only far from being one of the more profitable applications of this capability, but guarantees a negative return. The cost is high and destruction of specific, low-value items promises rather limited gains. There are also much cheaper methods to effect any desired condition on the specific type of target, including its complete destruction.

While the attack scenario is accurate, it lacks, therefore, a corresponding threat that would produce actual attacks. Such a threat would exist, for example, if the assumed target were other main battle tanks rather than personal computers.

CoronApp-News (2020-07-19)

Juli 19, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, DigitalisierungContact Tracing, Corona-App, Corona-Warn-App, KontaktverfolgungSven Türpe

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.

In der Doppelbotschaft verheddert

Juni 17, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, Digitalveganismus, FolkloreArgumentation, Contact Tracing, Corona-App, Corona-Warn-App, digitaler Veganismus, Double Bind, KontaktverfolgungSven Türpe

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:

pic.twitter.com/U74PtiF61G

— Ruprecht Polenz (@polenz_r) June 16, 2020

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.

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.

Gefühlte Bedrohung

Juni 16, 2020Anforderungen – Requirements, Bedrohung, Covid-19, GeschäftSven Türpe

Pünktlich zum Start der Corona-Warn-App meldet sich der Vorstand des VZBV und warnt davor, „dass Restaurants, Geschäfte oder Flughäfen die Freiwilligkeit der App faktisch aushöhlen, indem sie nur App-Nutzern Zutritt gewähren“. Er hält diese Gefahr für real, doch das ist sie nicht.

Die App-Nutzung zu kontrollieren und daraufhin Kundinnen den Zutritt zu verweigern, ergibt nämlich für Unternehmen keinen Sinn. Solche Kontrollen kosteten doppelt Geld, einmal für die Arbeitszeit der Kontrolleure und einmal in Form verlorener Umsätze der abgewiesenen Kunden. Dem steht kein messbarer Nutzen des Unternehmens gegenüber. Selbst wenn man rein hypothetisch annähme, bei Infektionsfällen im Unternehmen drohe eine vorübergehende Betriebsschließung, bliebe dieses Risiko gering. Zum einen bleiben die Infektionszahlen und damit auch das mittlere Ansteckungsrisiko gering. Maßnahmen zur Pandemiebekämpfung zielen darauf, diesen Zustand zu erhalten. Zum anderen ist bei größeren Unternehmen auch ein Betrieb nicht dasselbe wie das Unternehmen, ein Supermarkt keine Supermarktkette. Doch schon bei Kleinunternehmen stellt sich die Frage: Was hätten etwa die darbenden Gastronomen davon, noch zusätzlich Gäste abzuweisen?

Realistischer erscheinen Kontrollen dort, wo Kontrollen ohne besonderen Aufwand praktikabel sind und Zutrittsbeschränkungen keinen Einfluss aufs Geschäft haben. Dies gilt zum Beispiel für Besuche in Krankenhäusern und Pflegeheimen. Auch hier stellt sich jedoch die Frage nach dem Nutzen. Das bloße Vorhandensein der App auf einem Smartphone sagt wenig aus und selbst der Warnstatus filtert nur diejenigen heraus, die unterwegs gewarnt wurden und es noch nicht bemerkt haben.

Eigentlich gehört das Kontrollszenario auch gar nicht zur Corona-Warn-App, sondern zu den zeitweise diskutierten Immunitätsnachweisen. Dort gehört die Kontrolle zum Konzept, sonst sind sie nutzlos, und die Frage ist berechtigt, unter welchen Bedingungen man sie ausnahmsweise zulassen möchte. Dies ist jedoch kein App-Problem.

CoronApp-News (2020-06-14)

Juni 14, 2020Anforderungen – Requirements, By Design, Covid-19Contact Tracing, Corona-App, Corona-Warn-App, KontaktverfolgungSven Türpe

Zweimal werden wir noch wach …

Die Corona-Warn-App soll ab Dienstag nutzbar sein. Der Bundesdatenschutzbeauftragte hält sie für solide, der TÜV für stabil und sicher (ähm*) und Fabian A. Scherschel ist für Heise Online beeindruckt. Kanzleramtschef Braun meint rückblickend, man hätte die Entwickler ein paar Tage früher beauftragen sollen; die auch zeitliche Abhängigkeit von Apple und Google hätte das freilich nicht beseitigt. Die Entwicklung kostet 20 Millionen Euro, umgerechnet etwa zwei Kilometer Autobahn in einfachem Gelände, und soll auch nach dem Veröffentlichungstermin weitergehen. Als – überwindbares – Hindernis erweist sich die bisher schleppend verlaufene Vernetzung des Gesundheitswesens.
Alexander Roßnagel hält den Datenschutz der Corona-Warn-App für beispielgebend, fordert aber dennoch weiter ein Gesetz zur Regelung jener Fragen, die sich jenseits des Datenschutz-Horizonts aufdrängen. Ein Teilproblem hat das Bundesgesundheitsministerium mittlerweile per Verordnung gelöst: Anspruch auf einen kostenlosen Test hat man jetzt auch nach einer Warnung durch die App und schon bevor Symptome auftreten.
Nach einer nicht repräsentativen Twitter-Umfrage von Malte Engeler würde jeweils etwa ein Drittel der Befragten die Corona-Warn-App auch ohne Begleitgesetz, nur mit Begleitgesetz beziehungsweise auf gar keinen Fall installieren.
Seit April verbreitet sich das Mem, wenigstens 60% der Bevölkerung müssten eine App zur Kontaktverfolgung nutzen, damit sie einen Nutzen habe. Dem widersprechen nun die Autoren der Studie, auf die diese Angabe zurückgeht. Auch bei geringeren Akzaptanzraten sei die Kontaktverfolgung per App nützlich, die Angabe 60% habe ein Eigenleben als Mem entwickelt.
In Nordrhein-Westfalen können nach Angaben des WDR drei Millionen Menschen die Corona-Warn-App nicht nutzen, das ist ein Sechstel der Bevölkerung.
Das Schweizer Parlament hat eine Rechtsgrundlage für den Einsatz der dortigen App geschaffen. Die App selbst lässt noch auf sich warten, sie soll Ende des Monats zur Verfügung stehen.
Die französische App StopCovid fand in den ersten vier Tagen nach ihrer Veröffentlichung eine Million Nutzer.
Unterdessen meldet die FAZ eine „Sicherheitslücke bei Corona-Apps“, die sich bei näherer Betrachtung jedoch anscheinend als lange bekannt und wenig dramatisch entpuppt.
- Ergänzung um Mitternacht: Wer tiefer in die Materie einsteigen möchte, findet hier das Paper und dort eine Diskussion dazu.
Die Briten brauchen mit ihrer App etwas länger als geplant und testen gerade eine zweite Version.
Eine ganz andere Form der Kontaktverfolgung demonstriert El País und rekonstruiert minutiös drei Virusverbreitungsereignisse in einem Großraumbüro, einem Restaurant sowie in einem Reisebus.
Für die Erfassung von Kontaktdaten in Restaurants bietet das amerikanische Unternehmen 360 Virtual Experts eine Lösung, bei der die Gäste keine App installieren müssen. Stattdessen werden sie per QR-Code auf eine Website geschickt, wo sie ihre Daten eintragen können. So ähnlich soll wohl darfichrein.de funktionieren, aber das wird weder aus der Website noch aus der Demo so recht klar. Fertiger wirkt Miss Racoon aus dem Taunus.

*) Den TÜV gibt es gar nicht und das mit dem Damm in Brasilien war ein anderer.

Plattform, mit Betonung auf platt

Mai 31, 2020Anforderungen – Requirements, Digitalisierung, Freundlich zum Nutzer, Unterwegsdigitale Plattformen, Mobilitätsplattformen, Nutzerorientierung, PlattformwirtschaftSven Türpe

Digitale Plattformwirtschaft gilt der Bundesregierung als großes Ding, seit sie bemerkt hat, dass wir keine eigene haben. Um diese Lücke zu schließen, fördert Berlin Plattformprojekte. Zum Universalleuchtturm Gaia-X, dessen Anwendungen von Chatbots für das eGovernment bis zur Krebsheilung reichen sollen, kommen die Themen der einzelnen Ressorts. Das Verkehrsministerium fördert, naheliegend, die Mobilitätsplattform Stadtnavi, die nicht weniger verspricht als Mobilität gemeinsam neu zu denken. Das Ergebnis ist Asche, nämlich ein notdürftig als Plattform verkleideter Karten- und Routenplanungsdienst, der seine Claims statt auf die Hauptsache direkt auf Nebengebiete wie Open Data, Open Source und Datenschutz legt. Zu kurz kommt wie so oft die Nutzerorientierung und damit das, was andere Plattformen erfolgreich macht.

Der Fairness halber sei gesagt, dass Stadtnavi nach eigener Aussage noch nicht fertig ist und das Projektbudget mit 370.000 Euro überschaubar bleibt. Gleichwohl lässt sich bereits eine Richtung erkennen. Stadtnavi bietet im Wesentlichen einen Karten- und Navigationsdienst, der verschiedene Verkehrsträger berücksichtigt und der mit Echtzeitdaten zum Beispiel über freie Parkplätze, Ladestationen, Mitfahrgelegenheiten, Busverspätungen und so weiter angereichert wird. Richtig verpackt sind solche Dienste unbestritten nützlich, das zeigen die Navigationssysteme in vielen Autos, Karten- und Navigationsapps für Smartphones sowie der DB Navigator. Anders als der DB Navigator, der auch Fahrkarten verkauft und Bahnreisende unterwegs unterstützt, bleibt Stadtnavi jedoch auf der Metaebene: Man kann sich dort über Mobilität informieren, sonst nichts.

Gemessen am eigenen Anspruch, für saubere Luft zu sorgen, wie auch an den Erfolgsvoraussetzungen für ein Plattformgeschäft drückt man sich vor der eigentlichen Herausforderung: Mobilität nutzerorientiert anders zu organisieren. Dazu müsste man nicht nur irgendwas mit Internet machen, sondern echte und konkurrenzfähige Mobilitätslösungen bieten. Messen lassen müssen sich solche Angebote am Auto, das bei vielen Menschen vor der Tür steht und darauf wartet, gefahren zu werden. Das Auto vor der Tür befriedigt bequem und flexibel eine breite Palette an Mobilitätsbedürfnissen. Wer sich einmal daran gewöhnt hat, einfach einzusteigen und loszufahren, findet kaum einen Anlass, sich überhaupt über Alternativen zu informieren. Wer es dennoch tut, wird häufig in seiner Entscheidung für das Auto bestärkt. Mit Ausnahme der Schnellbahnsysteme in Großstädten und Ballungsräumen bleibt der öffentliche Nahverkehr der individuellen Fortbewegung – einschließlich Fahrrad und Taxi – oft unterlegen.

So verwundert nicht, dass eine kommerzielle Plattform wie Uber, in deren Motivation saubere Luft so wenig eine Rolle spielt wie die Arbeitsbedingungen ihrer scheinselbständigen Fahrer, einen Taxidienst anbietet. Ein Ubertaxi ist so bequem wie das eigene Auto vor der Tür, erspart einem jedoch den Ärger damit und steht im Gegensatz zum eigenen Auto auch am Zielflughafen auf Wunsch vor der Tür. Ob man Uber deswegen auch gestatten sollte, an die Stelle der bisherigen Taxiwirtschaft mit ihrem vergleichbaren Angebot zu treten, sei dahingestellt. Jedenfalls bieten alte wie neue Taxis heute echte Mobilitätsplattformen mit einem Smartphone-Interface, die digital eine Schar mehr oder minder unabhängig arbeitender Dienstleister koordiniert.

Erfolgreiche Plattformen vernetzen Anbieter und Kunden so, dass für alle ein Mehrwert entsteht. Von Amazon zum Beispiel bekomme ich einen Online-Shop für fast alles, was man überhaupt kaufen kann. Manches liefert Amazon selbst, anderes kommt von unabhängigen Händlern, die (auch) über Amazon verkaufen. Mir erleichtert Amazon das Leben, weil ich einmal bestelle und dann in den nächsten Tagen Klemmstifte für die Heizung aus der Oberlausitz, Ersatzteile für meine Fahrradtaschen aus dem Schwarzwald und eine Fahrradbremse aus dem Amazon-Lager geliefert bekomme. Den Händlern nimmt es einen Teil des Shop-Betriebs ab und führt ihnen Kunden zu. Amazon sorgt dafür, dass das alles reibungslos funktioniert. Analog bekomme ich von Apple, Google oder Microsoft nicht einfach ein Gerät oder ein Betriebssystem, sondern Appstores, aus denen ich mir über viele Anbieter hinweg meine Anwendungslandschaft zuammenklicke und Updates bekomme.

Eine echte und nützliche Mobilitätsplattform müsste dasselbe tun und die Verkehrsbedürfnisse ihrer Nutzerinnen und Nutzer besser und einfacher befriedigen als ohne sie. Ein Ansatz dazu ist die echte Vernetzung verschiedender Verkehrsträger nicht nur in Form integrierter Navigation und Fahrplanauskunft, sondern zu einem nützlichen Mehrwertdienst. Möchte ich zum Beispiel nach Frankfurt oder über Frankfurt irgendwohin fahren, muss ich erst einmal zum Bahnhof kommen. Ich wohne zwischen zwei etwa gleich weit entfernten Strecken, auf denen jeweils S-Bahnen und Nahverkehrszüge und auf einer auch nutzbarer Fernverkehr fahren. Die ÖPNV-Anbindung ist in einer Richtung besser als in der anderen, und unabhängig davon etwa einen Kilometer Fußweg entfernt. Mit einem eigenen Fahrzeug, das ich am Bahnhof parke – egal ob Fahrrad oder Auto – beschränke ich mich für die Rückfahrt auf eine der beiden Strecken. Mit einem Rollkoffer im Schlepp fällt das Fahrrad aus und ein eigenes Auto habe ich gar nicht.

Möglicherweise könnte ich mich für eine Plattform begeistern, die mir in dieser Situation das Denken und Organisieren abnimmt. So einer Plattform würde ich einfach sagen, dass ich jetzt nach Frankfurt möchte. Daraufhin bekäme ich die Antwort: „Kein Problem, kostet 25 Goldstücke, Sie werde in zehn Minuten abgeholt. Dürfen wir Sie am Zielort noch irgendwo hinbringen?“, oder auch: „Um die Ecke steht ein freies Mietfahrrad. Wenn Sie darauf spätestens halb drei gen Westen reiten, bekommen Sie die nächste Regionalbahn oder notfalls ein paar Minuten später die nachfolgende S-Bahn. Möchten Sie das Rad bis dahin reservieren?“ Für die zweite Variante fehlt es meiner Kleinstadt an Mieträdern, die gibt es nur in der größeren Nachbarstadt. In der ersten wüsste der Fahrer, der mich abholt, dass ich mit der Bahn weiter möchte und zu welchem Bahnhof er mich bei der aktuellen Verkehrslage fahren soll. In beiden Fällen hätte sich jemand Gedanken gemacht, was mein Mobilitätsbedarf ist, wie er sich befriedigen lässt und wie das für mich möglichst einfach wird. Dafür jedoch etwas mehr nötig als nur Auskünfte.

Nützlich machen könnte sich eine Mobilitätsplattform auch in Ausnahmesituationen. Unsere alltägliche Mobilität ist stark von Gewohnheiten geprägt. Wir fahren so oft zur Arbeit, zum Einkaufen, zu Verwandten und Freunden oder zu regelmäßigen Freizeitbeschäftigungen, dass wir darüber nicht mehr nachdenken, sondern alles wie immer tun. So mancher ist schon versehentlich Samstags zur Arbeit gefahren, weil er irgendwohin wollte, der Anfang des Weges derselbe war und dann der innere Autopilot übernahm. Manchmal haben wir jedoch ungewöhnliche Bedürfnisse, müssen mehr transportieren als das Fahrrad schafft, organisieren eine Familienfeier mit dezentralen Übernachtungen und mehreren Ortswechseln oder müssen eine Zeit überbrücken, in der das eigene Fahrzeug nicht verfügbar ist oder aus sonst einem Grund alles nicht wie gewohnt funktioniert.

Mit intelligenten Angeboten für solche Situationen bekäme eine Mobilitätsplattform vielleicht auch bei jenen einen Fuß in die Tür, die sich sonst gewohnheitsmäßig ins eigene Auto setzen und das auch noch täten, wenn der Benzinpreis bei fünf Euro und die Höchstgeschwindigkeit auf Autobahnen bei 80 km/h läge. Denken wir noch einmal an Amazon: In seiner Jugend konnte der Konzern bei vielen Kunden damit punkten, dass er englischsprachige Bücher ohne Umstände lieferte. Heute sind dort noch viel mehr Dinge zu bekommen, die man in Geschäften und Kaufhäusern vor Ort vergebens sucht. Fotopapier, Feuerpoi, Fahrradständer – alles kein Problem. So etwas kommt heraus, wenn man mit einer Plattform Geld verdienen möchte, so dass man gezwungen ist, sich mit Nutzerbedürfnissen auseinanderzusetzen und echte Vorteile zu verkaufen. Aus ehrgeizarmen Förderprojekten kommt dagegen so etwas wie Stadtnavi, immer und immer wieder.

Geschichten erzählen

Mai 15, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, DigitalisierungContact Tracing, Corona-Warn-App, KontaktverfolgungSven Türpe

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)

Mai 9, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, Digitalisierung, SecurityContact Tracing, Corona-App, KontaktverfolgungSven Türpe

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

In Deutschland wird der Ruf nach einer gesetzlichen Regelung zur Kontakterfassung per App lauter. Heise und Golem berichten.
Auch in der Schweiz möchte das Parlament mitreden und lässt sich nicht von der Technik entmachten.
Amerika sieht Corona-Apps weniger erwartungsvoll entgegen als Politik und Medien hierzulande: Health Officials Say ‚No Thanks‘ to Contact-Tracing Tech. Ob es an der dank Silicon Valley größeren Erfahrung mit den Grenzen der Technik liegt, an der aus gleichem Grund geringeren Angst, wieder etwas zu verpassen, oder daran, dass man zum Thema auch mal Gesundheitsexperten zu Wort kommen lässt, mag sich jeder selbst überlegen.
Zur norwegischen Lösung Smittestopp gibt es ein FAQ auf Englisch.
PwC und Salesforce arbeiten unterdessen an Micro-Tracing für den Unternehmenseinsatz. Ob sich diese Idee durchsetzt, bleibt abzuwarten. Oft halten es Verantwortliche für klüger, nicht zu viel zu wissen, andernfalls müssen sie nämlich handeln.
Großbritannien mit seinem zentralen Ansatz ist inzwischen im Testbetrieb und hat den Quellcode veröffentlicht.
Der Hessische Rundfunk erklärt, wie Kontaktverfolgung wirklich funktioniert. Wie eine dezentrale Benachrichtigungs-App mit perfektem technischem Datenschutz zu wirksamen Quarantäneanordnungen oder auch nur einem Nachweis zum Beispiel zur Vorlage beim Arbeitgeber führen soll, bleibt indes weiter unklar.
Die indische App Aarogya Setu (Health Bridge) benutzt Positionsdaten und Arbeitnehmer dort sind zur Nutzung verpflichtet.

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

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

Mai 2, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, DigitalisierungSven Türpe

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

Das ZDF beschäftigt sich in eine halbstündigen Beitrag mit dem Chaos um die Corona-Apps.
Unterdessen gibt es für Tracing-App-Projekt der Bundesregierung noch keinen Vertrag und keine Kostenschätzung und niemand hat die Absicht, eine besondere Rechtsgrundlage zu erri-, äh, schaffen. Die Software soll jedoch auf jeden Fall Open Source sein.
Das Forum Privatheit betreibt seit einigen Wochen ein Blog zum Thema Corona-Tracing mit dem Anspruch, Orientierungswissen bereitzustellen.
Ein Beitrag von tante im Magazin Model View Culture beleuchtet die Denkweise hinter den übersteigerten Erwartungen an eine Corona-App.
Bruce Schneier findet die Idee einer automatischen Kontaktverfolgung anstelle des bisherigen Verfahrens durch die Gesundheitsbehörden „just plain dumb“, auf Deutsch: völlig bescheuert.
Matt Burgess ist ebenfalls nicht von den Segnungen der automatischen Kontaktverfolgung überzeugt und legt in Wired dar, warum die Nachteile größer sein könnten als der Nutzen.
Auch Ashkan Soltani, Ryan Calo und Carl Bergstrom halten Apps zur Kontaktverfolgung nicht für eine effektive Lösung des Problems Covid-19.
Patrick Howell O’Neill postuliert in MIT Technology Review fünf Erfolgsvoraussetzungen für die Kontaktverfolgung. Nummer eins: hunderttausend Menschen (für die USA) als Kontaktverfolger einstellen.
Ebenso halten Margaret Bourdeaux, Mary L. Gray, Barbara Grosz es für sinnvoller, menschliche Kontaktverfolger mit besseren Werkzeugen zu unterstützen.
Der britische NHS hat sich gegen die Plattform von Apple und Google und für einen zentralen Ansatz. Dieser erleichtere die risikoorientierte Benachrichtigung, die Anpassung der App an neue Erkenntnisse sowie die Begutachtung der Lösung.

Das sollte fürs Wochenende genügen.

Aufs Glatteis geführt

April 26, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, RegierungsviertelContact Tracing, Corona-App, KontaktverfolgungSven Türpe

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?

April 18, 2020Anforderungen – Requirements, By Design, Covid-19, Datenschutz, English, Security, So geht dasContact Tracing, CoronaSven Türpe

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.

Technik-PR statt Problemlösung

April 17, 2020Anforderungen – Requirements, By Design, Covid-19, PropagandaBlökchain, Corona, digitale SelbstbefriedigungSven Türpe

„Wo ist die Blockchain wenn man sie mal braucht?“, werden sich viele angesichts der Corona-Pandemie fragen, die nach neuen Ideen verlangt. War diese wunderbare Technologie nicht gerade dabei, alles, wirklich alles zu disruptieren, wo immer sie als Lösung ein passendes Problem fand? Wer, wenn nicht die Blökchain, böte sich als Krisengewinner an? Doch in den letzten Wochen hörte man wenig von der Blockchain. Sollte das Mem gut zwei Jahre nach seinem Höhepunkt seine letzten Träger verloren haben und sang- und klanglos verstorben sei?

Keine Sorge, die Blockchain lebt und tut, was sie schon immer am besten konnte: als schlechtes Beispiel dienen. Als Architekturmuster entstammt sie dem gescheiterten Versuch, einen nur minimal und rein technisch regulierten Finanzmarkt aufzubauen, der herkömmlichen Institutionen wie Aufsichtsbehörden, Justiz und Politik Widerstand entgegensetzt. Herausgekommen ist dabei wenig mehr als der Verkauf wertloser, weil in beliebiger Menge herstellbarer digitaler „Coins“ und „Token“. Um mehr als das ging es auch nie, sonst hätte man sich mit den realen Anforderungen an Bankdienstleistungen, Wertpapiere, Bezahlsysteme und so weiter auseinandergesetzt und plausible Lösungsansätze vorgelegt.

Stattdessen lieferte die Blockchain-Szene immer wieder äußerst grobe und meist offensichtlich undurchdachte Anwendungsideen und übertünchte die konzeptionellen Lücken mit überdetailliert erläuterten technischen Belanglosigkeiten. So entstand bis heute nicht mehr als Scheinlösungen für erkennbar falsch aufgefasste Probleme unter willkürlichen Annahmen.

Als hoffentlich nun wirklich letzte Runde in diesem Spiel wärmt ein Konsortium aus Bundesdruckerei, Lufthansa und anderen den Ansatz des technisch verbrämten magischen Denkens noch einmal auf und präsentiert die Idee eines digitalen Seuchenpasses „auf der Blockchain“. Dessen Inhaber sollen damit nachweisen können, dass sie regelmäßig zum Corona-Test gegangen sind und ihr letztes Ergebnis negativ war. Szenetypisch legt das Konsortium erst einmal ein dünnes Whitepaper vor.

Über so etwas kann man nachdenken. Dann muss man sich überlegen, wie so ein Seuchenpass verwendet werden soll und wie nicht, welche Information er vermitteln soll und welche nicht, wer ihn ausstellt und wer ihn bekommt, wie lange er gültig sein soll, was vom Besitz oder Nichtbesitz beziehungsweise den Eintragungen darin abhängt, wie man 80 Millionen Deutsche oder 500 Millionen EU-Bürger damit versorgt, wie man Fehler entdeckt und korrigiert, wie man den Seuchenpass und seinen Identitätsbezug kontrolliert und so weiter. Dabei müsste man auch entscheiden, ob die Idee überhaupt gut ist. Mit alldem hat sich das Blockchain-Seuchenpass-Konsortium jedoch offenbar nicht näher beschäftigt. Seine einzige Idee: Wenn man so einen Seuchenpass implementieren wollte, könnte man doch eine Blockchain-Architektur verwenden, warum auch immer.

Einen Eindruck von der Realitäts- und Anwendungsferne dieses Ansatzes vermitteln Nachrichten aus Spanien, die vor einigen Tagen erschienen. Dort hat man über einen serologischen Pass nachgedacht, der Immunisierten diese Eigenschaft bescheinigen könnte. Ansonsten geltende Einschränkungen könnten für Inhaber des Passes aufgehoben werden. Experten erteilten diesem Vorhaben jedoch eine Absage und begründen sie damit, dass so ein Pass Fehlanreize schaffe. Die mit seinem Besitz verbundenen Vorteile könnten Menschen dazu verleiten, sich mit Hoffnung auf einen leichten Verlauf der Erkrankung absichtlich anzustecken, um die Immunität und damit deren amtliche Bescheinigung zu erlangen. Zudem sei eine Diskriminierung anhand medizinischer Kriterien generell problematisch und Gesundheitsdaten seien daher aus gutem Grund vertraulich.

Man könnte noch eine Reihe weiterer Einwände vorbringen, beispielsweise die leichtere Kontrollierbarkeit allgemeiner Vorschriften beziehungsweise umgekehrt die weit aufwändigere Kontrolle individuell variierender Erlaubnisse und Verbote. Könnte man die fundamentalen Probleme lösen, stieße man sicher im Verlauf der Entwicklung auch auf die Frage, wie so ein Seuchenpass am besten zu repräsentieren sei. Um die zentrale Frage handelt es sich jedoch nicht. Im Gegenteil, man würde sich dann wahrscheinlich an existierenden Lösungen orientieren, zum Beispiel an den Online- und Digitaltickets der Bahn oder der Fluggesellschaften, die hervorragend funktionieren.

Das Blökchain-Konsortium redet hingegen lieber von Pseudonymisierung und bemerkt dabei nicht, dass es auf die gar nicht ankommt, wenn man Menschen einen persönlichen Nachweis zum Vorzeigen in die Hand drückt. Seriöse Lösungsentwicklung ist das nicht, sondern Bullshit-PR. Die beherrschen freilich auch andere. Vor wenigen Tagen machte sich erst PEPP-PT und in der Folge auch Apple und Google mit der Idee wichtig, eine App zur Kontaktverfolgung unters Volk zu bringen. Auch hier kümmerte man sich wenig um die soziotechnischen Anforderungen der Anwendung und fokussierte seine PR stattdessen auf einen Randbereich, nämlich den Claim perfekten technischen Datenschutzes. Dummerweise fragten dann doch einige, ob das denn überhaupt funktioniere und einen Sinn habe. Die Antworten stehen noch aus.

Schnapsidee: Falschfahrerwarnung als Werbegag in der Radio-App

November 12, 2019Anforderungen – Requirements, Digitalisierung, Fundbüro, How to, Propaganda, Safety, SecurityCyberangriff, Geisterfahrer, human factors, Warn-AppSven Türpe

Der Radiosender Antenne Bayern hat sich von Bosch einen Werbegag für seine App bauen lassen und mir stehen die Haare zu Berge. Es handelt sich um eine neue Funktion in der App des Senders, eine Falschfahrerwarnung. Das noble Ziel: „Keine Verkehrstoten mehr durch Falschfahrer“, doch der Weg erscheint fragwürdig.

Die Warnfunktion besteht offenbar aus zwei Teilen. Der eine erkennt Falschfahrten daran, dass sich eine aktive Instanz der App in der falschen Richtung durch eine Autobahnauffahrt bewegt, und meldet dieses Ereignis an einen Clouddienst. Der andere empfängt Warnmeldungen und gibt sie aus. Nach eigenen Angaben hat man dabei auch an den Datenschutz gedacht. Technisch ist das so weit plausibel und den Datenschutz glaube ich einfach mal ohne Prüfung. Wenig Sinn ergibt jedoch das Konzept insgesamt, wenn als übliche Anforderungen an einen Sicherheitsmechanismus erstens Verlässlichkeit verlangt und zweitens die Anpassung der Technik an den Menschen.

Die Verlässlichkeit scheitert daran, dass sie Warnfunktion in einer Radio-App steckt. Erkannt werden nur Falschfahrer, welche die App benutzen und die Funktion aktiviert haben, gewarnt ebenso nur Nutzer der App mit aktivierter Warnfunktion. Laut den Mediadaten für Antenne Bayern hat die App im Monat knapp 300.000 „Unique User“. Das entspricht etwa der Einwohnerzahl von Bayerns drittgrößter Stadt Augsburg oder weniger als 2,5% der bayerischen Bevölkerung. Gehört ein Geisterfahrer nicht zu dieser Minderheit, warnt auch niemand vor ihm. Nach Angaben von Bosch steckt die Funktion noch in einigen anderen Apps, aber das ändert nichts am grundlegenden Problem, dass Entertainment-Apps kein guter Träger für Sicherheitsfunktionen sind.

Selbst wenn die Warnfunktion auf jedem bayerischen Mobiltelefon aktiv wäre, übersähe sie immer noch ausgerechnet ortsunkundige Auswärtige sowie jeden, der das Telefon zu Hause ließe, dessen Akkuladung zur Neige ginge oder der im Funkloch geisterführe. Umgekehrt hätten Bayern auswärts wenig von der Warnfunktion, nähmen sie per App zwar ihren Lieblingssender mit, begegneten jedoch in der Fremde falschfahrenden Saupreißn ohne App. Man müsste schon gewaltiges Glück in einem nicht sehr wahrscheinlichen Unglück haben, um aus der App überhaupt jemals eine gerechtfertigte und spezifische Warnung zu erhalten.

Nicht verlässlich scheint die App auch im Hinblick auf die Abdeckung relevanter Gefahrensituationen. Geisterfahrer im engeren Sinne können überall auftreten und zur Gefahr werden, wo Straßen getrennte Richtungsfahrbahnen haben und hohe Geschwindigkeiten gefahren werden. Laut Beschreibung erfasst die App nur Autobahnen und lässt damit Bundesstraßen und andere autobahnähnliche Schnellstraßen unberücksichtigt. Darüber hinaus würde mich interessieren, wie das System mit ausgedehnten und unkonventionellen Falschfahrten umgeht. Bei mir vor der Haustür schaffte ein betrunkener Lkw-Fahrer vor einem Jahr eine Geisterfahrt von einem Rastplatz über 21 Kilometer und ein Autobahnkreuz, bevor er gestoppt wurde. Wer nur Auffahrten überwacht, müsste sehr großflächig vor der Gefahr warnen, um alle Betroffenen erreichen zu können.

Unklar bleibt aus der kurzen Erläuterung, wie hoch das Risiko von Fehlwarnungen ist. Merkt es die App oder die Cloud dahinter, wenn etwa ein Bauarbeiter Antenne Bayern hört und sich bei der Arbeit falsch herum durch eine Autobahnabfahrt bewegt? Oder ein Autofahrer, der eine Panne hat und mit dem Händi in der Tasche ordnungsgemäß das Warndreieck aufstellt? Und wie steht es um Manipulationsmöglichkeiten? Was passiert, wenn jemand mit aktiver App in der falschen Richtung neben der Abfahrt herläuft? Wie ist der Clouddienst gegen das Einspeisen falscher Daten aus anderen Quellen als der echten App geschützt?

Daneben stellen sich bei einer solchen Funktion Fragen der benutzergerechten Gestaltung. Falls die App verlässlich warnen könnte, so müsste sie den betroffenen Fahrern – dem Geisterfahrer sowie jenen, denen er entgegenkommt – eine wirksame Warnung übermitteln. Da Geisterfahrten selten sind, wird es sich in der Regel um die erste Warnung dieser Art handeln, die der Fahrer erhält, und dann bleibt keine Zeit zum Nachdenken.

Unter diesen Umständen kommt eigentlich nur eine akustische Warnung mit einer direkten Handlungsanweisung in Frage. Vorbilder dafür liefert jedes moderne Flugzeugcockpit in unmittelbaren Gefahrensituationen. So warnt das Ground Proximity Warning System (GPWS) vor bevorstehendem Bodenkontakt und das Traffic Alert and Collision Avoidance System (TCAS) vor Zusammenstößen mit anderen Flugzeugen. Beide Systeme sagen den Piloten in knappen Worten, was sie tun sollen, denn für alles andere ist keine Zeit. Im Falle des TCAS wird die Anweisung zudem mit dem anderen Flugzeug koordiniert, so dass die Piloten des einen Flugzeugs zum Steigen und die anderen zum Sinken aufgefordert werden. Piloten werden zudem darauf trainiert, mit diesen Warnungen richtig umzugehen. Demgegenüber lenkt eine App auf dem Händi mit einer ungewohnten Warnung eher ab als dass sie hülfe und auf eine situationsabhängige Ausweichanweisung hoffen Betroffene wohl vergebens.

Im Auto und erst recht in einer Radio-App muss man sich außerdem noch Gedanken darüber machen, wie man wirklich wichtige Informationen aus dem Geplapper der Radiomoderatoren, des Navigationsgeräts oder des E-Mail-und-Kurznachrichtenvorlesers heraushebt. Vielleicht ist der Sprachkanal dann doch keine gute Wahl und es wäre besser, den entgegenkommenden Geisterfahrer im Head-Up-Display mit einem größer werdenden roten Punkt zu markieren.

In der vorliegenden Form ist die Falschfahrerwarnung in der Radio-App nichts weiter als ein Werbegag und daran änderte sich wenig, machten möglichst viele Menschen in Bayern mit, wie es sich der Sender wünscht. Eine sinnvolle Warnfunktion müsste Falschfahrten überall verlässlich, aber ohne Fehlarme und Manipulationsmöglichkeiten erkennen und in Gefahrensituationen verbal spezifische, umsetzbare Anweisungen zur Gefahrenabwehr geben. Dazu müsste sie zwingend in die Fahrzeugelektronik integriert sein – Hersteller Bosch sieht dies anscheinend als Alternative zum Smartphone vor – und zur Detektion von Falschfahrten auf absehbare Zeit zusätzlich auf Sensoren außerhalb der Fahrzeuge zurückgreifen. Wäre man darauf nicht angewiesen, könnte man gleich das Entwurfsziel ändern und überlegen, wie man Falschfahrer rechtzeitig stoppt, statt vor ihnen zu warnen.

Datenschutzzirkus

Februar 4, 2019Anforderungen – Requirements, Datenschutz, SecurityDatenschutz-Taliban, VerschlüsselungSven Türpe

Schwerin, Marienplatz. Öffentlicher Raum. Kein Ort der Heimlichkeit und der Privatheit. Was hier geschieht, kann jeder sehen. So auch die Polizei, die den Platz mit Hilfe von Videokameras beobachtet. Daran regt sich Kritik: die Aufnahmen werden unverschlüsselt übermittelt.

Die ersten Idee zu einem Recht auf „Privacy“ – Ungestörtheit in einer individuellen Privatsphäre – verdanken wir dem Aufkommen der Fotografie sowie der Presse. Diese damals neue Entwicklung motivierte Samuel Warren und Louis Brandeis 1890 zu ihrem Essay „The Right to Privacy”, der als Wurzel aller nachfolgenden Diskussionen über die Privatsphäre und später über den Datenschutz gilt.

Hundert Jahre später erregte die „Videoüberwachung“ – die Aufnahme, Übertragung und Aufzeichnung von Bewegtbildern insbesondere für polizeiliche und verwandte Zwecke – den Zorn aller Datenschutzaktivisten und daran hat sich bis heute wenig geändert. Aus der Sicht eines Datenschutzaktivisten gehören Videokameras im öffentlichen Raum zu den schlimmsten Dingen, die uns dort begegnen können. Dies gelte sogar für eine bloße Anscheinsüberwachung durch Kameraattrappen, meinen sie, denn Ausgangspunkt ihrer Kritik ist die selten hinterfragte These, selbst eine nur scheinbare Möglichkeit der Fernbeobachtung oder Aufzeichnung verändere auf wundersame Weise das Verhalten der Beobachteten¹.

Mit der Realität hat dies wenig zu tun. Wir sind heute allerorten von Kameras umgeben, allen voran jene in unseren Taschenkommunikatoren, gefolgt von anderen Kameras, die zu allerlei Zwecken in der Landschaft hängen. Von nahezu jedem Ereignis mit Nachrichtenwert taucht früher oder später mindestens ein verwackeltes Händivideo auf. Die Erwartung, sich noch irgendwo in der Öffentlichkeit, jedoch nicht vor einem Kameraobjektiv aufhalten zu können, ist absurd.

Ebenso absurd ist die Vorstellung, die allgegenwärtigen Kameras könnten uns manipulieren und unterdrücken. Wäre dem so, hätten wir es nämlich längst bemerkt. Haben wir aber nicht, also stimmt die Vermutung wahrscheinlich nicht. In Wirklichkeit tun Kameras im öffentlichen Raum niemandem weh, denn sie sehen nur das, was Menschen in aller Öffentlichkeit tun.

Mit Ausnahme der Datenschützer versteht das auch jeder und so regt sich zu Recht kaum noch Protest gegen den Kameraeinsatz. Doch so leicht geben sich Aktivisten nicht geschlagen. Für Datenschützer nimmt eine Kamera nicht nur Bilder und Videos auf, sie verwandelt auch den Anblick eines öffentlichen Raums in personenbezogene Daten, die nach Schutz verlangen.

Ob diese Daten aus einer öffentlichen Quelle stammen, spielt dabei keine Rolle, denn alle personenbezogenen Daten gelten dem Datenschutz als gleich schützenswert (mit Ausnahme der besonders schützenswerten Daten, zu denen etwa die Information gehört, dass der Papst und seine Kardinäle katholisch sind). So kommt es, dass Aufnahmen aus dem öffentlichen Raum nach Auffassung der Datenschützer verschlüsselt versendet werden müssen.

Dass dies sinnlos ist und niemanden vor irgend etwas schützt, spielt keine Rolle, denn der Datenschutz schützt Daten und nicht Menschen. Der Sensor einer Digitalkamera verwandelt ungezwungene Öffentlichkeit in ein amtliches Geheimnis.

¹ Gedankenexperiment: Jemand geht in eine Bank/Spielhalle/Tankstelle, hält eine Videokamera vor sich und ruft: „Geld her, ich habe eine Kamera!“ – Würde das funktionieren? Wenn ja, warum? Wenn nein, warum nicht?

Sicherheitstechnik gehört nicht ins Gesetz

Februar 2, 2019Anforderungen – Requirements, By Design, Regierungsviertel, SecurityAuthentifektion, Cybersicherheit, Gesetz, Politik, populistische Kackscheiße, Regulierung, SPDSven Türpe

Die SPD-Bundestagsfraktion hat ein Positionspapier zum IT-Sicherheitsgesetz 2.0 beschlossen. Da stehen einige sinnvolle Forderungen drin, etwa nach Verbesserungen im Opferschutz und bei den zuständigen Behörden. Andere sind Blödsinn, allen voran jene nach einer Verpflichtung von Dienstanbietern zu spezifischen Sicherheitsmaßnahmen wie 2-Faktor-Authentisierung.

Sicherheit sei kein Zustand, lautet ein geflügeltes Wort, sondern ein Prozess. Dies gilt nicht nur für den Betrieb von IT-Systemen, sondern auch für ihre Entwicklung und Gestaltung. Konkrete Ausprägungen von Sicherheitsfunktionen stehen am Ende einer langen Folge von Entwurfsentscheidungen.

Viele dieser Entscheidungen sind das Resultat von Abwägungen zwischen verschiedenen Entwurfszielen auf verschiedenen Gebieten, zum Beispiel Funktionalität, Usability und Usability. Noch mehr Entscheidungen treffen gar nicht die Entwickler selbst, sondern der Markt und der Stand der Technik, der sich ständig weiterentwickelt.

In diesem Kontext einen sinnvollen und lange haltbaren Fixpunkt zu setzen, ist schwierig, und Politiker sind für diese Aufgabe noch weniger qualifiziert als jene, die wenigstens das Problem verstehen. Die besten Lösungen entstehen vielmehr durch fortwährende Evolution.

Ein Beispiel: Die URL-Zeile im Webbrowser begann ihre Karriere vor mehr als einem Vierteljahrhundert als einfaches Eingabefeld für Web-Adressen. Im Laufe der Zeit stellte sich heraus, dass gefälschte Websites für allerlei Angriffe benutzt werden können und man daher gut daran tut, die Benutzer eines Browsers so gut wie möglich bei der Erkennung solcher Täuschungsversuche zu unterstützen.

Dabei müssen gleichzeitig andere Ziele berücksichtigt werden, wenn die URL-Zeile dient weiterhin auch ihrem ursprünglichen Zweck. Über die Jahre haben die Browser-Entwickler gelernt, auf welche Einzelheiten es ankommt und wie man die verschiedenen Ziele gut unter einen Hut bekommt, und daraus Empfehlungen formuliert.

Diese Empfehlungen repräsentieren den aktuellen Stand; die Entwicklung wird weitergehen, die Anforderungen werden sich ändern und man wird für neue Aspekte des Problems neue Lösungen finden. Evolution eben. „Security by Design“ klingt zwar gut, aber Design ist nichts anderes als forcierte Evolution.

Spezifische Entwurfsvorgaben von Gesetzesrang grenzen diese Evolution willkürlich ein. Sie machen aus einem Lern- und Innovationsproblem eine Compliancefrage und eine bürokratische Angelegenheit. Damit erreichen sie genau das Gegenteil des Gewollten: Die Sicherheit erhöht sich nicht, sondern alle sind nur noch damit beschäftigt, gesetzliche Vorgaben einzuhalten, seien sie nun sinnvoll oder nicht.

Tatsächlich ist liegt simple 2-Faktor-Authentisierung alleine sogar schon hinter dem Stand der Technik. Wer sich moderne, das heißt nichtdeutsche Websites oder gar „die Cloud“ anschaut, findet dort ausgefeilte Systeme zum Identitäts- und Rechtemanagement, in denen die unmittelbare Benutzerauthentisierung nur ein Baustein ist.

Einige andere Bausteine sind an der Benutzerschnittstelle zum Beispiel die Verwaltung von Clientgeräten (Funktionen wie: „Alle angemeldeten Geräte abmelden“), Benachrichtigungsfunktionen („Jemand hat Ihr Passwort dreizehnmal falsch eingegeben.“), die Nichtbehinderung von Passwortmanagern sowie Recovery-Funktionen, mit denen Benutzer in verschiedenen Situationen (Passwort vergessen, gehackt, E-Mail-Adresse verändert) wieder Zugang zu ihrem Account bekommen. All diese Bausteine sind sicherheitsrelevant und jeder von ihnen sowie ihr Zusammenspiel unterliegt ebenso wie die Gestaltung der URL-Zeile im Browser der fortlaufenden Evolution.

Gesetzestexte können schon die statische Komplexität des Themas nicht fassen, von der Weiterentwicklung gar nicht zu reden. Konkrete gesetzliche Vorgaben zur Gestaltung von Authentisierungsfunktionen wären schon bei Inkrafttreten des Gesetzes veraltet oder unvollständig. Sogar als rein wirtschaftlich motivierte Marktregulierung taugt der Ansatz wenig: Ausgerechnet heimische Anbieter wie GMX und Web.de tun sich schwer mit der Zwei-Faktor-Authentisierung, während sie bei den Großen aus Amerika längst Standard ist. Ganz ohne Gesetz übrigens.

Ich wäre der Politik dankbar, wenn sie sich auf das Formulieren von User Stories* beschränken und die Technik den ITlern überlassen würden. Glauben Sie mir, meine Damen und Herren, und das möchte ich hier in aller Deutlichkeit betonen: Es ist besser so. Wer die Evolution der Technik wirklich beeinflussen möchte, sollte das indirekt über die Anreize tun.

*) Eigentlich: Anforderungen, aber die Erklärung, warum Lösungsvorschläge schlechte Anforderungen sind, wäre mir hier zu lang geworden.

PS: Jemand hat mir dieses Video zum Thema zugespielt, das ich nachträglich im Text mit verlinkt habe.

Erfolgsfaktoren für den Datenschutz durch Technikgestaltung

Oktober 13, 2018Anforderungen – Requirements, By Design, Datenschutz, SecuritySven Türpe

Die Forderung nach Datenschutz und Sicherheit „by Design“ ist schnell erhoben und gerade nach Sicherheitsvorfällen sieht rückblickend oft alles nach offensichtlicher Schlamperei aus, die man doch einfach hätte vermeiden können. Wer tatsächlich IT-Systeme gestaltet und dabei Datenschutz- und Sicherheitsanforderungen berücksichtigen soll, steht jedoch einigen Problemen gegenüber. Zum Beispiel kann man zu viel Sicherheit anstreben und sich im Ergebnis selbst blockieren, wie es die Entwicklung der Gesundheitstelematik seit ungefähr anderthalb Jahrzehnten vorführt*, oder vor unmöglichen Entscheidungen stehen, weil es zu vielfältigen Wechselwirkungen zwischen Datenschutz und Sicherheit auf der einen und allen übrigen Anforderungen und Entwurfsdimensionen auf der anderen Seite kommt. Beim Datenschutz kommt hinzu, dass anders als bei der Sicherheit Stakeholder und Angreifer zusammenfallen: Der Datenschutz beschränkt Handlungen, von denen Betreiber und Nutzer eines Systems profitieren.

Mit diesen Schwierigkeiten beschäftigt sich der Beitrag „Erfolgsfaktoren für den Datenschutz durch Technikgestaltung“ zur Konferenz „Die Fortentwicklung des Datenschutzes”, die Anfang November 2017 in Berlin stattfand. Er baut auf vorangegangenen Vorträgen (Was kommt nach „Security by Design“? Chancen der Partizipation im Software Engineering 2016 in Kassel und Security by Design? 2017 in Limburg auf. Im Konferenzband zur Tagung konnte unser Beitrag letztlich nicht erscheinen, da der Verlag über eine faire Rechteübertragung hinaus unannehmbare Forderungen an die Autoren erhob und zu Verhandlungen über die Konditionen nicht bereit war.

*) Großprojekte mit vielen Stakeholdern haben allerdings noch weitere Probleme neben dem Thema Sicherheit, an denen sie scheitern können.

Beschränkter Horizont

März 26, 2018Anforderungen – Requirements, By Design, Datenschutz, Nerds, Risiko, SecurityAnwaltsgeheimnis, besonderes elektronisches Anwaltspostfach, Ende-zu-Ende-Sicherheit, security by design, Technikgestaltung, Telekommunikationsgeheimnis, threat modelSven Türpe

Die Forderung nach Ende-zu-Ende-Sicherheit für das besondere elektronische Anwaltspostfach (beA) und andere Dienste geht auf missverstandene Anforderungen und eine eingeschränkte Sicht auf den Lösungsraum zurück. Die missverstandene Anforderung liegt in der Vorstellung, der rechtlicher Schutz der Kommunikation verlange nach technischen Garantien. Die eingeschränkte Sicht auf den Lösungsraum berücksichtigt nur ausgewählte technische Mechanismen, deren Wirkung sie überschätzt, und lässt andere Aspekte des Risikomanagements außer Acht.

✹✹✹

Die Befürworter der Ende-zu-Ende-Verschlüsselung argumentieren, der Schriftverkehr von Rechtsanwältinnen sei besonders sensibel und man müsse ihn deshalb technisch besonders gut vor unbefugter Kenntnisnahme schützen. Die besondere Sensibilität mag man annehmen, wenngleich das beA nicht der Kommunikation zwischen Anwältinnen und ihren Mandantinnen dient, sondern dem Schriftwechsel zwischen Anwältinnen und Gerichten sowie der Anwältinnen untereinander. Jedoch steht die Telekommunikation ganz allgemein unter rechtlichem Schutz durch das Telekommunikationsgeheimnis. Selbst wer sie abhören könnte, darf dies nicht und wird andernfalls verfolgt und bestraft.

Ein wirksamer rechtlicher Schutz macht kann technische Maßnahmen überflüssig machen. Umgekehrt sind individuelle Schutzmaßnahmen dort nötig, wo keine Hilfe zu erwarten ist. Im Alltag verstehen wir das auch und verzichten zum Beispiel meist darauf, unsere leicht verwundbaren Körper besonders gegen Angriffe zu schützen. Wir wissen, dass die Wahrscheinlichkeit eines körperlichen Angriffs gering ist, denn dafür sorgen Polizei und Justiz. Anders verhalten sich etwa Menschen in Kriegsgebieten, die mit solchem Schutz nicht rechnen können.Im Spektrum zwischen diesen Extremen gibt es Mischlösungen, deren Schwerpunkt auf der einen oder anderen Seite liegt. Das Ziel ist letztlich ein akzeptables Restrisiko, ganz gleich mit welchen Mitteln es erreicht wird.

Die Motivation für technische IT-Sicherheit entspringt der eingeschränkten Möglichkeit zur Strafverfolgung im Netz. Zwar gelten Gesetze auch online, doch können sich Täter leichter verstecken und selbst bekannte Täter entgehen der Verfolgung, wenn sie im Ausland sitzen. Ganz ohne Sicherheitstechnik wird ein Anwaltspostfach also nicht auskommen. Allerdings muss man sich sowohl den Schutzbedarf als auch die Sicherheitsstrategie genauer anschauen.

Interessanterweise haben Juristen in dieser Hinsicht realistischere Vorstellungen als Hacker, die perfekte Sicherheit fordern. Juristen gehen ganz selbstverständlich davon aus, dass man Sicherheitsanforderungen nicht überspitzen darf. Das Schutzniveau soll dem alternativer Kommunikationsmittel wie Telefax und Briefpost entsprechen. Auf ein theoretisches Ideal kommt es nicht an. Aus rechtlicher Sicht interessant sind dann rechtliche Implikationen, die sich beispielsweise aus der zeitversetzten Kommunikation ergeben.

Ende-zu-Ende-Verschlüsselung erfüllt keine reale Sicherheitsanforderung, sondern sie strebt ein technisch motiviertes theoretisches Ideal an. Wie ich im vorigen Beitrag erläutert habe, ist dieses theoretische Ideal im realen System kaum zu erreichen. Das ist jedoch kein Problem, da sich die realen Sicherheitsanforderungen am Sicherheitsniveau realer Kommunikationsmittel wie Post, Fax und Telefon orientieren.

✹✹✹

Den Lösungsraum verengt die Forderung nach Ende-zu-Ende-Sicherheit auf scheinbar ideale kryptografische Ansätze. Diese Ansätze sind jedoch nicht nur nicht sinnvoll, wenn man – im Gegensatz zur Gesundheits-Telematik – in endlicher Zeit ein funktionsfähiges System bauen möchte. Es gibt auch Alternativen und Aspekte, von denen die Fokussierung auf das theoretische Ideal ablenkt.

Die Befürworter der kryptografischen Ende-zu-Ende-Sicherheit kritisieren die Umschlüsselung von Nachrichten in einem Hardware-Sicherheitsmodul (HSM). Bei der Umschlüsselung wird eine Nachricht ent- und mit einem anderen Schlüssel verschlüsselt. Auf diese Weise lassen sich die Zugriffsrechte auf der Empfängerseite von der ursprünglichen Verschlüsselung auf der Absenderseite entkoppeln. So kann man Beispielsweise Vertretern Zugriff auf Nachrichten geben, die bereits vor Beginn der Vertretung vom Absender verschlüsselt wurden.

Dies schaffe einen Single Point of Failure, der das ganze System „extrem verwundbar“ mache, argumentieren die Kritiker. Das ist insofern richtig, als ein erfolgreicher Angriff auf die entsprechende Systemkomponente, ein Hardware-Sicherheitsmodul (HSM), tatsächlich sämtliche Kommunikation beträfe. Solche Angriffspunkte gäbe es freilich auch bei einer Ende-zu-Ende-Lösung noch. Alle Kommunikation ausspähen könnte beispielsweise, wer den beA-Nutzerinnen eine manipulierte Version der Software unterjubelt oder wer in die Produktion der zur Nutzung erforderlichen Smartcards eingreift.

Die damit verbundenen Restrisiken nehmen wir jedoch notgedrungen in Kauf und ergreifen Maßnahmen, um sie zu klein zu halten. So wird man beispielsweise die Smartcard-Produktion durch Zugangskontrollen und Überwachung so gut wie eben praktikabel vor unbefugten Eingriffen schützen. Nichts spricht grundsätzlich dagegen, dies auch für die Umschlüsselung zu tun – deswegen unter anderem das Sicherheitsmodul. Die Fokussierung auf das vermeintliche Allheilmittel Ende-zu-Ende-Verschlüsselung verstellt jedoch den Blick auf solche Maßnahmen, die zum Risikomanagement beitragen.

Falls wir in einem Single Point of Failure ein grundsätzliches Problem sähen und die damit verbundenen Risiken für nicht beherrschbar hielten, müssten wir jedoch nach ganz anderen Wegen Ausschau halten. Wir müssten dann nämlich nach einer organisatorischen und technischen Architektur suchen, welche die Auswirkungen eines einzelnen erfolgreichen Angriffs auf einen Teil des Systems, der Nutzer und der Inhalte begrenzt und verlässlich dafür sorgt, dass der Aufwand für erfolgreiche Angriffe proportional zu ihren Auswirkungen wächst.

Solche Ansätze hätten erst einmal überhaupt nichts mit Kryptografie zu tun, sondern mit Organisationsprinzipien. Man könnte beispielsweise ein Ökosystem verschiedener unabhängiger Lösungen und Anbieter schaffen und die Haftung angemessen regeln. Angriffe auf einen Anbieter beträfen dann nur dessen Nutzer. Mit DE-Mail gibt es sogar bereits ein solches Ökosystem, welches weitgehend brachliegt und sich nach Anwendungen sehnt.

Auf solche Fragen und Ansätze – deren Nutzen und Notwendigkeit allerdings erst nach einer gründlichen Bedrohungs- und Risikoanalyse klar wird – kommt man gar nicht erst, wenn man eine Abkürzung nimmt und blind die Anwendung bestimmter technischer Entwurfsmuster fordert.

Mit Sicherheit ins Desaster

März 20, 2018Anforderungen – Requirements, By Design, Risiko, Security, security-industrial complex, So geht dasbeA, Gesundheitskarte, security by design, Signaturgesetz, Technikgestaltung, threat modelSven Türpe

Als wäre das Desaster um das besondere elektronische Anwaltspostfach (beA) nicht schon schlimm genug, kommen nun auch noch Aktivisten aus ihren Löchern und fordern eine „echte Ende-zu-Ende-Verschlüsselung“.

Kann diesen Cypherpunks mal jemand das Handwerk legen? Eine „echte Ende-zu-Ende-Verschlüsselung“ ist für ein beA technisch eben nicht möglich, sondern als Anforderung das Rezept für ein Desaster.

Unter Laborbedingungen lässt sich gewiss ohne große Schwierigkeiten eine Public-Key-Infrastruktur (PKI) aufbauen und auf beliebig viele Teilnehmer skalieren, so dass jeder mit jedem verschlüsselt kommunizieren kann. So eine Labor-PKI löst aber nur das halbe Problem – und macht es schwer, die andere Hälfte zu lösen, die unter den idealisierten Bedingungen der Laborumgebung keine Rolle spielt.

Drei Teilprobleme, mit denen eine Lösung für die Anwaltskommunikation zurechtkommen muss, sind (1) komplizierte Zugriffsrechte, (2) der Konflikt zwischen Vertraulichkeit und Verfügbarkeit sowie (3) Veränderungen im Zeitverlauf.

Komplizierte Zugriffsrechte
Anwaltskommunikation ist nicht einfach Kommunikation von Person zu Person. Anwälte haben Gehilfen für administrative Tätigkeiten, die beispielsweise Post holen und verschicken. Diese Gehilfen brauchen ausreichende Zugriffsrechte, um ihre Arbeit zu verrichten, aber sie haben keine Prokura. Anwälte haben außerdem Vertreter für Urlaub, Krankheit usw., die von der Anwältin oder der Rechtsanwaltskammer bestellt werden. Alleine der Versuch, § 53 BRAO in eine PKI und eine Ende-zu-Ende-Verschlüsselung zu übersetzen, dürfte Entwicklern einiges Kopfzerbrechen bereiten.
Vertraulichkeit vs. Verfügbarkeit
Vertraulichkeit der Anwaltskommunikation ist wichtig, aber zweitrangig. Wichtiger ist die Verfügbarkeit. Fragen des Zugangs von Erklärungen und der Einhaltung von Fristen können einen Rechtsstreit unabhängig davon entscheiden, wer in der Sache eigentlich Recht hätte. Vor allem anderen werden Anwältinnen Wert darauf legen, dass sie unter allen Umständen verlässlich kommunizieren können. Demgegenüber genügt hinsichtlich der Vertraulichkeit oft das Schutzniveau „Telefon“.
Zeitliche Dynamik
Ein reales System zur Anwaltskommunikation muss nicht zu einem Zeitpunkt funktionieren, sondern über einen langen Zeitraum, währenddessen sich die Welt ändert. Das betrifft neben den offensichtlichen Aspekten – Hinzukommen und Ausscheiden von Nutzern in den verschiedenen Rollen, veränderte Vertretungsregelungen usw. – auch die Technik, zum Beispiel den Schlüsseltausch. Damit muss ein beA unter Berücksichtigung von (1) und (2) zurechtkommen. Darüber hinaus können sich auch gesetzliche Regelungen jederzeit ändern.

Wir brauchen deshalb keine Ende-zu-Ende-Sicherheit, sondern im Gegenteil endlich die Einsicht, dass Sicherheit:

sekundär ist und der Funktion nicht vorausgeht, sondern folgt,
keine theoretischen Ideale verfolgen, sondern reale Risiken reduzieren soll,
nicht durch formale Garantien und einzelne Wunderwaffen entsteht, sondern aus der Kombination verschiedener partieller Maßnahmen resultiert,
nicht perfekt sein muss, sondern nur gut genug.

Die Vorstellung, man könne konkurrenzfähige Anwendungen um starke Kryptographie herum konstruieren, ist vielfach gescheitert und diskreditiert. Als um die Jahrtausendwende der Online-Handel wuchs, entwickelte man kryptografische Bezahlverfahren von eCash bis SET – den Markt gewannen jedoch Lastschrift, Kreditkarte, Nachnahme und Rechnung. Das Online-Banking wollte man einst mit HBCI / FinTS sicher machen – heute banken wir im Browser oder auf dem Händi und autorisieren Transaktionen mit TANs und Apps. Das vor gut zwanzig Jahren entstandene Signaturgesetz ist in seiner ursprünglichen Form Geschichte und elektronische Signaturen haben sich bis heute nicht auf breiter Front durchgesetzt.

Wer dennoch weiter an die heile Scheinwelt der Ende-zu-Ende-Sicherheit glauben möchte, der möge sich seine Lösungen von den Experten der Gematik entwickeln lassen. Die kennen sich damit aus und sobald ~~ihr Flughafen~~ ihre Telematikinfrastruktur läuft, haben sie sicher Zeit für neue Projekte.

Vortrag: „Security by Design?“

März 15, 2017Anforderungen – Requirements, Begriffe, By Design, Events, Forschung, SecuritySDL, Sicherheit, SoftwareentwicklungSven Türpe

Triggerwarnung: work in progress

Vergangene Woche durfte ich auf dem 1. IT-Grundschutztag 2017 zum Thema Security by Design? vortragen. Das Leitthema der Veranstaltung war Application Security und ich habe passend zu unserer Forschung einen Blick auf die Softwareentwicklung geworfen. Sichere Software ist leicht gefordert, aber die Umsetzung im Entwicklungsalltag bereitet Schwierigkeiten: In frühen Phasen der Entwicklung kämpft man mit Ungewissheit und es ist schwer, Entscheidungen zu treffen; später weiß man mehr, aber die Veränderung wird schwierig – nicht nur technisch, sondern auch in den Strukturen und Routinen des Entwicklerteams.

Der Vortrag entstand aus einer früheren Fassung, die ich gemeinsam mit Andreas Poller auf dem Workshop „Partizipatives Privacy by Design“ im vergangenen Oktober in Kassel gehalten habe. Aus Andreas’ Vortrag auf der CSCW’17 habe ich mir auch Slides geborgt.

Wer die Tonspur zu den Slides hören möchte: einfach fragen.

Sicher ist sicher?

Ängste, Risiken, Vorsorge und unser gestörtes Verhältnis zur IT