Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

231 lines
14 KiB

<?xml version="1.0" encoding="UTF-8" ?>
<html>
<head>
<meta name="author-name-1" content="Bernhard Reiter" />
<meta name="author-link-1" content="http://blogs.fsfe.org/bernhard" />
<meta name="publication-date" content="2012-03-23" />
<title>Minimalgebot für Datenformate - Offene Standards - FSFE</title>
<meta name="cc-license" content="Neben der Standardlizenz der Webseite steht dieser Artikel unter der Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) https://creativecommons.org/licenses/by-sa/3.0/" />
</head>
<body id="article">
<p id="category">
<a href="/projects/os/os.html">Offene Standards</a>
</p>
<h1>Minimalgebot für Datenformate - offener Standard sein reicht nicht</h1>
<p>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.</p>
<p>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.</p>
<p>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, 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.</p>
<p>Deshalb kann ein gutes Datenformat nur ein <a
href="/projects/os/def.html">Offener Standard</a> 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 <a
href="http://jendryschik.de/wsdev/trans/designguide/">Essay von Bert
Bos</a> ü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.</p>
<p>Zwei zentrale Fragen dabei sind:<ul>
<li>Wie gut löst das Datenformat das Problem? Und:</li>
<li>Ist es das einfachst mögliche oder gibt es ein einfacheres Datenformat?</li></ul>
</p>
<p>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.</p>
<p>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.</p>
<p>Da ist einmal die schlechte Wirkung des <a
href="http://sourcemaking.com/antipatterns/design-by-committee">"Design
by Committee"</a>, also der <a
href="http://webstandard.kulando.de/post/2010/07/21/design-by-committee-gestaltung-durch-viele-entscheider">Beteiligung
vieler Entscheider</a> 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 <a
href="http://www.w3.org/People/Bos/DesignGuide/committee.html">laut
Bos</a> dieser Problematik immerhin bewusst, viele andere Gruppen sind es
nicht.</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>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.</p>
<p>Experten betrachten Komplexität als das größte Problem für
Software-Sicherheit. Deshalb stehen viele von ihnen Standards skeptisch bis
feindselig gegenüber.<a class="fn" href="#fn">1</a> </p>
<p>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. <a
href="http://de.wikipedia.org/wiki/Homographischer_Angriff">Der
homographische Angriff</a> 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 <a
href="https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m05/m05102.html">die
Möglichkeiten von Unicode in URLs zum Verhängnis</a>.</p>
<p>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.</p>
<p>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 <a
href="http://pdfreaders.org/os.de.html">Versionen oder Teile von PDFs</a>
entsprechen nicht mal den Anforderungen eines offenen Standards.</p>
<p>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 auffü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 <a
href="https://www.bsi-fuer-buerger.de/ContentBSIFB/GefahrenImNetz/Schadprogramme/Viren/viren.html">Makro-Viren</a>. </p>
<p>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 <a
href="http://de.wikipedia.org/wiki/Creole_(Markup)">schlichte,
textbasierte Auszeichnungsprache</a>, wie sie in Wikis Verwendung finden.
Die Wikipedias und Weblogs dieser Welt belegen, das sich sehr viel
Inhalt mit solch einfachen Mittel ausdrücken läßt.</p>
<p>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 <a
href="http://magplot.de/TasteForMakers">ein schlichtes und elegantes
Design</a>. Schön ist ein Baukasten, bei dem sich aus wenigen
verschiedenen Elementen leicht unendliche viele Werke schaffen lassen.</p>
<p>Obwohl es gute Gründe geben kann, ein Datenformat zu nehmen, welches mehre
Anforderungen bündelt, sollten wir uns öfter fragen: "Geht das
einfacher?"</p>
<h2 id="fn">Fußnoten</h2>
<ol>
<li>"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"
<a href="http://www.macfergus.com/pc">http://www.macfergus.com/pc</a></li>
</ol>
</body>
<timestamp>$Date$ $Author$</timestamp>
<tags>
<tag>open-standards</tag>
</tags>
</html>