Software soll sich am User orientieren und nicht umgekehrt - diese simple Weisheit gilt bei Sicherheitsprogrammen besonders. Nur wenn die Applikation sich jederzeit verhält wie erwartet, eine verständliche Sprache spricht und optische Hilfen gibt, schützt sie den Anwender ausreichend.
Anwender haben oft sehr konkrete Vorstellungen, wie Software zu funktionieren hat und in welcher Reihenfolge welche Tätigkeiten anstehen sollen. Weicht ein Applikation von diesem Schema ab, bereitet sie den Benutzern große Schwierigkeiten. Als abschreckendes Beispiel eignet sich das Erzeugen eines Schlüsselpaars (öffentlicher und privater Key). Wer an einer Unix-Kommandozeile sitzt, wirft gewöhnlich GPG oder OpenSSL an, füttert die Kommandozeile mit einer länglichen Folge von Optionen, reagiert auf Nachfragen des Programms und wartet darauf, dass das Tool die Schlüssel an der vom User vorgegebenen Stelle ablegt. Für CLIs (Command Line Interfaces) ist dieser Ablauf normal, die Benutzer erwarten es nicht anders.
Dummerweise haben die GUI-Entwickler das Interface stur übernommen: Die Option »-k Schlüssellänge« mutiert mal zu einer Combobox mit einer Liste vorgegebener Werte und aus »-a Algorithmus« wird vielleicht ein Satz Checkboxen. Abbildung 1 zeigt eines dieser missglückten Designs. Dieses Exemplar scheut nicht einmal davor zurück, in einem Expertenmodus den User wieder auf die Kommandozeile zurückzuwerfen.
Abbildung 1: KGPG dient als grafisches Frontend zu GPG. In diesem Dialog erzeugt der User einen neuen Schlüssel. Leider orientiert sich die Oberfläche viel zu sehr am Kommandozeilen-Original.
Dieses GUI ist lediglich eine grafische Fortsetzung des CLI, die jeder Kommandozeilenoption ein grafisches Element zuordnet. Doch damit nicht genug: Die Optionen verteilen sich manchmal über mehrere aufeinander folgende Fenster. Eine große öffentliche CA (Certification Authority) geht noch weiter, sie quält ihre User durch elf Bildschirmseiten, in denen sie ihre Daten eintippen, bevor sie ein Schlüsselpaar erzeugen dürfen.
User, die das Kommandozeilen-Interface kennen, finden sich in diesen GUI-Umsetzungen noch ganz gut zurecht. Wer über diesen Erfahrungsschatz nicht verfügt, wird die Oberfläche dagegen kaum verstehen. Ihm bereitet es dann enorme Mühe, ein Schlüsselpaar für einen E-Mail-Client oder für den Webserver anzulegen. Er wird sich mindestens folgende Fragen stellen:
Kurz gesagt: Dieser Dialog ist unbrauchbar, das Beste, was ihm passieren kann, ist ein freundliches »rm -rf«.
Auch die tollste Anwendung ist für die meisten Benutzer nur ein Werkzeug und kein Selbstzweck. Statt sich auf die Haken und Ösen der Schlüsselerzeugung zu konzentrieren, braucht das Programm einen anderen Fokus. Der User will nur eine Aufgabe erledigen - dabei sollte ihn das Programm so weit möglich unterstützen und nicht behindern.
Von Microsoft stammt der Name "Activity-Based Planning". Wer diesem Designprinzip folgt, stellt zunächst eine Liste von Aufgaben zusammen, die der Benutzer erledigen will, und baut das Userinterface dann passend zu diesen Abläufen. Herkömmliche GUIs stapeln dagegen atomare Operationen und erwarten, dass der Benutzer die wichtigen Stellen selbst findet. Dabei jagen sie ihn durch unübersichtliche Menüs und verworrene Dialoge.
Aktivitätsorientiertes Planen richtet sich danach, wie Anwender ihre Wünsche äußern. Sie setzen sich Ziele wie "Meine Patientenakte muss vertraulich bleiben" oder "Ich will sichergehen, dass die Person/Firma, mit der ich gerade rede, auch die ist, die sie vorgibt zu sein". Niemand denkt "Ich will ein X.509v3-Zertifikat zusammen mit Triple-DES-Verschlüsselung verwenden, um meinen Kommunikationskanal abzusichern".
Eine weitere Lehre daraus: Statt mit dem Vokabular der Security-Experten zu jonglieren, muss Software Sicherheitsaufgaben mit den Worten präsentieren, in denen der Anwender denkt und die er versteht. Nur so haben die User eine Chance, zu begreifen, was sie gerade machen, und werden die vorhandenen Sicherheitsfeatures auch nutzen.
Auf die Schlüsselerzeugung angewandt bedeutet dies: Es gibt zwei Aktivitäten, einmal einen Schlüssel zum Schutz von E-Mail erzeugen und einmal einen zum Schutz der Websurfer - genauer gesagt einen Key für einen SSL-Server. Das dazu passende Interface lässt den User erst wählen, welche dieser Aktivitäten er plant, und fragt anschließend nach Name und E-Mail-Adresse beziehungsweise Webserver-Domäne. Aber selbst das geht noch besser: Ist der Dialog Teil der zu schützenden Anwendung, kann er sich die Fragen nach Namen und Adressen sparen oder wenigstens die bekannten Daten vorab ausfüllen.
Selbst für Stand-alone-Programme gilt keine Ausrede, alle Daten vom User erneut zu verlangen, wenn diese bereits in »/etc/passwd« oder der Konfiguration eines E-Mail-Programms vorliegen. Durch die Vielzahl an Mailclients unter Linux ist Zweiteres eine Herausforderung für die Entwickler, der sich zu stellen durchaus lohnt. Selbst wenn der User die vom Programm vorab ausgefüllten Daten nicht verwendet, ist der Schritt hilfreich: Er gibt ihm eine Vorlage, was das Programm erwartet, statt ihn mit einem leeren Eingabefeld allein zu lassen.
Aktivitätsorientierte Designs sind sorgfältig zu planen. Sie müssen die Aufgabenstellung der meisten Anwender abdecken, ohne Benutzer abzuschrecken oder sie in das Korsett eines festen Ablaufs zu zwängen, den sie gar nicht wollen. Schlecht formulierte Aufgaben zwingen den User gar, den Programmentwurf zu analysieren und zu raten, welcher Knopf zum Ziel führt. Besonders verwirrend geben sich zum Beispiel viele der interaktiven Telefondienste von Fluglinien, Banken und anderen Firmen im Internet.
Braucht ein Wizard mehr als drei oder vier Schritte, um einen Schlüssel zu erzeugen, ist ein Redesign fällig. GPA (GNU Privacy Assistant), der zur selben Programmkategorie gehört wie KGPG, benutzte ursprünglich ein fast identisches Dialogfenster wie KGPG. In jüngeren Versionen löst ein Wizard diesen Dialog ab, einer der Schritte ist in Abbildung 2 zu sehen. Leider beschränkt der Wizard sich darauf, die unverständlichen Eingabefelder des Dialogfensters in viele kleine Stücke zu zersägen. Zu den Sünden des Originals gesellt sich damit Langzeitfolter.
Abbildung 2: Einer von zu vielen Schritten beim Erzeugen eines Schlüssel mit GPA. Es genügt nicht, normale Dialoge durch Wizards zu ersetzen und die alten Eingabefelder neu anzuordnen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
