Gedanken von der RightsCon: Was bildet Vertrauen?
Vom 16.–18. Mai hat Elisa für den Prototype Fund die RightsCon in Toronto besucht – und dort erforscht, wie andere Projekte Vertrauensprozesse implementieren bzw. welche Rolle Vertrauen in der Technologieentwicklung generell spielt. Mitgebracht hat sie drei Learnings, Bruce Schneiers Wisdom und Ahornsirup:
Die RightsCon ist eine jährliche Konferenz, auf der sich Aktivist*innen, Menschenrechtsverteidiger*innen, Tech-Coaches und Entwickler*innen aus aller Welt treffen um sich über die Herausforderungen an der Schnittstelle von digitaler Entwicklung und Menschenrechten austauschen.
Mein Ziel war es, andere Funder zu treffen, neue Projekte kennenzulernen und über meinen eigenen Tellerrand zu gucken. Als thematischen roten Faden hatte ich mir vor allem die Vorträge und Workshops gesucht, die sich um das Thema Sicherheit und Vertrauen drehen.
Hier sind meine drei liebsten Learnings aus drei Tagen dichtem Programm:
White Paper, Vertrauen und Design
Was macht ein digitales Werkzeug, das sichere Kommunikation ermöglichen soll, vertrauenswürdig? Ein Whitepaper über die Krypto, würden Entwickler*innen wahrscheinlich sagen, oder ein ordentliches Audit. Das ist sicher richtig, aber die Antwort ist nicht auf die Nutzer*innen übertragbar. Ihr Vertrauen hängt eher davon ab, wie gut das User-Experience-Design des Werkzeugs ist. Ist das Tool einfach zu bedienen? Ist immer klar, was gerade passiert und was zu tun ist? Einfache Design-Entscheidungen können dazu führen, dass ich mich befähigt oder machtlos fühle. Wer in Signal schon einmal die Nachricht “Your security number with XY has changed.” bekommen hat, weiß, wovon ich spreche: Nichts verrät mir, warum ich diese Nachricht bekommen habe, oder was ich jetzt tun muss. Ich kann sie nur wegklicken und mich wundern. Natürlich sind tatsächliche Sicherheit und die Sicherheit, die das Design vermittelt, nicht aneinander gekoppelt. Wenig bis überhaupt nicht sichere Werkzeuge wie Telegram oder WeChat nutzen einfache Design-Tricks, um Privatheit vorzugaukeln, wo sie nicht existiert. Umso wichtiger ist es, dass sich die guten(TM) Werkzeuge nicht auf ihrer technischen Qualität ausruhen, sondern kontinuierlich an ihrer Benutzbarkeit arbeiten und dafür aktiv das Feedback der Nutzer*innen einholen.
Wie Coaches für Security-Tools dafür sorgen können, dass Nutzer*innen-Feedback die Entwickler*innen erreicht
Wie erhält ein Tech-Team überhaupt Nutzerfeedback? Zum Beispiel über Workshops mit Freiwilligen, in denen ein Werkzeug getestet und Probleme dokumentiert werden. Dabei ist die Wahrscheinlichkeit aber groß, dass die Teilnehmenden nicht allzu weit von der Bubble der Entwickler*innen entfernt sind. Von vielen Security-Tools im weitesten Sinne profitieren bedrohte Minderheiten, denen Coaches die technischen Lösungen vorstellen und ihnen den sicheren Umgang und das nötige Tech-Know-How vermitteln. Mit diesen “Power Usern” kommen die Entwickler*innen selbst aber so gut wie nie in Kontakt. In einem Workshop vermittelten Tech-Trainer*innen von verschiedenen Kontinenten einen einfachen Weg, wie sie während ihrer Coachings Nutzerfeedback dokumentieren, ohne die Coachings dafür zu unterbrechen oder unnötig zu verlängern: In Absprache mit den Entwicklerinnen formulieren sie kurze Aufgaben zu einer konkreten Funktionalität an (z.B. “Lege einen Gruppenchat an und füge 3 Teilnehmer*innen hinzu.”). Diese Aufgaben werden in das Coaching integriert, und auf deinem Dokumentationsblatt halten die Teilnehmenden selbst den Schwierigkeitsgrad der Aufgabe fest und kommentieren das Ergebnis. So wird es möglich, quantitatives Feedback zu einzelnen Usability-Features strukturiert an die Entwickler*innen zurückzugeben und so Schritt für Schritt das eigene Werkzeug zu verbessern.
Du bist nicht allein – diese Checklist kann bei der Konzeption und Entwicklung digitaler Werkzeuge helfen
In einem Workshop präsentierte eine Gruppe aus Entwickler*innen und Designer*innen ihre “Digital Security and Privacy Protection UX Checklist”.
Achtung Achtung: Die Checkliste ist nicht vollständig, und wird es wohl auch nie sein. Sie kann aber dabei helfen, sowohl Sicherheit als auch Nutzbarkeit frühzeitig während der Konzeption und der Umsetzung einer neuen Anwendung mitzudenken. Beide Aspekte erfordern strategische Entscheidungen. Werden die zu spät getroffen, droht aus einem Werkzeug Flickwerk zu werden. Dieses Zitat spricht uns vom Prototype Fund aus dem Herzen:
“Before you start building the tool, platform, or technology, you want to know the people who will be using them. You need to collect and analyze information from your stakeholders and research participants.”
Privacy vs. Security? Security vs. Security!
In einer Panel-Diskussion brachte Bruce Schneier, ein Urgestein der Debatte um Computersicherheit, eine bedenkenswerte Antwort auf die Frage, wie wir als Community, die sich für den Schutz der Privatsphäre einsetzt, auf den von staatlicher Seite geäußerten Vorwurf reagieren können, dass wir bereit dazu seien, die Privatsphäre Einzelner über die Sicherheit Aller zu stellen – mit staatlich verordneten Hintertüren sei es doch so viel einfacher, durch die Überwachung möglicher Gefährder für die Sicherheit aller zu sorgen. Auf dieses Argument ließ sich Schneier nicht einmal ein: Die Gegenüberstellung von Schutz der Privatsphäre und dem Bedarf nach Sicherheit sei eine Wortwahl, die er nicht übernehmen wolle. Stattdessen sieht er einen Konflikt von zwei unterschiedlichen Sicherheitsbedürfnissen:
“Our digital communications security is threatened by one set of bad actors, our physical security by another set of bad actors.”
