Kopierschutz
Digital-Rights-Management
Mit der Entwicklung eines Digital-Rights-Management- Systems für HTML5 hat das W3C in den letzten Wochen für viel Aufmerksamkeit gesorgt.
Ich muss gestehen, dass mich die Diskussionen um das W3C und dessen Arbeit an einem, so wie sie es nennen, "content protection"-System bisher nicht wirklich interessiert haben. Warum sollten Netflix, Microsoft oder Google ihre Hollywood-Blockbuster nicht über DRM-geschützte HTML5-Videos anbieten dürfen? Alles ist besser als Flash oder Microsofts Silverlight.
Eigentlich betrifft mich die Diskussion auch nicht wirklich. Netflix funktioniert in Deutschland bisher sowieso nicht, und wenn ich mir mal ein Video ausleihe, dann über iTunes, oder ich kaufe mir gleich die DVD.
Vor ein paar Tagen bin ich dann aber auf einen sehr interessanten Artikel von Danny O'Brien gestoßen. Er weist darauf hin, dass ein DRM-System für Video und Audio wahrscheinlich nur der Anfang ist und eine ganze Reihe an weiteren Anwendungsfällen folgen kann. Vor etwa fünf Jahren gab es schon eine ähnliche Diskussion über ein DRM-System im Zusammenhang mit Webfonts. Auch aktuell gründen sich Gruppen, die eine Erweiterung der Spezifikation auf Bilder, HTML und sogar JavaScript fordern.
Das könnte so weit gehen, dass Sie schon bald nicht mehr jedes Bild speichern oder sogar Texte nicht mehr frei kopieren können. Ich habe mir damals, alleine durch das Herumstöbern in den Sourcecodes verschiedener Webseiten, HTML beigebracht, was so zukünftig durch ein DRM-System verhindert werden könnte. Somit wären wir alle davon betroffen.
In der Tat lässt die vom W3C veröff entlichte "Encrypted Media Extensions"-Spezifikation (kurz EME) viel Spielraum offen. Das Dokument definiert nämlich kein DRM-System, sondern lediglich eine JavaScript API, über die ein solches System Daten mit dem Browser austauschen kann. Sie könnten die EME auch sehr gut mit dem object- oder embed-Element vergleichen.
Ein standardisierter Weg, um nicht standardisierte Systeme anzubinden. Die Spezifikation ist derzeit zwar nur für video- und audio-Elemente defi niert, ließe sich aber ohne große Probleme auf jedes andere HTML-Element anwenden. Tim Berners-Lee, der Erfi nder des World Wide Web und Vorsitzender des W3C, erwähnt in einem Artikel, dass vor allem Open Source Browser von dieser Spezifikation profitieren.
EME definiert eine reine Schnittstelle zwischen DRM-Server und Browser. Es sind also keine Schlüssel oder Algorithmen notwendig, die eine Veröffentlichung des Quellcodes verhindern würden.
Content Decryption Modules
Ironischerweise kommt aber gerade aus dem Lager eines Open Source Browsers die größte Kritik. Brendan Eich, der CTO von Mozilla, wirft dem W3C vor, mit der EME API viele Bereiche undefiniert zu lassen. Die Spezifikation definiere nur die Kommunikation zwischen dem Browser und den sogenannten Content Decryption Modules (kurz CDM), nicht aber wie diese auszusehen haben.
Das könnte dazu führen, dass die Implementierungen von Browser zu Browser variieren und CDMs für jeden Hersteller individuell angepasst werden müssen. Die Spezifikation lässt sogar bewusst proprietäre Video Codecs oder andere browserspezifische Implementierungen zu. Eich schreibt weiter, dass Systeme wie Microsofts Silverlight aktuell sogar sinnvoller sind als die EME-Spezifikation. Sie müssen so nicht für jeden Filmanbieter ein extra CDM installieren - und Silverlights DRM-System arbeitet vollkommen autark, ohne das Zutun des Browsers.
DRM und Open Web?
Es stellt sich generell die Frage: Lassen sich derzeitige Digital-Rights-Management-Lösungen überhaupt mit HTML5 und einem offenen Web vereinbaren? Ian Hickson, einer der Editoren von HTML5, hat auf Google+ ein paar interessante Punkte zum Thema DRM im Allgemeinen aufgeführt. Hickson stellt die These auf, dass DRM nicht in erster Linie als Kopierschutz fungiert.
Vielmehr wird es als ein Mittel der Filmanbieter eingesetzt, um Konsumenten ein Abspielgerät aufzuzwingen. Legt man es wirklich darauf an, einen DRM-geschützten Film zu kopieren, findet man sicherlich die nötigen Mittel und Wege. Immerhin wird das gekaufte Video ja unverschlüsselt auf dem eigenen Fernseher oder Computer abgespielt.
Was Sie jedoch nicht frei wählen können, ist das Abspielgerät. Über eine X-Box lassen sich nur Filme aus dem "X-Box Video"-Repertoire abspielen, über Apple ausgeliehene Filme oder Serien nur über iTunes und Hörbücher von Audible funktionieren nur auf einem iPod.
Auf das Web übertragen bedeutet das, dass Microsoft und Google ihre Video-Plattformen dazu nutzen können, ihren eigenen Browser zu promoten. Google hat gerade vor ein paar Wochen angekündigt, einen "Paid Music Service" über Youtube anzubieten, mit EME könnten sie diesen Dienst ausschließlich Chrome-Usern zur Verfügung stellen.
EME bietet damit einen generellen Vorteil für die Browser der großen Firmen wie Apple, Google oder Microsoft, die jeweils über diverse Mediendienste verfügen. Mozilla oder Opera werden es dagegen schwer haben und müssen darauf hoffen, dass Medienunternehmen ohne eigenen Browser auch ihre Produkte unterstützen.
Fazit
Laut Tim Berners-Lee ist ein DRM-System für HTML5 (Audio und Video) unausweichlich, deshalb sollte es offen diskutiert und über das W3C standardisiert werden.
Prinzipiell hat Berners-Lee damit natürlich nicht unrecht. Ohne Webstandards wäre ein World Wide Web wie in seiner jetzigen Form nicht möglich. Eine Spezifikation, die proprietäre Formate fördert und die freie Browserauswahl einschränkt, hat in meinen Augen aber nicht den Begriff Webstandard verdient und sollte auf keinen Fall vom W3C vorangetrieben werden. HTML5-Audio und -Video wurden entwickelt, um die Medienwiedergabe im Browser zu vereinheitlichen. Browser sollen dadurch in der Lage sein, Filme und Musik direkt und ohne die lästige Installation von Plug-ins abzuspielen. Die "Encrypted Media Extensions" bricht mit allen diesen Grundsätzen und schafft Verhältnisse wie vor der Einführung von HTML5.
Entweder das W3C arbeitet an einer vollständigen DRM-Lösung, die jedem Browser gleichermaßen das Abspielen von geschützten Inhalten ermöglicht, oder es sollte sich besser ganz von der Entwicklung zurückziehen.
Es gibt übrigens auch eine Petition gegen DRM in HTML5, organisiert von der Free Software Foundation.
