DRM und das offene Web

,

In der HTML Arbeitsgruppe der W3C tobt seit bald drei Wochen ein Streit über die Einführung von DRM in HTML5. Auslöser war ein Entwurf von Google, Microsoft und Netflix, doch der Grund für die Auseinandersetzung liegt tiefer und geht auf die gegensätzlichen Ansichten zurück von Anhängern der Free Software Bewegung und Content-Produzenten, die den Zugang zu ihren Werken kontrollieren wollen. Es ist eine politische Diskussion, die einmal mehr die Frage nach den Wertvorstellungen und Ansichten im Web entscheiden muss.

Aber zuerst ein paar Infos über mich, da das hier mein erster Artikel ist. wink
Ich bin Oli, 22, studiere Medieninformatik und Gestaltung in der Uni Bielefeld und führe die Webseite css3-html5.de, die durch ausführliche Videotutorials über HTML5 bekannt geworden ist. Alexandra hat mich gefragt, ob ich nicht Lust hätte, im deutschsprachigen Opera Blog über HTML5 zu schreiben, und natürlich hatte ich Lust! bigsmile
Leider ist das aber schon fast ein Jahr her, ohne dass ich etwas gepostet habe. Deswegen wollte ich nun endlich mal die Möglichkeit nutzen und mache das nun mit diesem Artikel. Ich hoffe, er gefällt euch. smile

Alle wollen HTML5
Ihr habt ja bestimmt alle spätestens dieses Jahr von HTML5 gehört. Die neuen Webstandards, die als „HTML5“ zusammengefasst werden, bieten viele neue Möglichkeiten, die vorher nur mittels Plug-Ins realisierbar waren. Seitdem HTML5 in aller Munde ist, gewinnen die offenen Webstandards mehr und mehr an Bedeutung. Es gibt inzwischen sogar ganze Betriebssysteme, die im Grunde Browser sind. Und sogar in Windows 8 werden die Programme in HTML5 geschrieben. All diese Plattformen können HTML5, manche von ihnen sogar nur HTML5, weder Flash noch Silverlight oder ähnliches.
Kein Wunder also, dass Streaming-Anbieter wie Netflix, hulu, Voddler, Vudu, etc. (falls ihr diese Anbieter nicht kennt: Dort kann man legal Kinofilme, TV-Serien und andere hochwertige Videos gucken, nur leider sind die meisten von ihnen in Deutschland nicht verfügbar) von Flash wegkommen wollen und ihre Services lieber auf Grundlage von offenen Webstandards anbieten wollen. Und da bei HTML5 dank des video-Tags nun auch Videos ohne Plug-Ins eingebunden werden können, ist das technisch sogar möglich!

Aber die Kontrolle fehlt
Die Probleme liegen woanders: Inhalte einer Webseite, also Texte, Bilder, Videos, Skripte etc., sind für alle Welt zugänglich. Probier es aus: Gehe in Opera auf Darstellung > Entwicklerwerkzeuge (Windows: Seite > Entwicklerwerkzeuge), dort kannst du dir den Quelltext der Seite ansehen oder dir mit Opera Dragonfly einen Überblick über alle Ressourcen und Eigenschaften der Webseite verschaffen. Wenn ein Video über das HTML5 Video-Element eingebunden wäre, könntest du also auch den Pfad zur Videodatei herausfinden und das Video speichern, wenn du es wolltest.

Das verschreckt die Produzenten der Videos. Denn wie gesagt geht es hier um Blockbuster und andere Filme, die in ihrer Produktion teilweise hunderte Millionen Dollar gekostet haben. Die Vorstellung, Nutzer von Netflix könnten diese Filme problemlos speichern und dann unerlaubt in Umlauf bringen, ist ein Horror für die Filmstudios.
Denn sie wollen die Kosten der Filme selbstverständlich wieder einspielen und da wäre es in ihren Augen ein Unding, wenn die Filmdateien ungeschützt im Internet angeboten werden würden. Sie möchten den Zugang der Filme kontrollieren: Filme ansehen, ja, Filme speichern also Zugang zu dessen Daten, nein!

Um diesem Wunsch gerecht zu werden, wurde DRM geschaffen, Digital Rights Management. Mit DRM können die Daten von u.a. Musik- und Filmdateien verschlüsselt werden, sodass der Nutzer erstmal keinen Zugang zu ihnen hat. In den Playern, um die Musik- oder Filmdateien abzuspielen, sind dementsprechend Dechiffrierer eingebaut, die die Daten wieder entschlüsseln, um sie abzuspielen.

Die Nachfrage ist hoch
Und genau dieses DRM fehlt den Anbietern in HTML5. Vor einem Jahr hat die W3C, die Normungsorganisation im Web, ein „Web and TV Workshop“ veranstaltet, bei dem herauskam, dass das Fehlen von DRM eines der Hauptgründe ist, weshalb Premium Video Anbieter ihr Angebot nicht auf die Web Plattform bringen. Es ist eines der Hauptgründe, weshalb sie für Videoplayback auf Plug-In-basierte Lösungen wie Flash und Silverlight zurückgreifen, da diese DRM anbieten. Aber da Plug-Ins wie Flash nicht auf allen Plattformen zur Verfügung stehen, müssen sie für die verschiedenen Plattformen verschiedene Lösungen finden.

Um dieses Problem zu beheben, haben Netflix, Google und Microsoft zusammen eine mögliche Lösung ausgearbeitet, die sie der HTML Arbeitsgruppe am 21. Februar vorgestellt haben.

Viele Content-Anbieter und Anwendungsentwickler haben gesagt, sie können nicht das audio- und video-Element nutzen, weil in HTML solider Inhalteschutz fehlt. Ohne diese Funktionalität können sie ihre Apps nicht auf die Webplattform bewegen.


Viele Reaktionen haben das Vorhaben unterstützt und nochmal belegt, dass die Notwendigkeit und das starke Bedürfnis nach DRM in offenen Webstandards da ist. Hier ein kleiner Überblick:

Dieser Vorschlag ist ein guter erster Schritt, ein echtes Problem von Inhalteanbietern und Geräteherstellern anzusprechen [...] Ich denke, die Arbeit hieran sollte fortgeführt werden, damit HTML dieses Problem angeht.
Bob Lund, CableLabs


Wir unterstützen das Bestreben nachdrücklich und danken Google, Microsoft und Netflix für ihre Arbeit, um das voranzubringen. Wir denken, die HTML Arbeitsgruppe sollte sich um weitergehende Arbeit hieran bemühen.
Wayne Carr, Intel


In meiner Stellung als Repräsentant für Cox Communications möchte ich mitteilen, dass Cox unterstützt, dass die W3C eine vernünftige Lösung beschreibt, um die Wiedergabe von DRM- und/oder kopiergeschützten Medien mittels HTML5 zu ermöglichen.
Glenn Adams, Cox Communications


Wir haben das [genannte Problem] auch oft gehört.
Das sieht nach einem brauchbaren Vorschlag für mich aus.
Eric Carlson, Apple


Wir hören dieselben Rückmeldungen.
Chris Pearce, Mozilla


Comcast unterstützt diese Initiative ausdrücklich. Wir wollen weiterhin hochwertige Inhalte über Webbrowser anbieten, aber wir würden lieber das HTML5 video-Element nutzen, statt object-Element Plug-ins, wie es heute der Fall ist.
Mark Vickers, Comcast


(Alle Übersetzungen von mir)

Jedoch die Ethik!
Alle wollen loslegen, worauf also noch warten?
Es gibt da noch ein anderes Problem: Die ganze Idee von DRM und Kopierschutz widerspricht prinzipiell der Idee eines offenen Webs.

Ich finde, dieser Vorschlag ist unethisch und wir sollten ihn nicht weiter verfolgen.
Ian Hickson



Denn Fakt ist: Es gibt sehr viele legitime Kritikpunkte an DRM. Es entzieht Menschen prinzipbedingt die vollständige Kontrolle über Daten und Programme ihres eigenen Computers. Da man abspielende Medien theoretisch mit einem Screencast-Programm vom Bildschirm "abfilmen" kann und somit sich mit Leichtigkeit eine entschlüsselte Kopie davon erstellen kann, enthält manche DRM-Software Mechanismen, die im Hintergrund kontrollieren, ob der Nutzer solch ein Screencast-Programm ausführt und verhindert dann das Abspielen. DRM-Software greift also tief in das System des Nutzers ein und schränkt ihn in den Freiheiten seines Handelns ein. Trotz allem wird DRM-Software regelmäßig geknackt.
Außerdem kann es wegen DRM zu Problemen beim Abspielen kommen, zum Nachteil der Nutzer. Selbst Apple, das eines der ersten DRM-Programme geschaffen hat, sprach sich vor fünf fünf Jahren gegen DRM aus. Die Gründe:
  • DRM ist und wird nie perfekt sein. Es wird immer Menschen geben, die es knacken. Somit ist DRM im Grunde wirkungslos.
  • Deswegen werden nur die Menschen, die Nachteile von DRM zu spüren bekommen, die sich die Inhalte legal, also mit DRM-Schutz ansehen. Diejenigen, die sich die Inhalte illegal besorgen, haben keine Nachteile.
  • Darum ermutigt DRM-Schutz die Nutzer eher dazu, sich die Inhalte ohne DRM-Schutz zu besorgen, also illegal.

Damals ging es um Musik und nicht Filme. Letztendlich ist die Musikindustrie darauf eingegangen, sodass Apple inzwischen keine DRM-geschützte Musik mehr verkauft. Dasselbe erhoffen manche in der HTML Arbeitsgruppe für die Filmindustrie:

[...] Die Unterhaltungsindustrien bewegen sich im Allgemeinen sogar weg von DRM - Bilder waren schon immer DRM-frei, die Musikindustrie ist inzwischen größtenteils DRM-frei, und Buchverkäufer [...] nutzen im Allgemeinen DRM-freie Formate wie ePub. Filme sind noch nicht so lange wie die anderen Medienarten wirklich tauschbar im Internet, deswegen kommt die Filmindustrie etwas später zu der Erkenntnis, dass Sharing okay ist und ihnen nicht wirklich schadet, aber sie werden das in naher Zukunft verstehen, so wie jede andere Industrie auch.
Tab Atkins, Google


Außerdem gibt es rechtliche Sorgen:

Insbesondere einem Browser wie Mozilla [Firefox] ist es *rechtlich untersagt* so etwas wie DRM zu implementieren, da sie all ihren Code offenlegen müssen, inklusive den Verschlüsselungscode, der die Geheimnisse enthält, die man für die Verschlüsselung braucht.
Tab Atkins, Google


Auch, wenn der Einwand technisch wohl nicht ganz richtig ist, so bringt er doch einen weiteren Punkt auf den Tisch: Die Verpflichtung gegenüber den vier grundsätzlichen Freiheiten und den Standpunkten der Free Software Bewegung, mit denen DRM ebenfalls absolut inkompatibel ist.

Es ist unethisch für uns, Technologien zu machen und zu nutzen, die vorsätzlich unzugänglich sind, ob das nun ist, um taube Nutzer davon abzuhalten, zu wissen was in einer Filmproduktion von Hamlet gesagt wird, oder einen Englischprofessor am Kritisieren von Teilen ebendieses Films zu hindern.
Ian Hickson



Jedoch die Realität!
Es gibt also Widerstand gegen die Einführung von DRM in HTML5, der durchaus nachvollziehbar ist. Fakt ist aber auch: Die Wirklichkeit wird sich durch eine Nicht-Einführung von DRM in HTML5 nicht ändern. So oder so werden die Filme mit DRM-Schutz angeboten. Wenn es nicht mit HTML5 umgesetzt ist, werden einfach weiterhin Plug-Ins bemüht, wie Flash oder Silverlight.
Eine Einführung wäre sogesehen bloß pragmatisch und würde sogar die Webplattform stärken, weil es dann einen Grund weniger gäbe für die Nutzung von Plug-Ins. Sich diesem Pragmatismus zu widersetzen, kann also nur ideologische Gründe haben. Es geht darum, ob man solch ein System wie DRM im offenen Web überhaupt haben will.
Die verschiedenen Moral- und Wertvorstellungen stoßen aktuell in der Mailingliste zusammen. Seit fast drei Wochen schon.
Neben vielen weiteren Fragen ist hauptsächlich die zu klären, welche Kontrolle wichtiger ist: Die des Nutzers über seinen eigenen Computer oder die der Filmstudios über die Verbreitung ihrer Inhalte. Beide Seiten haben nachvollziehbare Argumente, sehr viel mehr Argumente als ich in diesem Artikel behandeln konnte.

Wie die Diskussion ausgehen wird, ist noch nicht abzusehen. Vor einer Woche hat ein Engagierter versucht, eine Zusammenfassung der Diskussion zu schreiben. Seitdem ist sie Grundlage der Diskussion (es gab bereits 77 Reaktionen darauf und eine Zusammenfassung der Gegenvorschläge, auf die es wiederum 14 Reaktionen gab, ganz abgesehen von den 137 restlichen Antworten nur allein innerhalb der letzten Woche).
Es gab wohl bereits bei der Schaffung des video-Elements eine Diskussion über die Einführung von DRM und wie wir heute wissen, hat es das damals offensichtlich nicht in die Spezifikation geschafft.
Was meint ihr zu dem ganzen Dilemma? Ich würde gerne ein abschließendes Fazit schreiben, aber mir fällt nichts ein, außer dass diese Fragen schwierig zu klären sind.

(Bildquelle: Mike Thomson)

Opera 11.61

Comments

schemestrom Saturday, March 10, 2012 12:35:21 AM

DRM? Die können mich mal*. Als ob das irgendwen, der es darauf anlegt Filme zu kopieren, davon abhalten könnte.
Von mir aus können sie auf Flash setzen. Das Blöde ist, dass sie damit auf Dauer nicht durchkommen werden. Für mobile Plattformen wird es kein Flash mehr geben, Silverlight war da eh nie drin. Der Internet Explorer 10 unterstützt in der Metro-Version ebenfalls keine Plugins mehr. Für Linux steht Flash auch vor dem Aus, Windows wird hoffentlich zeitnah folgen. Verrecken wird die Filmindustrie nicht dran, aber wünschen würde ich es ihnen.
Die Zukunft ist offen, ganz egal ob das der Content-Mafia oder Firmen wie Microsoft gefällt. Hoffentlich setzen sich die Kritiker durch.

* Ich musste mir unter Linux die Bibliothek zum Entschlüsseln von verschlüsselten DVDs (und das sind so ziemlich alle) selbst kompilieren, weil es die nicht in den Repositories meines Paketmanagers gab. Warum? Weil ich einfach nur eine DVD, die ich GEKAUFT habe, ansehen wollte und die Distributoren sie aus Angst vor Klagen (siehe https://de.wikipedia.org/wiki/DeCSS#Rechtliche_Situation) nicht verfügbar gemacht haben. Einsteiger-Distributionen wie Mint haben die zwar standardmäßig installiert, aber wahrscheinlich ist das nur noch keinem der Klage-Haie aufgefallen. *würg*
Nicht zu vergessen dieser ganze DRM-Wahnsinn bei Computerspielen, wo du als ehrlicher Käufer die Arschkarte hast. Das muss ich denke ich nicht weiter vertiefen, wird wohl jeder hier kennen oder zumindest schon von gehört haben.

timmi Saturday, March 10, 2012 10:23:40 AM

Hab noch nie verstanden wieso sich nur PC Benutzer darüber so aufregen. Netflix und ähnliches gibts doch schon länger auf diesen kleinen Boxen die an den TV angeschlossen werden, da regt sich auch keiner auf, dass DRM drauf ist.
Genauso bei Kabel und Satelliten TV, HD+ und CI+ gabs bissel am Anfang leichten Protest, aber wird angenommen.

Wenn Anbieter wie Netflix und ähnliche durch DRM billige Monatspreise anbieten können, wenn die dann DRM sind, wieso nicht*.
Das Argument mit der Vollständigen Kontrolle der Daten und Programme auf dem eigenen PC ist Blödsinn, seit wann hab ich denn über Programme Kontrolle? Ich hoffe doch das Programme das machen was ich will, ob die nebenbei noch was anderes machen, war noch nie unter meiner Kontrolle. Genauso bei Dateien, ich hab nur bei selbsterstellten Dateien die komplette Kontrolle darüber, alle anderen Daten hab ich meistens nur Nutzungsrechte erworben, das ich an Quellcode oder an die Dateien direkt dran komme, ist nirgends gegeben.

Von daher meine Meinung: Solange es funktioniert, können die ruhig DRM in HTML5 einbauen, solange es nur eine Ergänzung/Erweiterung ist und nichts ersetzt.

* Solange dies natürlich auch funktioniert und nicht nur bei der Hälfte der Benutzer.

corppneq Sunday, March 11, 2012 2:34:41 PM

@Bloli
„Eine Einführung wäre sogesehen bloß pragmatisch und würde sogar die Webplattform stärken, weil es dann einen Grund weniger gäbe für die Nutzung von Plug-Ins. Sich diesem Pragmatismus zu widersetzen, kann also nur ideologische Gründe haben.“

Ideologische Gründe??? Du kannst in einer offenen Plattform, wie HTML, keinen FUNKTIONIERENDEN Kopierschutz umsetzen. Der Grund ist nicht ideologischer Natur sondern technischer.

Das schreibt übrings auch Chris Pearce von Mozilla (http://lists.w3.org/Archives/Public/public-html/2012Feb/0303.html) den du leider verkürzt darstellst.

QuHno Monday, March 12, 2012 8:26:18 AM

Originally posted by corppneq:

Du kannst in einer offenen Plattform, wie HTML, keinen FUNKTIONIERENDEN Kopierschutz umsetzen. Der Grund ist nicht ideologischer Natur sondern technischer.

Wer will das denn?

Der Kopierschutz bezieht sich auf die Video- oder Audiodateien und die offene Plattform HTML könnte ganz locker verschlüsselte Videos einbinden, wenn die Entwickler der HTML Plattform beim Video Tag den Mechanismus zur Schlüsselaushandlung nicht vergessen hätten.

Theoretisch wäre eine Darstellung sogar über einen Web Handler möglich.

Das einzige was HTML dabei macht ist, dem Browser zu sagen, wo das Material liegt und wie es im Einzelfall entschlüsselt werden kann, das ist im Prinzip nichts anderes, als ein Link zu einer verschlüsselten ZIP Datei, bei der dann automatisch verhandelt würde, ob der Nutzer den Schlüssel bekommt, oder nicht.

Klar kann einer der Nutzer das Ding entschlüsseln und dann ins Netz stellen - allerdings ist dann auch sofort klar, dass er das entgegen der Nutzungsbedingungen (die übrigens ein Vertrag sind) getan hat - selbst bei kostenlos angebotenen Inhalten.

Bei schöpferischen Werken ist es noch schlimmer - es wird zusätzlich das Urheberrecht des Erstellers für nichtig erklärt.

Alle Leute reden immer über den Nutzer und free und so weiter - ich kann jedoch auch Leute verstehen, die ihre selbst unter Blut, Schweiß und Tränen erstellten Inhalte eben nur auf ihrer eigenen Seite anbieten wollen und eben nicht wollen, dass die überall angeboten werden, am besten noch ohne Nennung der Quelle.

Nicht vergessen:
Schöpferische Leistung ist nicht durch Masse ersetzbar - eine Million unkreative Leute können keinen Picasso ersetzen - und ein Picasso benötigte auch Geld, damit er sich etwas zu beißen kaufen konnte wink

corppneq Monday, March 12, 2012 8:17:20 PM

@QuHno

Originally posted by QuHno:

Der Kopierschutz bezieht sich auf die Video- oder Audiodateien und die offene Plattform HTML könnte ganz locker verschlüsselte Videos einbinden, wenn die Entwickler der HTML Plattform beim Video Tag den Mechanismus zur Schlüsselaushandlung nicht vergessen hätten.


Der Mechanismus wurde mit Sicherheit nicht vergessen sondern bewusst weggelassen!

Originally posted by QuHno:

Das einzige was HTML dabei macht ist, dem Browser zu sagen, wo das Material liegt und wie es im Einzelfall entschlüsselt werden kann, das ist im Prinzip nichts anderes, als ein Link zu einer verschlüsselten ZIP Datei, bei der dann automatisch verhandelt würde, ob der Nutzer den Schlüssel bekommt, oder nicht.


Du meinst wie man z.B. anhand eines vom Server gesetzten Cookies prüft ob ein Nutzer eingeloggt ist und auf Inhalte zugreifen darf?

Denn das funktioniert auch heute schon mit HTML! Das von dir vorgeschlagene Schutzlevel besteht schon! Dafür braucht man keine zusätzlichen Implementierungen!

Was in einer offen Plattform wie HTML, welche in Browsern implementiert wird, nicht funktioniert ist ein Kopierschutz wie AACS (http://de.wikipedia.org/wiki/Advanced_Access_Content_System) wo alle Komponenten untereinander verschlüsselt kommunizieren. Damit ein solchen System funktioniert müssen alle Komponenten BlackBoxen sein um vom Nutzer nicht modifiziert zu werden können.

Eine offene erlaubt jedoch Änderungen durch den Nutzer! Folglich kann man auf ihr keinen FUNKTIONIERENDEN Kopierschutz realisieren. Das ist auch der Punkt der von Chris Pearce von Mozilla (http://lists.w3.org/Archives/Public/public-html/2012Feb/0303.html) angesprochen wird.
Es wird kein bisschen zusätzlicher Schutz hinzugefügt. Das ist alles unnötige Augenwischerei und sollte nicht in einen Standard gelangen.

Originally posted by QuHno:

Klar kann einer der Nutzer das Ding entschlüsseln und dann ins Netz stellen - allerdings ist dann auch sofort klar, dass er das entgegen der Nutzungsbedingungen (die übrigens ein Vertrag sind) getan hat - selbst bei kostenlos angebotenen Inhalten.


Und da es verboten ist wird das ja keiner machen!!! rolleyes Wenn das so ist braucht man keine zusätzliche Schutzimplementierung. Wenn das nicht so ist braucht man auch keine zusätzliche Schutzimplementierung da eine solche bei einer OFFENEN Plattform keinen Schutz bieten kann der über das auch jetzt schon in HTML bestehende Level hinausgeht.

Originally posted by QuHno:

Alle Leute reden immer über den Nutzer und free und so weiter - ich kann jedoch auch Leute verstehen, die ihre selbst unter Blut, Schweiß und Tränen erstellten Inhalte eben nur auf ihrer eigenen Seite anbieten wollen und eben nicht wollen, dass die überall angeboten werden, am besten noch ohne Nennung der Quelle.


Ich sehe und verstehe genau wie der oben erwähnte Chris Pearce was diese Leute wollen. Dies kann für sie jedoch in einer offenen Plattform nicht umgesetzt werden. Dafür braucht man eine geschlossenes System wie z.B. ein Plugin.

timmi Monday, March 12, 2012 8:39:35 PM

DRM besteht also deiner Meinung nach vor allem aus security by obscurity? Ich kenn mich nicht direkt damit aus, aber nachdem was ich bei Wiki kurz überflogen habe, besteht DRM aus einem normalen Verschlüsselungsverfahren mit Schlüssel das es zuhauf schon gibt und immer noch sicher sind obwohl deren präzise Vorgehensweise bekannt ist.

SSL ist auch bekannt und bietet eine sichere Übertragung, auch schlüsselbasiert. Wer hält davon ab solch ein Schlüsselaustauschverfahren wie in SSL auch in DRM zu implementieren? Wüsste dann nicht was es für Probleme gäbe.

corppneq Monday, March 12, 2012 9:24:27 PM

@timmi
Was DRM ist hängt von der jeweiligen Umsetzung ab!

Originally posted by timmi:

besteht DRM aus einem normalen Verschlüsselungsverfahren mit Schlüssel das es zuhauf schon gibt und immer noch sicher sind obwohl deren präzise Vorgehensweise bekannt ist.


Das Verschlüsselungsverfahren ist sicher und wird auch gar nicht angegriffen. Damit der Nutzer den Inhalt aber anzeigen kann braucht er einen Schlüssel. Hier bekommt man aber das Problem mit der offenen Plattform.

In einem geschlossenen System kriegen nur Clients welche ich nicht manipulieren kann einen Client-Schlüssel. Bei einem offenen & freien System wie HTML lässt sich dies nicht realisieren. Ich könnte einen Schlüssel den Firefox (als Client-Schlüssel) bekommt (nehmen wir mal an das Mozilla im Browser den Inhalt nur zum Anzeigen anbietet und nicht zum Download) nutzen, denn Firefox ist ja Open Source. Oder ich könnte einfach Firefox umprogrammieren damit Firefox die eigentlich zum anzeigen entschlüsselten Mediendaten unverschlüsselt speichert.

Bei den Schlüssel des Inhalts besteht das gleiche Problem. Sobald ich das Anzeigeprogramm modifizieren kann hängt die Wirksamkeit des Kopierschutzes von meinen Wohlwollen ab.

Ich könnte also in einer offenen & freien Plattform nur ein System realisieren welches die gleiche Sicherheit wie bisher bietet. Der Nutzer loggt sich ein und bekommt per Cookie eine Session. Wenn der Nutzer auf einen Inhalt zugreifen will, schaue ich welcher Nutzer das ist (dafür ist der Cookie den ich gesetzt habe) und erlaube oder verbiete die Auslieferung des Inhalts an den Browser. Ob der Nutzer dann kopiert hängt davon ab ob er das will. Die Vorgeschlagene Lösung würde den gleichen Schutz anbieten (ich liefere die Datei an den Browser aus und dann schaue ich ob dieser den Schlüssel bekommt, was im Prinzip nur unnötiger Traffic ist da ich auch vor Auslieferung prüfen könnte) daher sehe ich keinen Grund/Sinn darin eine Funktionalität zu kopieren die es schon gibt.

Eine teilweise wirksame Lösung wäre eine geschlossene und nicht freie Plattform. Ich möchte nicht das HTML und das Web generell zu einer solchen wird. Eine Lösung als Plugin würde ich bevorzugen.

Mit AACS (http://de.wikipedia.org/wiki/Advanced_Access_Content_System) das bei Blu-ray verwendet wird gibt es schon ein solch sicheres System. In dem AACS System kommunizieren nur verifizierte Geräte verschlüsselt untereinander. Du kannst aber, im Unterschied zu Blue-ray Playern, unmöglich jedes Internet und HTML fähige Gerät verifizieren und locken (locken=Modifikationen technisch unterbinden) lassen (was auch dem Gedanken von HTML als freier und offener Plattform widerspricht).
Ein solches System kann trotz allem nur teilweise wirksam sein, da in der Umsetzung immer noch Fehler gemacht werden können (das ist bei Blu-ray passiert). Trotz möglicher Fehler ist ein solches System (wie z.B AACS bei Blu-ray) immer noch relativ schwierig zu umgehen und damit recht effektiv. Aus oben genannten Gründen kann so etwas nicht in einem offenen System gemacht werden.

Eine Lösung als Plugin (wie auch Flash, welches ein nicht mobil freundliches Layout hat und nicht sehr prozessorfreundlich ist, eine bietet) würde ein geschlossenes System in einem offenen darstellen und damit den, so denke ich, den praktisch maximal möglichen Schutz bieten.

Originally posted by timmi:

SSL ist auch bekannt und bietet eine sichere Übertragung, auch schlüsselbasiert. Wer hält davon ab solch ein Schlüsselaustauschverfahren wie in SSL auch in DRM zu implementieren?


Der Punkt ist das SSL eine sichere Übertragung bietet. Das würde diese Lösung (welche wahrscheinlich ähnlich bewährte Kryptographie wie SSL verwenden würde) auch bieten. Nur nutzt es nichts wenn niemand die Inhalte auf dem Übertragungsweg abgreifen kann. Sie müssen auf meinem Rechner zum abspielen entschlüsselt werden, womit wir wieder bei den schon beschriebenen Problemen eines offenen Systems währen.

QuHno Tuesday, March 13, 2012 6:16:22 AM

Wo ist das Problem?

Es gibt mindestens 2 Browser, die nicht offen sind, sondern lediglich offene Standards unterstützen. Auf beiden Browsern wäre selbst eine gesicherte Kommunikation mit eventuell vorhandenen TPM Chips der entsprechend zugelassenen Geräte möglich, ohne dass sich irgendwer darüber beschweren dürfte. Auch wäre eine Verifizierung der Geräte möglich denn es gibt auch einen HDMI Standard, der genau das regelt. Wenn es Chrome und Firefox aufrund ihrer Politik nicht können oder wollen (Chrome selbst ist nicht open source, lediglich Chromium ist es. Google kann und darf zusätzlich einbauen was sie wollen.) sind sie halt nicht geeignet und können die Inhalte nicht darstellen. Das ist genau wie mit anderen Videoplayern, einige können DRM und andere nicht, wo ist das Problem dabei? Der Nutzer muss sich dann halt einen Browser nehmen, der das unterstützt.

Der HTML Standard (nicht die Plattform, denn HTML ist keine) schreibt nirgends vor, dass die Darstellungssoftware (Browser) nicht auch etwas anderes zusätzlich können darf, er schreibt nicht einmal vor, dass es überhaupt ein Browser sein muss.

Niemand hindert die Browser Hersteller daran, statt z.B. GStreamer einen DRM fähigen Client einzubauen oder die Daten direkt an das System zur Darstellung in einem geeigneten Player zu übergeben. Selbst das VIDEO oder AUDIO Tag muss nur verstanden werden können, der Browser muss aber die Videos nicht nativ abspielen können, das wird nirgends im HTML Standard gefordert. Im Standard steht nichts darüber, wodurch es dargestellt werden soll, lediglich die Transport und Kontrollmechanismen werden geregelt sowie die Positionierung des Blocks bzw die Art der Darstellung - wenn die an einen externen Player übergeben werden, der das ganze in einer gesicherten Sandbox innerhalb der Webseite rendert, ist das kein Problem für den HTML Standard, denn der hat damit gar nichts zu tun. Die Aufbereitung der Video oder Audio Daten ist nicht Bestandteil des HTML Standards und das aus gutem Grund.

All das ändert auch nichts an der Offenheit von HTML, das darf auch weiterhin von jedem verwendet werden, um diese Inhalte anzubieten (nicht zu verwechseln mit verbreiten, das geschieht ein paar Ebenen tiefer im OSI-ISO Modell, es wird lediglich durch die in HTML angebotenen Mechanismen angestoßen). Selbst wenn die TPM Chips angesprochen und benutzt werden ändert das nichts daran.

Ein Video oder sonstiges Dokument, welche per DRM geschützt ist (viele Firmen nutzen DRM, um ihre normalen Dokumente zu schützen), ist sowieso kein Bestandteil des offenen Webs, denn es existiert offiziell nur im geschlossenen Ökosystem Anbieter - Kunde.

Fazit: Keine Schnittstelle dafür anzubieten ist 100% ideologisch bestimmt. Ein einziger zusätzlicher Parameter, der den Browser klar macht, dass er den Kram anders behandeln muss, wäre aus Sicht des HTML Standards völlig ausreichend.

PS:

Originally posted by corppneq:

Und da es verboten ist wird das ja keiner machen!!! rolleyes

Tut mir Leid, aber der Satz ist Blödsinn. In Deine Wohnung einzubrechen ist trotz unzureichender Sicherungsmaßnahmen auch verboten (ich halte jede Wette, dass der Zugang in weniger als 10s möglich ist, also ist die Wohnung ungesichert. Das Schloss an der Tür ist lediglich ein Symbol, dass Du es nicht wünscht.) und Du kannst hoffen, dass sich alle daran halten. Leute mit mangelndem Rechtsbewusstsein und mangelndem Respekt vor fremdem Eigentum hat es schon immer gegeben und wenn sie erwischt wurden, gab es schon immer die passende Bestrafung bzw. Pflicht zur Entschädigung.

corppneq Tuesday, March 13, 2012 7:35:53 PM

Originally posted by QuHno:

unterstützen. Auf beiden Browsern wäre selbst eine gesicherte Kommunikation mit eventuell vorhandenen TPM Chips der entsprechend zugelassenen Geräte möglich,


Dem stimme ich zu. Dies wäre wahrscheinlich sogar mit den freien Browsern möglich.

Originally posted by QuHno:

Fazit: Keine Schnittstelle dafür anzubieten ist 100% ideologisch bestimmt. Ein einziger zusätzlicher Parameter, der den Browser klar macht, dass er den Kram anders behandeln muss, wäre aus Sicht des HTML Standards völlig ausreichend.


Nein! Meine Aussage, das es nicht möglich ist einen Kopierschutz in das offene und freie HTML zu integrieren, ist richtig. Gegen eine Einführung im Browser sprechen zuerst technische Gründe nicht ideologische.

Wenn du in den in den unofficial Draft von Encrypted Media Extensions v0.1 (http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html) schauen würdest, sähest du das eine Einführung eines DRM-Systems in HTML nicht direkt geplant ist. Der Browser soll lernen Daten durchzureichen. Der Artikel stellt jedoch die Behauptung auf das ein DRM-System in HTML integriert werden soll!
Ich finde es ist ein wichtiger Unterschied ob man versucht ein DRM-System in Browsern wie Firefox zu implementieren (was nicht funktionieren kann) oder diesem beibringt Daten durchzureichen (an z.B ein TPM, was möglich ist). Auf dem Blog eines Browser-Entwicklers erwarte ich die Fähigkeit dies unterscheiden zu können.

Originally posted by QuHno:

Tut mir Leid, aber der Satz [...]


Wie schön das du mich verkürzt zitierst und nicht auf mein Argument eingehst.

QuHno Tuesday, March 13, 2012 9:00:22 PM

Die ganze Diskussion ist sowieso Blödsinn. Es gibt Leute, die DRM haben wollen und sie werden es bekommen, gleichgültig wie. Es gibt Leute, die kein DRM haben wollen und sie werden immer weinen Weg finden, es zu umgehen.

Was aber endgültiger Blödsinn ist, ist das "in HTML einbauen", denn einfach durchreichen bzw. von der Anwendung, innerhalb der auch der HTML Parser enthalten ist abarbeiten zu lassen, wenn sie es kann, reicht völlig aus (was übrigens auch so im Draft Proposal vorgeschlagen wird). Lediglich ein blöder Parameter (Vorschlag dort: onneedkey) muss in HTML hinzugefügt werden, der dem entsprechenden User Agent sagt: "Achtung, hier kommt DRM geschütztes Material dieser und jener Art" und selbst das könnte auf andere Art direkt in HTTP erfolgen, HTML ist technisch gesehen dafür überhaupt nicht notwendig. Auch nach Befolgung der dort vorgeschlagenen Maßnahmen wird da nichts in HTML integriert und auch nicht verlangt, dass irgendeine Form von DRM in HTML integriert wird, lediglich die Schnittstelle für die Übergabe.

Ansonsten: Das hier ist nicht das Blog des Browser-Entwicklers, sondern das Blog der deutschsprachigen Community, welches auf den Servern und mit der Software von Opera ASA, welches bei weitem nicht nur eine Browser-Entwickler Firma ist, betrieben wird. So viel Zeit muss sein.

Originally posted by corppneq:

Wie schön das du mich verkürzt zitierst und nicht auf mein Argument eingehst.

Ich habe den Satz, auf den ich mich bezog, nicht verkürzt zitiert. Beim Rest habe ich mich entschieden, die Argumente einfach so stehen zu lassen. Hätte ich sie zitieren und ihnen ebenfalls widersprechen sollen? Wen es interessiert, der kann bequem hoch scrollen und die vollständige Quelle lesen, das ist doch wohl nicht zu viel verlangt, oder?

Sangesgott Friday, March 23, 2012 1:37:15 AM

So wie ich die ganze Sache verstanden habe, ist DRM eh eine Totgeburt, wenn es einfach nur eine Art Kopierschutz sein soll. Denn am Ende der Kette muss das Video oder das Lied ja doch für den User unverschlüsselt wiedergegeben werden und kann somit im Zweifelsfall per Screen- oder Audiograbber einfach mitgeschnitten werden.
Sollte DRM jedoch als Zugangskontrolle für bestimmte Inhalte verwendet werden, kann man das auch einfacher haben, nämlich mit der guten alten Registrierung. Und die Variante, dass der User einen entsprechenden Key irgendwo auf seinem Rechner abgelegt haben muss, hat schon bei den Musikdownloads nicht gut funktioniert (Rechner musste neu installiert werden und prompt waren diverse gekaufte Alben wertloser Datenschrott, da die Keys weg waren)

Letztendlich bleiben die Bemühungen der Contentindustrie aber ein Pfuschen an den Symptomen, da sie krampfhaft versuchen an einem Vermarktungsmodell aus dem analogen Zeitalter festzuhalten. Es gibt nun einmal die Möglichkeit, eine Datei mal eben per Mausklick zu kopieren, das kann man nicht mehr rückgängig machen. Und deshalb lautet die Frage auch nicht ob DRM gut oder schlecht ist bzw. ob DRM im Web kommen wird. Die Frage lautet: Wie sieht ein zukünftiges, funktionierendes Geschäftsmodell im Web bzw. als digitaler Vertrieb aus?
(Übrigens: Die legalen, also bezahlten Musikdownloads schossen erst in die Höhe, als die großen Plattformen wie iTunes oder Amazon anfingen auf DRM zu verzichten...)

schemestrom Friday, March 23, 2012 11:32:41 AM

Originally posted by Sangesgott:

So wie ich die ganze Sache verstanden habe, ist DRM eh eine Totgeburt, wenn es einfach nur eine Art Kopierschutz sein soll. Denn am Ende der Kette muss das Video oder das Lied ja doch für den User unverschlüsselt wiedergegeben werden und kann somit im Zweifelsfall per Screen- oder Audiograbber einfach mitgeschnitten werden.


Viel besser. Ich würde im Zweifelsfall sogar darauf wetten, dass spätestens eine Woche, nachdem der erste Browser so ein System implementiert, ein Plugin für diesen Browser erscheint, mit dem man die Dateien unverschlüsselt auf der Festplatte ablegen kann.

Unregistered user Tuesday, April 10, 2012 10:52:01 PM

Anonym writes: DRM ist auch von daher schlecht, da es zu Problemen kommen kann, wenn ein Unternehmen pleite geht o.ä. Vor einigen Jahren hat ein großer Anbieter sein Angebot für DRM-geschützte Klingeltöne abgeschalten(da sich der Betrieb der Server nicht mehr rechnete). Dies schränkt auch "erworbene" Inhalte so sehr ein, dass sie immer nur für die Laufzeit der DRM-Server gültig sind, weshalb ich DRM in keinem Maße unterstützen kann. Es war ein unheimlich großer Aufwand, die erworbenen Dateien damals alle mit Freeware-Tools zu konvertieren um sie weiterhin nutzen zu können! Von daher ist DRM(für Videos) alles andere als die Zukunft und es sollte meiner Meinung nach genauso eine Totgeburt bleiben, wie die DRM geschützten Bilder, die uns ein Forscher mit einem Ministerium vor einiger Zeit präsentierte. btw Gut, dass jemand die Nutzer überhaupt über die Debatte aufklärt!

Unregistered user Wednesday, April 11, 2012 7:04:52 AM

X-COPY PRO writes: wir haben uns bereits zu zeiten des amiga sehr viel mit kopierschutz beschäftigt und ein programm herausgebracht, mit dem man praktisch von jeder diskette, egal welchen formats, eine sicherheitskopie ertellen konnte - das war x-copy mit cyclone. die damalige computergemeinde kennt es noch, es war damals weltmarktführer. warum haben wir das damals gemacht und was hat das mit der heutigen situation zu tun? unser programm hat einen kopierschutz NICHT entfernt sondern mitkopiert, dies war notwendig, denn der ehrliche käufer hatte sonst keine möglichkeit seine legal erlaubte sicherheitskopie anzufertigen. als alternative zu unserem programm gab es nur die "geknackten" versionen, bei denen der kopierschutz entfernt war. die konnte dann sowieso jeder kopieren. die situation mit DRM steht vor einem ähnlichen dilemma und -danke apple!!!- immerhin ein teil der industrie hat es erkannt. kopierschütze in jeder form sind vollkommen sinnlos und bringen leute nur dazu illegale dinge zu tun und diese zu bagatelisieren. sie sind vollkommen kontraproduktiv. es wird immer geknachte versionen geben. ich erinnere mich noch daran, dass eine australische gruppe seinerzeit volle drei monate daran gearbeitet hat um "dragons lair" komplett umzuschreiben, nur um den kopierschutz zu entfernen..... andererseits ist es ein unding und man kann erkennen wie weit die menschen heutzutage schon ihre persönlichkeitsrechte und privatsphäre verloren bzw aufgegeben haben, dass ÜBERHAUPT in erwägung gezogen wird, so tief in den privaten rechner eines einzelnen einzudringen, wie es DRM macht. ich kann dazu nur sagen: RAMA - RAUS AUS MEINEM ARBEITSRECHNER !!! und das gerede von den realitäten und der abwägung verharmlost nur die tatsache, dass wir - "der grosse dumme haufen" - immer weiter rumgeschubst und weichgeklopft werden sollen, damit man uns leichter kontrollieren kann. dieses rumgeschubse kann auch nach hinten los gehen und dann haben sich DR komplett erledigt. wir haben unser programm seinerzeit OHNE kopierschutz ausgeliefert und konnten trotzdem gut davon leben, sogar sehr gut. genau das können die firmen auch, die so laut jammern und unbedingt DRM haben wollen. es geht hier nicht um existenzen, sondern um die reine gier, das letzte aus einem produkt herauszupressen. dieses ganze hochgerechne, was die industrie angeblich dadurch verliert, unterschlägt bewusst, dass sich die nutzer von illegalen kopien die originale meist niemals leisten könnten. all diese zahlen sind nur augenwischerei und geplapper. es gibt andere möglichkeiten sicherzustellen, dass die rechteinhaber nicht leer ausgehen und die benutzer nicht kriminalisiert und ausspioniert werdem. hier eine für alle tragbare lösung auszuarbeiten ist konstruktiver und auch zukunftsträchtiger als unwirksame kontrollmechanismen zu entwerfen und diese auch noch zu implementieren... just my 5 cent as a veteran...

Write a comment

New comments have been disabled for this post.