­čçę­čç¬ Video­čÄ×´ŞĆ Microservice­čľą´ŞĆ Konzept­čôł (2018)­čÉ╗

8. Diskussion und Ausblick

8.1. Retrospektive

Eine Transcoding API bedeutet eigentlich die M├Âglichkeit per Standardmethoden komplexe Einstellungen an diesem Prozess vornehmen zu k├Ânnen. Deswegen hei├čt die in dieser Arbeit beschriebene L├Âsung Webvideopublishing API, oder kurz Webencoder API. Zwar wird vorwiegend von einem Transcoder Gebrauch gemacht, doch verfolgt das Programm prim├Ąr das Ziel, ein Webvideo im allgemeinen, einen adaptiven HLS-Stream im engeren Sinn zu erstellen.

Zun├Ąchst wurde der Versuch unternommen, ein Mockup unter node.js zu erstellen. Die asynchrone Datenverarbeitung in Hinsicht auf jeden einzelnen Programmierbefehl war f├╝r mich jedoch nicht in einem vern├╝nftigen Zeitraum zu beherrschen. Deswegen habe ich die Umgebung nach mehreren Ans├Ątzen zum LEMP-Stack (Linux-(E)nginx-MySQL-PHP) gewechselt.

Vor dem eigentlichen Beginn des produktiven Arbeitsabschnitts habe ich ein Datenbankschema entwickelt, in dem ich noch vorgesehen habe, dass die drei Typen von Tokens jeweils in den Datenbanktabellen Media und Token verteilt sind, da ich einen Zusammenhang zwischen der Art des Tokens und seiner Verwendung in den jeweiligen Objekten (UPLOAD.TOKEN in Token, MEDIA.TOKEN und WATCH.TOKEN in Media) gesehen habe. Im weiteren Arbeitsabschnitt habe ich festgestellt, dass eigentlich die Relation zwischen den Tokens und den Medien im Vordergrund steht und habe deswegen eine Tabelle f├╝r alle Tokens erstellt. Es hat sich ergeben, dass eine relationale Datenbankstruktur im Code viel leichter zu ver├Ąndern ist. Nachdem ich eigentlich schon mit einen weiteren Arbeitsabschnitt abgeschlossen habe, habe ich den MEDIA.TOKEN-Typ in den Code mit Erfolg eingebaut. Des Weiteren wurde die /media/delete.php-Methode erst gegen Ende des praktischen Teils erstellt und es war ebenfalls ├╝berraschend, wie schnell man in einer objektorientierten Programmierweise bestimmte ├änderungen vornehmen kann, damit eine weitere Methode Zugriff auf die Datenbest├Ąnde mit einem minimalen Overhead an Datenbankabfragen bekommt.

Es lag mir vorwiegend daran, eine Webfunktionalit├Ąt zu entwickeln, die universell einsetzbar ist. Was das jedoch in der Praxis bedeutet, wurde mir bewusst, als ich einen Artikel ├╝ber Microservices auf dem nginx-Blog gelesen habe98. Mein Verst├Ąndnis einer universellen Anwendung wurde damit konkretisiert und ich habe mich darauf konzentriert, einen VoD-Encoder mit diesem Paradigma zu beschreiben.

Es ist in der Webentwicklung verlockend jegliche m├Âglichen, einbaubaren Funktionen und Interaktionen einer Webanwendung in Betracht zu ziehen und ihren Nutzen f├╝r das Endprodukt zu projizieren. Doch gewinnt im Internet heutzutage die Spezialisierung, in der eine zu gro├če Allgemeinheit kontraproduktiv ist. In Hinsicht auf die Konzipierung und den Entwurf der Web-API musste ich auf jegliche Services, die nicht im direkten Fokus der geplanten Funktionalit├Ąt liegen, verzichten. Es war jedoch f├╝r meine Kreativit├Ąt f├Ârdernd, sich aus etlichen Webfunktionen einen klar definierten Abschnitt vorzunehmen und ihn gr├╝ndlich durchzuf├╝hren, statt durch einen chaotischen Entwurf das Ziel zu verfehlen ÔÇô ein funktionelles und nutzbares Programm zu schaffen.

Eine Funktionalit├Ąt, die nicht eingespart werden konnte, war die Zugriffskontrolle, da es sich um eine potentiell ├Âffentlich zug├Ąngliche Web API handelt. Deswegen wurden Transaktions-schl├╝ssel, ergo Tokens, f├╝r den Zugriff auf die REST-Endpunkte entwickelt. Da diese Methode jedoch nicht sicher ist, wurde auf der Online-Demo99 zus├Ątzlich ein HTTP Basic Auth– Verfahren via SSL eingerichtet.

Alle weiteren Features, wie eine Galerieansicht, eine komplette Nutzer- und Rechteverwaltung, Statistik bzw. Web Analytics, Social Media wie Foren und Kommentare, wurden aus diesem Grund bewusst aus dem Entwurf entfernt, um

  1. dem Webmaster, der die L├Âsung evtl. integrieren wird, keine typische Portallogik zu seinem bestehenden Kommunikationskonzept zu addieren, sowie
  2. den Vorteil des HLS-Protokolls zu nutzen, da├č es zustandslos und ohne Datenbank-Backend funktionieren kann und somit einem Integrator eine funktionale Barebonel├Âsung zu liefern.

Als Web Analytics Anwendung eignet sich die kostenlose Matomo-Plattform. Sie kann als Google Analytics- Ersatz auf einem organisationseigenen Server funktionieren und damit zur Einhaltung der Europ├Ąischen Datenschutzrichtlinien, sowie anderer Normen zum Datenschutz und zur Datensicherheit100 beitragen. Mit dieser Plattform sollte die Messung von Zuschauerzahlen und den konsumierten Medien und ihrer Dauer kein technisches Problem sein, da die HLS-Streams direkt auf dem Dateisystem liegen und jeder Zugriff vom HTTP-Server verzeichnet wird. Es gibt auch ein entgeltpflichtiges Plugin ÔÇ×Media AnalyticsÔÇť f├╝r die Motomo Web Analytics Plattform101, das h├Âchstwahrscheinlich viele Standardmessmethoden und die resultierenden Metrics bereits fertig zum Einsatz bietet und mit Standard HTTP-Streamingprotokollen zusammenarbeitet.

Eine weiteres Feature, das ich am Anfang der Implementierung nicht ernst genug genommen habe, ist die Analyse des Originalformats der Quelldatei, die ein Benutzer hochl├Ądt. Mit nur etwas Gl├╝ck kann sich herausstellen, dass der Originalvideocodec schon HLS-kompatibel ist und dadurch ein Encoding zumindest der h├Âchsten Qualit├Ątsspur, die sich an den geometrischen Parametern der Originalspur orientiert, nicht notwendig ist. Die Neuenkodierung eines bereits in H.264 vorliegenden Films verursacht unn├Âtige Artefakte, sofern die Originaldatei bereits einen HLS-kompatiblen Codec beinhaltet. Bei einer ausreichenden Analyse der Kompatibilit├Ąt des vorliegenden Codecs nach seinen H.264-Parametern (Aufl├Âsung, Profil, Farbsystem, Encoderlevel) kann der Encoder davon ausgehen, dass der Originalcodec der Quelldatei im zuk├╝nftigen, h├Âchsten HLS-Profil verwendet werden kann und dadurch die h├Âchste Bitrate in ihrer Originalqualit├Ąt HLS-enkapsuliert und abgespielt werden kann. Die Analyse der Originalspur muss daf├╝r gr├╝ndlich getestet werden, um potentielle Falschentscheidungen bei inkompatiblen H.264-Spuren, die durch einen m├Ą├čig programmierten Encoder generiert werden k├Ânnen, auszuschlie├čen. Gleichzeitig impliziert eine schlecht kodierte Originalvideospur Konsequenzen f├╝r das gesamte Ergebnisvideo, den jedes Profil kann nur so korrekt transkodiert werden, wie es die Qualit├Ąt der Originalspur erm├Âglicht.

Deswegen ist es nicht notwendig, in diesem Ablauf jegliche m├Âglichen Defekte zu entdecken, denn ab einer gewissen unteren Qualit├Ątsgrenze kann der Transcoder kein sinnvolles Ergebnis mehr produzieren ÔÇô unabh├Ąngig davon, ob die Originalvideospur beibehalten wird.

8.2. Ausblick

Es w├Ąre von Vorteil, alle in Kapitel 4 Anforderungen besprochenen Unterpunkte zu realisieren. Im Vordergrund steht eine weitere Optimierung der diversen Videoprofile, um ein artefaktfreies TV-Erlebnis zu gew├Ąhrleisten.

Weiterhin ist die Umsetzung eines kompletten Workflows Encoder Ôćĺ CMS w├╝nschenswert, da dadurch das Projekt die n├Âtige Weblogik erh├Ąlt, um als autarkes VideoCMS zu funktionieren. Denkbar w├Ąre die Herstellung von Plugins f├╝r diverse Content Management Systeme, wie WordPress, Buddypress, Foren und Webshops. Dadurch werden die Medienadministratoren in den echten Genuss einer hochqualitativen und automatischen Streaming Website kommen.

Des Weiteren w├Ąren Medienworkflows, wie die automatische Ver├Âffentlichung des Videos in Social Media, f├╝r ein VideoCMS von erheblichem Vorteil. Dies ist auch der Hintergedanke bei der Implementierung des OpenGraph-Protokolls in den Kopfzeilen der Mediendateien.

Ein sicherer Webplayer ist w├╝nschenswert. So ein Playout ist leichter mit der Gesamtl├Âsung zu vertreiben und zu individualisieren, als eine App, die in einem zus├Ątzlichen Framework geschrieben werden muss.

Es ist ebenfalls schwieriger, den Content-Key in einer Webumgebung zu verschachteln, in der theoretisch jeder User und jeder Webclient potentiell Zugriff auf den Schl├╝ssel erlangen k├Ânnten. Dennoch ist es den Aufwand wert, eine webbasierte, sichere L├Âsung zu entwerfen. Im Webclient, der in dieser Arbeit mit der REST API kommuniziert, habe ich vorerst die SSL ├ťbertragung der Logindaten eingebunden.

SSL-Verschl├╝sselung ist ebenfalls eine Bedingung sine qua non f├╝r eine sichere ├ťbertragung des Content-Keys. Der Medienserver besitzt zwei HTTP-Endpunkte, die beide die Legitimit├Ąt des Aufrufs eines verschl├╝sselten Medien-Assets ├╝berpr├╝fen k├Ânnen. Die beiden Endpunkte sind:

  • die master.m3u8 im Hauptverzeichnis des Medien-Assets,
  • die Keyinfo-Datei, die der master.m3u8 beigeh├Ąngt wird.

Beide Dateien k├Ânnen mit einer Weblogik ausgestattet werden, also Scripts verwendet werden, um die Attribute eines HTTP GET- Aufrufs zu verifizieren. Zu den Attributen, die beide Dateien verifizieren k├Ânnen, geh├Âren:

  1. diverse Felder des HTTP-Headers, die u.a. den Ursprung des Aufrufs dokumentieren. Diese k├Ânnen jedoch durch jeden HTTP-Client, der die Manipulation der Header zul├Ąsst, umgangen werden.
  2. CORS-Header (Cross-Origin Resource Sharing), die im Webserver konfiguriert werden, k├Ânnen ebenfalls nicht-legitime Aufrufe von REST-Ressourcen stoppen, doch kann dies ebenfalls durch Manipulation der Header der HTTP-Anfrage umgangen werden.
  3. den WATCH.TOKEN, ├╝ber den der Webserver das Nutzungsrecht per se kontrolliert, das durch den Medienserver und seine Zuschauerpolitik gew├Ąhrt wird (basierend auf Beitr├Ągen, Nutzungsrechten in einer Groupware, usw.). Bei einem legitimen Aufruf des Medien-Assets, also keinem Angriff, der in dieser Beschreibung erschwert werden soll, sollte der WATCH.TOKEN die entscheidende Information ├╝ber die Herausgabe der Keyinfo beinhalten.
  4. ein noch zu erstellendes Public Key System, dass die Originalit├Ąt des Clients (in diesem Fall der Webbrowser) mittels zus├Ątzlicher, individueller und verschl├╝sselter Attribute verifiziert. Zu den Attributen, die die Originalit├Ąt des Clients verifizieren, geh├Âren u.a. die Session-ID, die der Webserver einem eingeloggten User erteilt, sowie die o.g. HTTP-Header, die in der verschl├╝sselten Nachricht zwecks Verifizierung der Anfrage verbaut sein k├Ânnen.

Diese verschl├╝sselten Nachrichten k├Ânnen anschlie├čend per HTTP GET- Aufruf sowohl an die master.m3u8 ├╝bermittelt werden, sowie wahrscheinlich ebenfalls an die virtuelle Keyinfo-Datei, was noch durch Experimente verifiziert werden muss. Eine HTTP GET- Anfrage kann Zusatzinformationen ├╝ber die URI ├╝bermitteln, die ein HLS-Player zustandslos an die master.m3u8 ├╝bermitteln kann, indem die URL, die der Browser aufruft, dynamisch erstellt wird. Wiederum kann die master.m3u8 dieselben oder andere Nachrichten an die Keyinfo-Datei per HTTP GET-Syntax ├╝bermitteln.

Die Keyinfo-Datei sollte eine tempor├Ąre, virtuelle URI sein, die nach dem Konsum durch den Zuschauer-Aufruf entfernt werden muss. Diese virtuelle Datei sollte ebenfalls nur erstellt werden bzw. abrufbar sein, sofern ein WATCH.TOKEN erfolgreich generiert wurde. Die Keyinfo-Datei sollte optimalerweise auf den Konsum durch diesen expliziten WATCH.TOKEN mittels eines allgemein g├╝ltigen Aufrufs warten und die virtuelle URI anschlie├čend entfernt werden, da sie nach einem g├╝ltigen Aufruf theoretisch von keinem anderen Ereignis mehr gebraucht wird.

Der Javascript-Code, den ich in diesem Beispiel vorgesehen habe, kann ebenfalls Mechanismen enthalten, die die f├╝r einen Angreifer relevanten Informationen unkenntlich machen.

Angreifer analysieren als erstes die Kommunikation zwischen ihrem Client und dem angepeilten Webserver, in diesem Fall dem Medienserver. Der Javascript-Code, der im Player verbaut ist, ist das erste Angriffsziel, um seine Funktionsweise nachzuvollziehen und zu lernen, sie zu imitieren. Bei einem erfolgreichen, b├Âsartigen Nachbau der Funktionsweise des Einstiegscodes, kann ein Angreifer, solange er unbemerkt bleibt, weiter in die interne Logik des Servers vorr├╝cken, diese ebenfalls experimentell mittels der imitierten XHR-Aufrufe des Webclients analysieren usw. Schlie├člich kommt der Angreifer, sofern die eingebauten Schutzmechanismen ihn nicht effektiv verzweifeln lassen, zum Ziel, also der Einsicht in die Schl├╝sseldatei eines Medien-Assets im Klartext. Falls der Angreifer die Prozedur, die er dazu entwickelt hat, zu einem Automatismus umbauen kann, ist quasi der gesamte Medienbestand an ihn ausgeliefert.

Der Keyserver kann ebenfalls einen Alarm-Trigger besitzen, der typische Reverse Engineering- Ans├Ątze erkennt und den Angreifer gew├Ąhren l├Ąsst, um ihn mit angeblichen Fortschritten in ein Labyrinth zu locken, in dem ihm widerspr├╝chliche und falsche Informationen, inklusive frei erfundener Content-Keys, als K├Âder pr├Ąsentiert werden, die ihn immer wieder zum selben Ausgangspunkt f├╝hren.

Zum Einen k├Ânnen XHR-Anfragen mittels eines Base64 Kodierers verpackt werden, was die ÔÇÜon-the-flyÔÇś-Erkennung der Informationen in den Header erschwert102.

Des Weiteren kann der gesamte Javascript-Code mit einem sog. Obfuscator unkenntlich gemacht werden. Der unter https://www.obfuscator.io/ beschriebene Quellcode-Kodierer behauptet, gegen existierende Dekodierer z.T. immun zu sein. Es ist diskutabel, ob dieses Verfahren effektiv ist. Es ist jedoch funktional und solche Verfahren erschweren i.d.R. nur einer gewissen Randgruppe, und nicht allen m├Âglichen Teilnehmern, den illegalen Zugriff auf gesch├╝tzte Daten. Deswegen ist es nicht abwegig, den Javascript-Code, der direkt im Player verbaut ist, und der als Einstiegsdatenflow f├╝r den Aufruf der Keyinfo dient, mit einem Obfuscator unkenntlich und damit die Analyse des Codes, der als erster ├╝ber den Zugriff eines Zuschauers auf einen gesch├╝tzten Bereich entscheidet, und ihn an weitere Sicherheitschecks leitet oder sofort abweist, deutlich erschweren.

Weitere Methoden zur sicheren ├ťbertragung eines Content-Keys in einer webbasierten Umgebung m├╝ssen noch erdacht und erprobt werden. Diese Denkans├Ątze k├Ânnen ein Ansto├č sein, sie sind aber bei Weitem nicht komplett und bieten keine fertige L├Âsung.

Eine zus├Ątzliche Komponente, die dem Projekt hinzugef├╝gt werden kann, ist eine Beispiel-App f├╝r die Betriebssysteme Android sowie iOS. So eine App sollte nach den in dieser Arbeit beschriebenen Anforderungskriterien erstellt werden. Weitere Funktionen, wie etwa Web Analytics und Social Media, kann ein versierter Webentwickler selbst hinzuf├╝gen.

Auch die in diesem Teil beschriebenen Techniken zur sicheren ├ťbertragung eines Content-Keys lassen sich auf viele Frameworks zur App-Entwicklung ├╝bertragen oder direkt anwenden. Neben Android Studio und Xcode gibt es zahlreiche andere Frameworks zur mobilen App- und Desktop-Entwicklung, die ebenfalls die erstellten HLS-Streams integrieren k├Ânnen, denn i.d.R. wird die HLS Unterst├╝tzung vom Betriebssystem gestellt und muss vom App Framework lediglich eingebunden werden. Ebenso verh├Ąlt es sich mit der ├ťbermittlung von Informationen ├╝ber einen HTTP GET- Aufruf. Solche Aufrufe werden von jedem HTTP-Client standardm├Ą├čig verarbeitet, was auch der Fall bei einem HLS-Player ist, der von einen HTTP-Client als Transportschicht Gebrauch macht.

Der dieser Arbeit beigef├╝gte und in ihr integrierte Flowplayer war noch zu den Zeiten der Beliebtheit von Flash Streaming Verfahren, wie dem RTMP-Protokoll und Progressive Download, beim Einbinden der Videoinhalte in Webseiten sehr verbreitet, da auch eine kostenlose Version zur Verf├╝gung steht und seit jeher dutzende eingebaute Funktionen f├╝r Web Analytics und Branding beinhaltet waren.

Dennoch ist es mit dem Advent der Media Source Extension und der direkten Interpretation von Streaming Media durch Browser und Betriebssysteme erstrebenswert, auf 3rd Party-Player zu verzichten und eine eigene Playoutl├Âsung zu programmieren. Die Transportschicht von HLS-Streams wird vom hls.js-Plugin verl├Ąsslich bedient. Weiterhin kann der Browser die empfangenen MPEG-TS Dateien direkt darstellen. Deswegen ist der Entwurf eines auf die pers├Ânlichen Bed├╝rfnisse bzw. das Kommunikationskonzept zugeschnittenen Players ein wichtiger Baustein einer integrierten VoD-L├Âsung. Der Player bietet die M├Âglichkeit, die Verwertung der Medien direkt zu kontrollieren, das Zuschauerverhalten zu analysieren und schlie├člich, Player und Anwendungen zu entwerfen, die auf vertikale M├Ąrkte zugeschnitten sind, wie Unterhaltungsmusik, klassische Musik, Sportsendungen, Reiseziele, TV Opern, Reality TV und alle anderen Sparten, die sich in einem integren und logisch verbundenen Angebot zusammenf├╝gen lassen. Dadurch k├Ânnen Webplayer sowie Mobile Player f├╝r nahezu jeden Anwendungsfall entstehen, den man sich erdenken kann. Auf diese Weise kann sowohl ein Musiktheaterfestival wie ein beliebiger Fussballklub seine eigene App mit einem mehr oder minder aufwendigem Apparat an Vermarktungs- und Verwertungsalgorithmen und seiner eigenen und individuellen Videonarration erstellen.

Auf der ├ťberholspur zur Webvideovermarktung gab es wenige Versuche, aus den begangenen Fehlern bei der Markteinf├╝hrung von Breitbandvideo ├╝ber Telefonkabel und andere moderne ├ťbertragungsmedien zu lernen. Das Erkenntnispotenzial liegt nicht nur darin, diese Fehler nicht zu wiederholen. Es kann auch positive Informationen ├╝ber erprobte Methoden liefern, wie ein neues Medium effektiv auf den Markt zu bringen sei. Des Weiteren verbergen sich in den Fallstudien von Unternehmungen, die gescheitert sind, wertvolle Informationen, welche Faktoren zu ihrer Niederlage gef├╝hrt haben k├Ânnten und wie sie bei einer Marktneueinf├╝hrung vermieden werden k├Ânnen. Ein gutes Beispiel ist nicht jede neue Extrafunktionalit├Ąt f├╝r den Stein der Weisen zu halten. France Telecom hat eine ÔÇ×neueÔÇť Dienstleistung ├╝berpr├╝ft, die Webseiten wie auch TV-Programme mit Ger├╝chen erg├Ąnzt hat. Eine ├Ąhnliche Technologie ÔÇ×Smell-o-VisionÔÇť wurde in den 1950ern in den Kinos in den U.S.A. eingef├╝hrt, um die TV-Zuschauer wieder in die Kinos, mit dem Versprechen eines tieferen Erlebnisses, zu locken. Die Zuschauer fanden den Effekt jedoch wenig reizvoll103.

├ähnlich verh├Ąlt es sich mit den Inhalten. Eine McLuhan zugeschriebene ├äu├čerung lautet, dass Menschen dazu tendieren, neue Medien mit alten Medien zu f├╝llen. Die ersten TV-Programme waren visualisierte Radioprogramme. Die ersten Radioprogramme haben dramatische Elemente aus der Gutenberggalaxie entliehen. Es w├╝rde ebenso lange dauern, die Charakteristik eines komplett neuen Mediums nachzuvollziehen, um darauf zugeschnittene Unterhaltungserlebnisse liefern zu k├Ânnen104.