Offene Standards

Minimalgebot für Datenformate - offener Standard sein reicht nicht

Ohne ein Werk-stück ist Werkzeug nutzlos. Was sind also die Werkstücke für unsere Computer? Daten, Informationen, Wissen, Meinungen, Kunstwerke - kurz Inhalt. Er wird erstellt, verarbeitet und übertragen. Meist direkt elektronisch. Immer mehr Menschen haben einen Rechner mit Internetanschluss zur Verfügung und evolutionieren damit ihre Zusammenarbeit.

Inhalt wandert also von einer Nutzerin zum Nutzer und zurück. Dabei muss er eine Form annehmen: Das Datenformat. Es legt fest, wie Inhalt plus Verpackung zu handhaben sind, was darin stehen darf und wie das in einer Datei oder über eine Internetverbindung dann konkret aussieht. Wer mitmachen möchte, braucht eine Software, welche das Datenformat versteht. Sonst wäre der Inhalt für die eigene Anwendung wie eine unbekannte Fremdsprache. Wenn ein Datenformat keine Speicherung von Fotos zuläßt, dann kann ich mit diesem eben keine Fotos speichern. Die Wahl des Datenformats ist deshalb entscheidend dafür, wie lange ich an meinen Inhalt herankomme und was ich mit ihm machen kann.

Der einzelne Nutzer mag die Wirkung seiner Entscheidung bei jedem Abspeichern kaum bemerken. Wenn sich eine IT-Abteilung oder die öffentliche Hand für ein Datenformat entscheiden, dann wirft das Wellen. Die damit verbundene Wahl der Softwarelösung hat Auswirkungen auf viele Jahre und Jahrzehnte hinaus. Je mehr wertvolle Schriftstücke, Tonaufnahmen oder Bilder elektronisch abgelegt werden, desto wertvoller ist es, darauf noch zugreifen zu können. Bewusst oder indirekt wird so auch die Entwicklung der Datenformate finanziert. Viele Softwarehersteller versuchen absichtlich Nutzer dazu zu verleiten, ein von ihnen beherrschtes Datenformat zu verwenden, zum Beispiel für die Konstruktionspläne von Fahrzeugen, Gebäuden oder Maschinen. Der Hersteller der dazugehörigen CAD-Anwendung erhält dann praktisch diese Daten eines Unternehmens als Faustpfand. Aus seiner Sicht ist das eine starke Verhandlungsposition für die Kosten der nächsten Version. Manchmal begeben sich auch ganze Staaten in eine solche Situation.

Deshalb kann ein gutes Datenformat nur ein Offener Standard sein. Diese Grundvoraussetzung ist jedoch nicht ausreichend. Das Datenformat muss zudem ein Problem angemessen lösen, also fachlich und technisch gut passen. Dazu lassen sich eine Vielzahl von Eigenschaften betrachten. Das Essay von Bert Bos über die Design-Grundsätze der Organisation W3C - welche die Formate des World-Wide-Web erarbeitet - nennt unter anderem Effizienz, Wartbarkeit, Zugänglichkeit, Erweiterbarkeit, Erlernbarkeit, Einfachheit und Langlebigkeit.

Zwei zentrale Fragen dabei sind:

• Wie gut löst das Datenformat das Problem? Und:
• Ist es das einfachst mögliche oder gibt es ein einfacheres Datenformat?

Die erste Frage erläutert sich von selbst: Wer einen Text speichern, übertragen und durchsuchen möchte, der wird ungern ein Format für pixelbasierte Bilder wählen - obwohl bei eingescannten Papieren oder Faksimiles im ersten Schritt unvermeidlich.

Spannender ist die zweite Frage: Ist das Format so kompliziert wie nötig und so einfach wie möglich? Es ist schwer, ein Datenformat zu entwerfen oder auszuwählen, welches diesem Minimalgebot entspricht.

Da ist einmal die schlechte Wirkung des "Design by Committee", also der Beteiligung vieler Entscheider an einer technischen Ausarbeitung. Standards werden gern mit der Beteiligung Vieler entwickelt und die Entscheidung für eine Softwarelösung in einer Organisation - besonders in einer öffentlichen - wird ebenfalls in oft zahlreich besetzen Gremien gefällt. Da können schnell "viele Köche den Brei verderben" und mehr hinzufügen, als wirklich notwendig wäre. Das W3C ist sich laut Bos dieser Problematik immerhin bewusst, viele andere Gruppen sind es nicht.

Hinzu kommt, dass Software-Lösungen oft mit einer Abhakliste bewertet werden. Zuerst dürfen sich alle Betroffenen etwas wünschen. Diese Wünsche sind oft konkrete Lösungsideen und werden zu der Liste für die Beschaffung verdichtet. Das Software-Produkt gewinnt mit den meisten Häkchen, was meist ein Datenformat bedeutet, welches selten bis gar nicht gebrauchte Funktionen enthält. Besser wäre es die Wünsche problemorientiert zu erfassen und mehr Punkte für Lösungen zu verteilen, welche mit mehreren, einfachen, sich ergänzenden Datenformaten arbeiten.

Softwarehersteller kennen Ihre Käufer. Je mehr Häkchen bedient werden können, desto wertvoller scheint eine Software, da sie - flüchtig betrachtet - mit sehr vielen Wünschen zurecht käme; außer dem Wunsch nach schlichter Eleganz. So sehen dann Software und Datenformat auch aus: Aufgebläht mit vielen Funktionen, damit sich viele Lösungsideen direkt wiederfinden lassen. Ein weiterer Vorteil für den Hersteller: Der Konkurrenz wird es erschwert, das Format genauso gut zu verarbeiten oder eine überlegene Teillösung anzubieten. Der Kunde muss ganz kaufen, oder gar nicht. Warum noch ein weiteres Datenformat, wenn das eine schon alles kann?

Jede zusätzliche Funktion oder Regelung macht die Beschreibung eines Datenformats exponentiell komplizierter. Die Nachteile sind immens. Die Entwickler von einer Software, welche mit einem Datenformat umgehen soll, müssen die Beschreibung komplett durchdringen. Das umfasst den ganzen Text und dann alle Möglichkeiten, welche sich durch die Kombination der enthaltenden Elemente ergeben. Weniger lesen und verstehen zu müssen, bedeutet eine einfachere und sicherere Umsetzung in der Software. Das führt zu mehr Software, welche das Datenformat auf hohem Niveau spricht. Wettbewerb, Auswahl und damit mehr Nutzen für Anwender folgen nach.

Je fintenreicher ein Datenformat ist, desto größer die Chance, dass es selten benötigte Vorkehrungen gibt. Das Format und dessen Umsetzungen in Software gleichen dann einem großen verwinkeltem Haus, bei dem manches stark belebt ist, aber einige Räume oder Nischen praktisch nie betreten werden. Klar, so ein Haus lässt sich schwerer absichern. Einbrecher könnten einfach ein in Vergessenheit geratenes Kellerfenster aufdrücken, oder beim offiziellen Gang durch das Gebäude unentdeckt etwas in einem dunklen Treppenabsatz verstecken.

Experten betrachten Komplexität als das größte Problem für Software-Sicherheit. Deshalb stehen viele von ihnen Standards skeptisch bis feindselig gegenüber.1

Um die Risiken greifbarer zu machen, betrachten wir wie ein Rechner Schriftzeichen darstellt: Da gibt es den weit verbreiteten Standard ISO/IEC 8859-15 (Latin-9). Mehr als 20, meist westeuropäische, Sprachen könnten damit verarbeitet werden. Für ein Zeichen gibt es 255 verschiedene Möglichkeiten. Ein neuerer Standard namens Unicode (ISO 10646) soll es ermöglichen alle Sprachen zu Kodieren. Dafür braucht es mehr, nämlich mehr als eine Millionen Möglichkeiten. Weiterhin kann ich gleiche Zeichen noch auf mehreren unterschiedlichen Wegen darstellen, beispielsweise in den Kodierungsvarianten UTF-8 und UCS-2. Einerseits ist Unicode ein Segen: Einmal richtig programmiert, ist eine Anwendung auf hunderte von Sprachen grundsätzlich vorbereitet. Andererseits kann eine Programmiererin bei einer Eingabe nicht mehr im Kopf ausrechnen, was bei allen Zeichen im Quelltext geschehen könnte. Bei den 256 Fällen von Latin-9 ging das; bei Unicode fehlt diese Übersicht. Ein schlauer Angreifer mag dann Kombinationen finden, an welche der Entwickler nicht gedacht hat. Das kommt regelmäßig vor. Hier zwei einfache Beispiele: 1. Der homographische Angriff täuscht Nutzer durch ähnlich aussehende Internetadressen. Das Kyrillische aus Unicode-Schriften eignet sich dafür. 2. Den Entwicklern eines bekannten Webservers wurden vor vielen Jahren die Möglichkeiten von Unicode in URLs zum Verhängnis.

Es ist keine Überraschung, dass es mehr Anwendungen gibt, welche mit Latin-9 "korrekt" umgehen können als mit Unicode. Das Problem ist für jedes "dicker" spezifizierte Datenformat ähnlich: Es gibt Anwendungen welche die seltenen Funktionen nicht verstehen. Schon weil es so viele Funktionen sind, dass sich das nicht mehr testen lässt. Beworben wird dann die Fähigkeit, Datenformat X zu verstehen, aber ob das in der Praxis mit der Software klappt, ist fraglich.

Manche Datenformate bauen dieses Problem sogar direkt ein: Es gibt von ihnen verschiedene Ausbaustufen. Wer hier feststellen möchte, ob Anwendungen kompatibel sind, der muss genau angeben, um welches Datenformat es sich handelt. Beispielsweise gibt es vom Open Document Format (ODF) mit 1.0, 1.1 und 1.2 schon drei Varianten. Vermutlich mit zunehmender Komplexität. Es gibt sicher viele Fälle, wo das Nutzen der Möglichkeiten von Version 1.0 völlig ausreichend wäre. Die Voreinstellung dürfte trotzdem das Speichern in der neuesten, von der Software unterstützten, Version sein. Für PDF existiert das Problem noch verschärfter. Manche Versionen oder Teile von PDFs entsprechen nicht mal den Anforderungen eines offenen Standards.

Wer Computer verstehen möchte, dem wird erklärt, dass es zwei verschiedene Dinge gibt: Daten und Programme. Während die Daten nur verarbeitet werden, enthalten die Programme Befehle für den Computer. Der Unterschied wird deutlich anhand eines Zettels auf dem steht: Spring von der Brücke! Diesen Zettel und den Satz kann ich problemlos lesen, aufschreiben und weitergeben - also verarbeiten. Sollte ich ihn als Befehl auffassen und ausführen, dann falle ich leicht auf die Nase. Das ist bei Rechnern genauso. Dateiformate wie ODF, Doc und PDF können neben Daten auch Anweisungen für automatische Bearbeitung ("Makros") oder interaktive Elemente (Javascript) enthalten. Das macht jede Datei zu einer potentiellen Anwendung mit Befehlen für meinen Computer. Klar, dass Angreifer das ausnutzen, wie bei den Makro-Viren.

Die meisten Texte, welche übertragen werden, brauchen nur einen kleinen Bruchteil dessen, was gängige Datenformate ihnen an Formatierungs-, Auszeichnungs- und Layout-möglichkeiten anbieten. Eine schlichte Datei aus Latin-9 Zeichen kann seit Jahrzehnten auf jeden Rechner mit einem einfachen Texteditor und allen Textverarbeitungen bearbeitet werden. Mit steigenden Anforderungen könnte ein kleiner Teil von HTML 2 schon ausreichen, für Überschriften, Aufzählungen und Internetverweise. Oder eine schlichte, textbasierte Auszeichnungsprache, wie sie in Wikis Verwendung findet. Die Wikipedias und Weblogs dieser Welt belegen, das sich sehr viel Inhalt mit solch einfachen Mittel ausdrücken läßt.

Alle - außer den Herstellern der proprietären Software - haben ein Interesse daran, dass verschiedene Software-Produkte miteinander im Wettbewerb stehen. Und dass die Produkte sicher gegen Angreifer und gut interoperabel sind. Das Minimalgebot für Datenformate fördert all das. Es besteht darin, alles wegzulassen, was nicht unbedingt notwendig ist. Ziel ist ein schlichtes und elegantes Design. Schön ist ein Baukasten, bei dem sich aus wenigen verschiedenen Elementen leicht unendliche viele Werke schaffen lassen.

Obwohl es gute Gründe geben kann, ein Datenformat zu nehmen, welches mehrere Anforderungen bündelt, sollten wir uns öfter fragen: "Geht das einfacher?"

Fußnoten

1. "Complexity is the main enemy of security", Ferguson, Niels, and Schneier, Bruce - Practical Cryptography, Wiley, 2003, ISBN 0-471-22357-3. p146 "9.4.1 Simplicity", pp365- "23 Standards" https://www.schneier.com/books/practical-cryptography [↲]