„HTML“ 5: Mit DRM ins Web der Medienkonzerne
Die ganze Sache mit „HTML“ 5 war mir nie geheuer. Schon seit 2008 verfolge ich mit großer Sorge die Entwicklung, die immer weiter weg führt von dem Erfolgsmodell World Wide Web, wie wir es kannten.
Neuester Streich im Dunstkreis von „HTML“ 5 ist die in Arbeit befindliche Spezifikation Encrypted Media Extensions. Sie wird von Google, Microsoft und Co. getrieben und standardisiert einen Weg zum Einbinden von DRM („Digital Restrictions Management“ oder „digitale Rechteminderung“) direkt im Herzen des World Wide Web, in den vom World Wide Web Consortium (W3C) abgesegneten technischen Empfehlungen.
Die Auswirkungen wären beträchtlich. Natürlich gibt es zum einen die direkten Folgen, die jeder spüren wird. Derzeit ist das Web eine offene Plattform. Notwendige Zugangsbeschränkungen zum Beispiel zum eigenen GMX-Account lassen sich über Mechanismen wie Benutzername/Passwort realisieren. Das wars dann aber auch schon. Was ich einmal in meinem Browser angezeigt bekomme, kann ich
- so oft sehen, wie ich möchte,
- speichern,
- verschicken,
- von anderen Programmen als dem Browser verarbeiten lassen
und so weiter. Wenn ein sogenannter „Rechteinhaber“ das verhindern will, muß er sich auf eine andere Infrastruktur verlassen und zum Beispiel auf kommerzielle Browser-Plugins ausweichen. Das ist mit Aufwand verbunden und daher eher die Ausnahme.
Wenn ein DRM-Mechanismus im Web standardisiert wird, liegt die Latte niedriger. Es wird einfacher sein, Inhalte zu beschränken - und es wird daher häufiger vorkommen. Ein Video darf nur 1x angesehen werden, fürs zweite Mal muß man erneut zahlen. Ein Katzenfoto darf man ansehen, aber nicht an Freunde verschicken. Den wissenschaftlichen Artikel kann man online lesen, aber nicht abspeichern. Musik darf man streamen, aber nicht aufs Handy überspielen. Alles, was bisher nur aus den Walled Gardens von Apple & Co. bekannt war, wird dann Teil des heute noch freien World Wide Web.
Es gibt aber noch ein zweites, tieferliegendes Problem: Wenn DRM-Mechanismen so leicht von einer Webseite angefordert werden können, dann müssen sie auch halbwegs verläßlich in den Browsern implementiert werden. Ein Browser, der die Funktion nicht bereitstellt, würde vom einfachen Benutzer nicht als moralisch überlegen, sondern als nicht funktionstüchtig wahrgenommen. (Ähnlich wie Handy-Browser ohne Flash-Unterstützung.) Bleibt die Frage: Wie lösen quelloffene, freie Browser das Problem? Eine Implementierung im offenen Teil des Codes ist problematisch, sie könnte ausgehebelt und von den Anbietern als nicht ausreichend sicher eingestuft werden. Bleibt eine Implementierung als proprietäres Plugin, ähnlich wie Flash … mit all ihren Nachteilen: Ein proprietäres Plugin wird nicht auf allen Betriebssystemen und nicht für alle Versionen zur Verfügung stehen, darf aus rechtlichen Gründen nicht einfach so weitergegeben werden, kann bei technischen Problemen nicht schnell repariert werden usw. usw.
Bürgerrechtsbewegungen wie die EFF oder Defective By Design kämpfen einen ersten Kampf, in dem es darum geht, öffentliches Bewußtsein für dieses Problem zu schaffen. In einer von mir unterzeichneten Petition forderten sie das W3C auf, die Arbeit an diesem Projekt einzustellen. Natürlich lassen sich Microsoft und Google nicht von ein paar tausend Unterstützungserklärungen abhalten. Aber darum gings aus meiner Sicht auch nicht. Es geht jetzt zunächst darum, das Thema überhaupt bekannt zu machen und es zu ermöglichen, daß Internet-User sich eine Meinung bilden.
W3C:
