 Gut, dann herzlich willkommen zu meinem Vortrag WebRTC Security. Was ist WebRTC und wieso ist es sicher? Erst mal kurz zu meiner Person, ich bin Stefan Tamm. Ich bin zusammen mit Kilian hier vorne, Innovable UG, kleine Firma hier in Dresden. Wir haben eine Website und wir haben vor ein paar Jahren, 2013, haben wir zusammen mit anderen Leuten ein Palaver angefangen. Das ist eine WebRTC Videokonferenz-Plattform. Und WebRTC ist ja auch jetzt hier unser Thema. Genau, wie der Vortrag ablaufen wird. Als erstes erstmal den ersten Teil der Frage, was ist WebRTC? Danach schauen wir uns das nochmal genauer an, wie WebRTC funktioniert aus der Anwendungssicht. Als nächstes schauen wir uns dann diesen Verbindungsaufbau an. Das ist ein bisschen das Komplexeste an WebRTC. Und als letztes schauen wir uns noch mal ein bisschen an, wie dann die Sicherheit und die Protokolle auf der Netzwerkebene on the wire dann funktionieren. Das wird so ungefähr unser Ablauf hier sein. Als erstes zu der Frage, was ist WebRTC? WebRTC steht für Web Real-Time Communication. Ich erkläre WebRTC immer am liebsten, indem ich diese einzelnen Teile erkläre, die dem Javascript-Entwickler jetzt neu zur Hand gegeben werden, die er jetzt neu nutzen kann. Das erste, was wir da haben, ist dieses GetUserMedia. GetUserMedia ist eine Funktion, mit der man vom Nutzer Medien bekommen kann, seine Kamera, sein Mikrofon. Teilweise kann man auch seinen kompletten Desktop übertragen. Und dafür ist jetzt diese neue Funktion GetUserMedia da. Und wenn man diese Streams dann hat, diese Nutzerdaten, dann möchte man natürlich auch was mit denen machen. Am liebsten möchte man sie weitergeben. Und dafür gibt es dann in WebRTC diese PeerConnection. PeerConnection ist die Möglichkeit, Peer-to-Peer zwischen den Browsern Verbindungen aufzubauen. Also ohne dass die Surfer, wie es bisher immer sein musste, erst über irgendeine Verbindung zum Surfer gehen und dann zum nächsten weitergeleitet werden. Nein, mittlerweile ist es so, dass man einfach direkt zwischen den Browsern mit einer direkten Verbindung übertragen kann. Was dann natürlich auch, wenn man große Daten überträgt, dann eine Menge Trafficspart und Aufwand. Und das Letztes haben wir dann. Man will natürlich nicht einfach nur diese Videodaten übertragen. Man möchte auch sonstige Daten übertragen können. Gibt es noch die sogenannten Data Channels. Damit kann man dann beliebige Nutzerdaten übertragen. Damit kann man seinen Chat integrieren. Man kann da seine Dateiübertragung integrieren und so weiter. Das Ganze ist ein neuer Standard. Ist mir egal, könnt gerne zwischendurch Fragen stellen. Genau, das ist dann das, wo du hier oben diese Verbindungsaufbau-Teile, das hat die meisten Knubbel. Da werden wir uns am längsten mit beschäftigen. Also das ist ein wichtiger Teil davon, den werde ich auch nochmal genauer erklären und wie das genau funktioniert. Genau, Standardisierung. Das Ganze ist in den Browsern drinnen dann, ohne Plugins. Und das Ganze wurde 2011 von Google initiiert und wird mittlerweile in zwei Gruppen weiterentwickelt. Zum einen gibt es die WebPredits-Gruppe in der W3C. Da werden die Javascript-Arpies entwickelt und standardisiert. Also alles, was der Frontend-Web-Entwickler sozusagen zu sehen bekommt, ist diese drei Teile, die ich vorhin gesagt habe. Das GetUser-Media, der DIPIER Connection und der Data Channel. Und der zweite Teil ist die RTC-Web-Gruppe im IETF. Das ist die Internet-Engineering Taskforce. Das ist eher das On-the-Wire. Also das, was dann einmal im Netzwerk übertragen wird, damit man sich auch diese verschiedenen Bits und Bytes, die man da überträgt, sich gegenseitig verstanden werden können. Das Ganze ist Work-and-Progress. Das ist noch kein verabschiedeter Standard, sondern wird seit 2011 weiterentwickelt. Ich hatte ja schon gesagt, 2013 haben wir Palaver entwickelt. Und da war so der erste Punkt, wo man sagen könnte, jetzt kann man es in der Praxis nutzen. Und jetzt ist es in den ersten Browsern drinnen. Aber wie sieht es denn aus mit der Implementierung in den Browsern? Da habe ich hier mal eine schöne Tabelle. Das ist von ISWeb-ETC-Ready-Yet. Das ist eine Website, die da den Fortschritt aufzeichnet, wie weit die Implementierung in den einzelnen Browsern ist. Was man da sieht, einige Browser sind besser als andere. Also an der rechten Seite haben wir da unsere Problemkinder. Zum einen den Safari, der überhaupt noch nicht mitspielen will. Und zum anderen, ja, den Internet-Explorer haben Sie mittlerweile rausgenommen aus der Liste ansonsten, sah der genauso aus wie der Safari, aber jetzt mittlerweile noch den Edge, wo auch einiges fehlt. Und das Wichtigste, was fehlt beim Edge, ist die Solid Interoperability. Also das ist so, die meisten Browser, also Chrome, Opera, Firefox, die können auch derzeit miteinander sprechen. Also sie sind miteinander, sind Verbindungen möglich. Das ist mit Edge derzeit noch nicht möglich. Also Edge hat da noch einiges nachzuholen, bis man da die in den normalen Workflow integrieren kann. Aber ansonsten sieht man das bei den Chrome und Firefox, die ja hoffentlich die verbreitesten auch sind in eurem Umfeld, dass da ziemlich viel grün, ein bisschen gelb und ein bisschen rot, aber das, was man braucht, das ist eigentlich alles möglich derzeit, solange man eben nicht irgendwelche komischen Microsoft oder Apple-Produkte unterstützen muss. Jetzt noch ein paar praktische Beispiele, die das WebRTC denn sein kann. Als erstes das Palava, ich habe es jetzt schon mehrfach genannt, das ist einfach so eine Website, palava.tv, wo man sich hinverbinden kann. Dann hat man so eine schöne Auswahl, da kann man entweder einen Raumnamen sich auswählen oder einen privaten Raum machen, wo er sich dann einen geheimen Raumnamen ausdenkt. Und wenn man sich dann verbunden hat, dann sieht man erstmal nur sich. Und dann kann man den Link weiter schicken an Leute, die man noch einladen will. Da sieht man noch die anderen Leute, mit denen man sprechen will. Also es braucht keine Nutzer-Accounts, es ist einfach nur, dass man Link weiter schickt. So funktionieren derzeit die meisten dieser Videokonferenz-Lösungen auf WebRTC-Basis, dass sie eben auch dieses Privacy mit betonen, dass es eben eine P2P zu Ende verschlüsselte Verbindung ist, dass wir als Palava überhaupt nichts davon sehen, was ihr da genau kommuniziert. Und dass es eben ohne Accounts geht und man einfach nur diesen Link verschickt, oder dass wir genau wissen müssen, wer ihr denn genau seid. Eine weitere Möglichkeit, was man mit WebRTC machen kann, ist dann natürlich diese Data-Channels-Nutz, die ich schon angesprochen hatte. ShareFest ist eine Website, wo man dann einfach Dateien hin- und herschicken kann. Und das natürlich auch für den Betreiber viel günstiger als bisher, denn bisher war es so, man muss irgendwo ein Websurfer hinstellen, alle Daten werden zu dem Websurfer geschickt, und der Websurfer schickt sie dann an den anderen. Jetzt kann man einfach nur mit diesem Vermittlungsaufwand, den wir uns nachher noch mal anschauen, kann man einfach nur sagen, hier, ihr braucht eine direkte Verbindung auf, und wir schicken jetzt die Daten direkt zwischen euch hin und her. Man kann natürlich auch ein bisschen kreativere Sachen damit machen, das verbindet so ein bisschen beides. Hier habe ich ein Beispiel, das nennt sich CubeSlam. Wenn man Multiplayer macht, sieht man dann in dem anderen, in dem Gegenüber, die Webcam des Gegners, und kann Multiplayer-Pong spielen. Und kann dann das Gesicht des Gegners verpixeln, wenn man Punkte macht. Das ist so eine Möglichkeit, wo man eben kreativ alle Teile von WebPD zusammennehmen kann, dass man irgendwie eine Videokonferenz-Komponente drin hat, dass man das Video überträgt, und dass man aber trotzdem noch mit dem Data-Channels dann die Spieldaten übertragen kann. Und man kann natürlich ganz fancy Zeug machen. Das ist von Mozilla ein Projekt, das nennt sich Banana Bread. Die haben die CubeEngine von C auf Javascript kompiliert und haben die Implementierung der Sockets dann auf die Data-Channels umgebaut. Und da kann man jetzt in seinem Browser eine Unreal Tournament-Klon spielen. Also sowas auch möglich, hat man natürlich ungefähr halbe Latents. In Gegensatz zu anderen Möglichkeiten, die man vorher im Web hatte, weil man eben wie gesagt wieder die Verbindung direkt zwischen Browser und dass man nicht über den Surfer gehen kann, muss. Genau, das ist so ungefähr das, was man machen kann. Und Frage ist natürlich, wie weit ist das jetzt schon verbreitet? Ich habe damals wo Beispiele, wer das bisher nutzt, zum einen nutzt es Firefox selbst. Ist das vielleicht schon aufgefallen? Es gibt jetzt so einen neuen Button, dieser Hello Firefox-Button, oder Firefox Hello, wo man einfach klicken kann. Dann bekommt man wieder so eine Webadget-C-Videokonferenz, wo man den Link weiter schicken kann und andere Leute einladen kann. Und dann kann man wieder ohne Account einfach eine Videokonferenz anfangen. Und das finde ich schon interessant, dass wirklich einfach jeder, der irgendwie einen Firefox sich installiert, dann schon mit einem Klick an so einer Sache dran ist und eine Alternative zu Skype usw. hat. Wer es auch nutzt, Facebook. Facebook hat es in ihren Online-Messengers integriert. Früher haben sie Skype-Links verschickt. Wenn man so eine Videokonferenz eingeladen hat, dann haben sie einen eigenen Web-RTC-Chat integriert. Und wenn wir jetzt sehen, Facebook nutzt das doch bestimmt Voll-Privacy und so. Und ist das denn jetzt unbedingt sicher? Das ist ja ein bisschen das Thema auf des Talks. Ist es denn unbedingt sicher, wenn Web-RTC draufsteht oder können da immer noch irgendwelche Fallstrecke drin sein, kann man sich als User darauf verlassen, dass man da nicht veräppelt wird von den Anbietern oder ist es unbedingt sicher? Als Erstes schauen wir uns das Ganze mal auf der Anwendungssicht an. Wie macht jetzt ein Web-Entwickler, dass, wenn er gerne dieses Get-User-Media nutzen will, habe ich mal ein bisschen Code hier auf die Folie getan. Das ist alles, was man machen muss, um das Bild des Users auf eine Website einzubinden. Als Erstes sagt man ein paar Constraints. Er sagt man, also ich hätte gern Audio, ich hätte gern Video. Danach ruft man diese von mir schon mehrfach erwähnte Get-User-Media-Funktion auf. Übergebt diese Constraints sagt, also ich hätte gern Audio und Video und bekommt in einem Callback dann im Optimalfall natürlich den Stream. Und den kann man dann einfach an Videotech anfügen. HTML5 ist schon schön, oder? Dass man dann so ein Videotech hat, wo man das einfach so anfügen kann und schon sieht man den User. Also so einfach ist das da, diese Kamera benutzt, das einzubinden. Die Frage ist jetzt natürlich, wenn ich jetzt ein Marktforschungsinstitut bin, was Leute dabei beobachten will, wie sie meine Website beobachten, kann ich das denn jetzt einfach immer so machen oder hält mich irgendwas davon ab? Ja, es hält mich etwas ab, denn es wird natürlich nach Erlaubnis gefragt, wenn ich den Kamerazugriff haben will. Das bedeutet, es ist nicht einfach möglich, dass wenn ich eine Webcam dran habe, dass dann jede Website diese abgreift. Also es ist immer so, dass der Benutzern noch um Erlaubnis gefragt wird. Hier habe ich die Beispiele zum einen von Chrome, zum anderen von Firefox. Bei Chrome sieht man dann da oben die Leiste mit allow or deny. Und unten beim Firefox kann man da auch sogar noch die Kamera auswählen, welche man der Website zur Verfügung stellen will. Und so wird der Nutzer davor geschützt, dass da Leute einfach so auf die Kamera zugreifen, ohne dass er es weiß. Was ein bisschen Nachteil an dieser Variante ist, ist es so, dass wenn die Verbindung HTTPS verschlüsselt ist, wird er nur einmal gefragt, weil man hat den Website-Betreiber ja schon einmal mit der Kameraverbindung vertraut. Und da vertraut man ihn natürlich immer wieder. Das bedeutet, wenn ihr einmal auf Palawatevorgewesen seid, einmal geklickt habt, ich erlaube den Kamerazugriff, dann wird es in Zukunft immer sofort gestattet. Kann natürlich sein, wenn jemand danach evil wird. Und was anderes mit eurer Kameraverbindung vorhat, das ist so ein bisschen der Nachteil, aber von der Usability her war es wahrscheinlich, dass sie sich gedacht haben, dass es jetzt der Kompromiss, den wir eingehen, wir fragen einmal. Und wenn man den nachweisen kann, dass die gleiche Person danach noch ist, dann erlauben wir es der Person immer. Das wäre dann möglich, aber im Zweifel hat deine Kamera hoffentlich ein Lichtchen, dass du siehst, wenn deine Kamera angeht. Ich habe die Streifen vor seiner Kamera. Genau nochmal für den Stream und die Nachwelt. Man sieht auch in seinem Tapp dann einen Eiken, dass da eine Kamera aktiv ist, neben dem das da hoffentlich die Kamera leuchtet. Genau, so weit zum Kamerazugriff. Und jetzt schauen wir uns nochmal genauer an, wie das denn mit den Peer-to-peer-Verbindungen aussieht, auch wenn das für die meisten wahrscheinlich nichts Neues sein wird, wenn man jetzt eine Verbindung herstellen will und die Verwendung herstellen kann. Man kann das nicht wirklich unterbinden, wo das angezeigt wird. Also Web-ATC kann man, ich glaube im Chrome, gar nicht unterbinden. Im Firefox kann man ein Häkchen setzen, dass es aus ist, aber dass es irgendwie in einem Iframe oder so drin ist, kann man nicht unterbinden. Wüsste ich nicht, wie das geht. Da wüsste ich grad nichts, wie so was funktioniert, wie man das da einschränken kann. Okay, Peer-to-peer-Verbindungen. Wir haben eine Kommunizierung. Wir hätten gerne eine Videokonferenz. Wir gehen jetzt mal davon aus, dass es Palaver ist. Das ist das einfachste Beispiel. Und Sie wollen jetzt eine Videokonferenz machen. Was machen wir also? Wir haben ja eine Peer-Connection. Okay, so weit zu einfach. Wir haben noch Charlie dazu. Charlie möchte jetzt auch noch in diese Videokonferenz reinkommen. Was machen wir? Okay, Charlie wurde von Alice eingeladen. Also machen wir erstmal eine Peer-Connection und das Problem ist bloß, Charlie sieht jetzt Alice. Alice sieht Bob, aber Bob sieht Charlie nicht. Was müssen wir also machen? Bob muss also auch noch Charlie dir Videodaten schicken und Charlie muss Bob die Videodaten schicken. Was wir jetzt also schon haben ist, Alice, jeder einzelne Teilnehmer muss zweimal die eigene Videodaten raus schicken. Und da wir in einer Welt von Asylnchronen-Internet-Verbindungen leben, kann das irgendwann knapp werden. Besonders wenn jetzt Dave noch dazukommt, dann haben wir schon dreimal Verbindungen, die wir raus schicken müssen. Das waren unseren Tests dann für haushaltsübliche Verbindungen dann eigentlich schon eine Herausforderung, vier Leute gleichzeitig in so einer Konferenz drin zu haben. Mehr will man dann eigentlich nicht über Peer-to-Peer machen. Was gibt es dafür Alternativen dafür? Man kann sich etwas einbauen, das nennt mal Multi-Point-Control-Unit MCU. Und das ist einfach ein Surfer, der irgendwo in der Gegend rum steht. Und dann haben wir wieder Alice, Bob, Charlie und Dave. Und die verbinden sich alle zu der MCU, die senden einmal ihre Videodaten zu dieser MCU per WebRTC und bekommen von der MCU alle drei anderen Videostreams wieder zurück. Vorteil ist, wir haben jetzt unsere Bandbreitenprobleme für den Benutzer gelöst. Nachteil ist, wir haben das Ganze zugefügt, weil die MCU müssen wir natürlich irgendwo hinstellen. Die muss im Zweifel dann noch die Videodaten umkodieren für die geringeren Auflösungen, wenn jemand schlechter angewunden ist. Und es ist natürlich auch so, es war ja bisher so in unserem Peer-to-Peer-Beispiel, dass jede einzelne Verbindung Ende zu Ende verschlüsselt war. Und das können wir hier natürlich nicht mehr sicherstellen, dass der Anbieter nicht sieht, worüber kommuniziert wird. In diesem Video, wenn dieses Szenario genutzt wird mit einer MCU dazwischen, dann ist es immer so, dass der Anbieter theoretisch die Daten abhören kann und mitschneiden kann. Das ist natürlich ein bisschen ein Gefahr. Es gibt Anbieter, die bei WebLTC so was anzusetzen. Ich nehme an, dass auch dieser HelloFireFox-Button das tut. Palaver tut das nicht. Zum einen aus Privacy-Gründen, Palaver ist mittlerweile ein gemeinnütziger Verein und wir wollen einfach nur da diese günstige Infrastruktur bereitstellen und dem User in Privacy geben. Genau, das ist eben da das Problem, dass der Nutzer auch nicht unbedingt weiß, in welchem Szenario gerade diese Web-Applikation fährt. Also ob er sich direkt zu den Endnutzern verbindet oder ob da irgendetwas dazwischen ist. Das kann der User nicht so einfach sehen. So einen, der in der Mitte steht, zu implementieren, wäre theoretisch möglich. Das Problem ist bloß, dass der dann eine richtig große Bandbreite braucht. Weil er alles raus schicken muss. Das ist dann schon nicht mehr trivial, den zu finden, wenn da einfach nur zufällige Leute sich verbinden und in Zweifel alle eine schlechte Verbindung haben. Also in Zweifel haben wir immer eine schlechte Verbindung. Okay, das ist also schon ein Problem, was wir sehen. Man weiß nicht genau, in welchen dieser beiden Szenarien man fährt. Es ist zwar so, dass Web-ATC peer-to-peer Verbindungen anbietet. Man weiß aber nicht, ob man eine peer-to-peer Verbindung zu so einer MCU aufbaut oder ob man sie wirklich zu den anderen Teilnehmern aufbaut. Was wir jetzt als nächstes machen wollen, wir wollen uns den Verbindungsaufbau oder noch kurz die Verbindung zu der MCU ist auch verschlüsselt. Das Gruppenschlüssel um das so nochmal zu verstärken, gibt es gerade kein Szenario, für theoretisch könnte man es vielleicht über den Datachannel implementieren, dass man in ja was krippt, dann die Verschlüsselung implementiert, aber ich sehe es jetzt nicht in unserer Zukunft gerade. Also es ist eher nicht so einfach. Was, da gucken wir uns genauer nachher nochmal an, was genau die Verschlüsselung aussieht. Genau, jetzt zu dem vorher schon angefragten Verbindungsaufbau. Denn wie schon angemerkt wurde, unser Ziel ist ja einfach, dass wir irgendwie eine Peerconnection haben, aber ganz so einfach, dass zwei Leute auf eine Website gehen und dann haben sie eine magische eine Peerverbindung ist ja nicht. Also schauen wir uns mal den ganzen Ablauf genauer an. Was wir hier als erstes haben, wir brauchen natürlich einen Websurfer, zu dem wir uns hinverbinden, da runterladen und so weiter. Also Download der Web-Applikation, Download der Web-Applikation, denn beide Teilnehmer brauchen natürlich die Palava-TV-Website, wenn wir jetzt bei dem Beispiel bleiben wollen. Was passiert als nächstes? Irgendwie müssen die Leute sich finden. Dafür gibt es dann diesen so genannten Signaling-Surfer. Der Signaling-Surfer ist dafür da, diesen Teil zu liefern, dieser Abstimmung, damit die Leute sich finden und damit sie ein bisschen koordinieren können, wie die Verbindung dann am Ende aussieht. Was man dann macht, ist, dass in diesem Fall Alice eine Offer sendet und in der Offer steht ungefähr drinnen, was für ein Video-Kodec unterstützt, der Browser von Alice, vielleicht auch unter welcher Adresse ist Alice erreichbar, dann steht da noch drinnen, welche Optionen für die Verbindung noch sind, also welche Optimierung man dann noch auf der Verbindung auf der Offer wird an den Signaling-Surfer verbunden und der Signaling-Surfer schickt dann diese Offer weiter an Bob. Und was Bob dann damit macht, Bob wertet diese Offer aus und schickt dann eine Anzer darauf. In dieser Anzer steht ungefähr das Gleiche drinnen wie in dieser Offer, plus eben darauf angepasst, dass eben die Kodecs schon so ausgewählt wurden, dass nur das genutzt wird, was Alice angeboten hat und dass sie automatibel sind. Und wenn dann Alice diese Anzer hat, dann hat man immer noch ein Problem, weil man befindet sich im Zweifelfall nicht hinter einer öffentlichen IP, sondern muss erst noch dafür sorgen, dass man sich wirklich finden kann. Diese ganzen Browser stehen ja hinter irgendwelchen Plastik-Kisten und haben nicht direkten Zugriff aufs Internet, also haben zwar direkten Zugriff aufs Internet, aber das Internet hat nicht direkten Zugriff auf sie. Man nennt sich Hole-Punching. Das werde ich nachher noch mal genauer erklären. Dieses Hole-Punching ist dafür da, dass man eben die Verbindung aufbaut, dass man ein Loch in die Firewall beziehungsweise den Nuts schlägt. Und wenn man das Hole-Punching gemacht hat, dann schickt man die Information, die man aus diesem Hole-Punching erworben hat, weiter an den Alice in diesem Szenario und Alice macht genau das Gleiche, schickt die Daten dann weiter und dann hat man eine PeerConnection. Was man also braucht, ist der Websurfer, den man ja normalerweise schon in seinem Reparat war, ein Zicklingsurfer, das ist dann was Spezifisches für das WebRTC, aber auch keine Magie und so ein Stoon-Surfer, der ist auch schon etablierte Technologie, das ist nämlich das Gleiche, was man bei VoiceOverIP-Telefonie derzeit schon nutzt, um dieses Hole-Punching zu machen. Jetzt schauen wir uns mal an, wie so eine Offer und so eine Anzer eigentlich aussieht, die wir da hin- und herschicken. So sieht eine Offer- und Anzer aus. Ich lasse es erstmal in kurzen paar Sekunden wirken, kann ja jeder mal ein paar Zeilenzieh anschauen. Man sieht schon, es ist nicht wirklich schön, das ist auch einer der Punkte, wo Microsoft sich beschwert hat und auch andere Leute sich beschwert haben, dass es jetzt nicht unbedingt State of the Art ist, dass man da solche komischen Zeilen hin und her schickt. Das, was Microsoft und andere da als Alternative vorgeschlagen haben, ist ein JSON-basiertes Protokoll für diese Aushandlung der Verbindung und das wird jetzt höchstwahrscheinlich auch kommen, also das ist WebRTC 2.0 geplant, dass es wahrscheinlich da, wo Microsoft dann auch aufspringen wird, also dieses WebRTC, wie es jetzt ist, werden sie wahrscheinlich nicht mehr unterstützen, aber sie werden dann höchstwahrscheinlich bei WebRTC 2.0 aufspringen und das richtig umsetzen. Und hoffentlich haben wir dann ein Internet, wo alle sinnvoll miteinander WebRTC sprechen können. Genau. Was genau bedeutet das jetzt alles? Ich werde natürlich jetzt nicht Zeile für Zeile durchgehen, ich werde nur ein bisschen Übersicht geben. Es besteht unter anderem aus diesen M-Lines, also so eine M-Line steht immer für eine Komponente, die man überträgt. Was wir hier sehen, ist als erstes diese Audio-Komponente, also man sieht M ist gleich Audio und dann ganz viel Zeug dahinter. Und da wird eben, wenn man jetzt Audio und Video überträgt, wird da einfach beschrieben, ja, das ist jetzt, ich biete dir eine Audioverbindung an und ich kann folgende Kodex dir anbieten. Mit folgende Kodex verstehe ich. Mit folgenden Kodex können wir uns unterhalten und mit diesem Bit raten können wir uns unterhalten. Und dann sind noch ein paar Optionen dabei und weiter unten sieht man dann schon ein bisschen was über die Verbindung. Das Gleiche hat man dann nochmal für das Video. Da sieht man schon, dass es ein bisschen kürzer ist, weil man nicht ganz so viele Video-Kodex unterstützt. Das war auch ein bisschen ein Kampf in der Anfangszeit, dass Google versucht hat, V8 durchzudrücken und Mozilla lieber versuchen wollte, H264 als etablierte Technologie zu nutzen. H264 ist natürlich das Problem, dass es mit Patenten belastet ist. Das, was derzeit jeder unterstützt ist V8. Also da hat man sich derzeit auf diesen Standort geeinigt, damit alle auch Video miteinander austauschen kann und sich die Browser verstehen. Internet Explorer unterstützt natürlich nicht V8, unterstützt natürlich H264. Da müssen wir mal sehen, wie es wird, wenn das dann soweit fertig ist, wenn Microsoft da richtig mitmacht. Als letztes haben wir da noch unsere MIS-Gleich-Application-Line drin gehabt. Das sind dann die Dataschannels. Also da haben wir dann unsere Dataschannels, mit denen wir sonstige Daten übertragen können. Und jetzt kommen wir zu dem lustigen Part des Hole-Punchings. Da sitzt zu Hause, wollt irgendwie ein Surfer aufmachen und stellt fest, so richtig Internet ist das nicht, was ich hier hab. Irgendwie muss ich da noch was bekommen, zum Rauszukommen. Wenn wir jetzt einfach sagen, es ist schönes Internet, was wir haben, wir haben Alice und Bob und wir hätten gerne wieder eine PeerConnection, die am Ende per UDP ist, dann können wir einfach, wenn normales Internet wäre, schönes Internet, um Magie, wir haben eine Verbindung. Das Internet ist aber leider nicht so schön. Wir haben da komische graue Balken, die sind im Zweifel kleine Plasterooter, die da Network-Address-Translation machen. Weil im Zweifel hinter einem so komischen kleinen Plasteding sitzen dann verschiedene Rechner und man hat nur eine IP-Adresse. Deswegen müssen irgendwie die Anfragen, die auf diese IP-Adresse eingehen, weitergeleitet werden und die Frage ist natürlich dann, was ist das für eine Verbindung? Schauen wir uns also mal an, wie man das machen kann. Wir versuchen es erstmal naiv, fängt einfach jemand an, ich sage es mal durch Zufall Bob. Bob versucht, sich zu der IP zu verbinden, die er von Alice kennt und er bleibt einer Plastik-Histe hängen. Lasst mal was anderes probieren. Alice versucht sich zu Bob zu verbinden. Der Router weiß natürlich, wie es ins Internet geht, und was jetzt passiert? Der Router merkt sich, oh, Alice hat UDP-Pakete geschickt über diesen Port an Bob. Und ich habe es über diesen Port an Bob rausgeschickt. Und wenn jetzt irgendwie von Bob was zurückkommt über genau diesen Port, dann sagt der Router, ich erinnere mich, da war was. Ich glaube, das gehört zu Alice. Und das ist dann, wie man anfangen kann, dieses nachzuumgehen. Dass man eben sagt, hey, mal diese Verbindung nehme ich wieder auf. Also das ist, dass da eine Tabelle ist, wo die Adressen eingetragen sind und die Ports dann entsprechend zugewiesen werden. Es ist aber natürlich nicht so, dass es immer nur so halb unschön ist im Internet. Im Zweifel ist es gleich richtig unschön. Sondern wir haben zwei solche Plastik-Histen dastehen. Wir machen wieder unseren Ansatz, von vorhin wir probieren einfach Bob alles mal. In die eine Richtung probieren wir Alice versucht, zu überwinden. Nein, funktioniert nicht. Bob schickt was an Alice. Nein, leider auch nicht. Was macht man jetzt? Die Lösung ist, es gibt was, das nennt sich Stoon Surfer. Ein Stoon Surfer ist dafür da, dass solche Szenarien dann überwunden werden können. Was der Stoon Surfer macht ist, Alice schickt an den Stoon Surfer eine Anfrage. Mit dieser Anfrage wird schon mal ein Problem gelöst, was ich bisher einfach übersprungen habe. Alice, ihre eigene IP-Adresse, natürlich gar nicht weiß. Alice kennt vielleicht die IP-Adresse, die sie im lokalen Netzwerk hat, aber Alice weiß nicht, wie sie im großen, weiten Internet zu erreichen wäre. Dieses Problem können wir dadurch lösen, dass wir an den Stoon Surfer eine Anfrage schicken. Dass der Stoon Surfer uns dann zurück sagt, hey Alice, ich habe gerade von dir unter dieser IP-Adresse eine Anfrage bekommen und hier hast du deine Verbindungsdaten. Dadurch weiß man die IP-Adresse von Alice und weiß auch den Port, über den man kommuniziert hat. Das muss nicht immer der Gleiche sein. Router machen das teilweise auch so, dass der Port über den man denkt, dass man es schickt, geändert wird und ein anderer Port rauskommt. Was wir jetzt haben, ist, dass wir diese gepunktete Verbindungen haben. Die haben wir ja vorhin schon gehabt, dass dann irgendwie darüber wieder eine Verbindungsaufbau möglich ist. Und was man jetzt versuchen kann, man kann jetzt sagen, wir schicken einfach zu dem Port, den der Stoon Surfer gesehen hat, UDP-Pakete und gucken mal, was passiert. Denn der Router ist vielleicht so dumm oder schlau, kann man sich jetzt streiten, dass er sich nicht merkt, dass es zu dem Stoon Surfer diese Verbindung ist, sondern dass einfach nur eine Verbindung ist, die Alice hat. Dadurch kann man nämlich das Network Address Translation und kann dann diese Verbindung aufbauen. Und so hat man dann seine peer-to-peer-Connection zwischen den einzelnen Browsern über das Internet aufgebaut. Und deine Frage ist hoffentlich beantwortet. Es ist aber natürlich immer noch nicht alles perfekt. Also mit diesem Szenario kann man, ich sage mal, grob 90 Prozent der Fälle erschlagen. Es gibt aber immer noch Fälle, wo Netzwerke besonders restriktiv eingerichtet sind und teilweise einfach Plasterouter besonders schlecht gemacht sind, kann es immer noch sein, dass man diese Methode nicht hinbekommt. Als letzte Methode gibt es da noch den sogenannten Törnsurfer. Der funktioniert einfach so, dass Alice nicht nur am Anfang eine Anfrage an den Törnsurfer sendet, wie dann ihre IP-Adresse wäre, sondern dass Alice einfach jegliche Daten über den Törnsurfer schickt. Und der Törnsurfer jegliche Daten, die an ihn geschickt werden, werden an Bob weiterleitet. Hier sehen wir natürlich, man ist gleich zwei Vorteile los. Vorteil Nummer eins, ich muss keine dicke Infrastruktur mehr betreiben. Naja, wenn ich da so ein Törnsurfer hinstelle und alle Leute ihre Daten darüber schicken, dann sieht es zwar am Ende wie Piotopier aus, aber es ist natürlich am Ende wieder so, dass irgendwie die Daten über mich für diese 10 Prozent der Nutzer gehen. Das kann teuer werden. Das andere ist natürlich die Frage, inwiefern man den dann noch vertrauen kann, wenn da die Daten darüber geleitet werden, inwiefern es dann auch vertrauenswert ist, dass diese Instanz dann diese Daten nicht einfach abhören kann. Aber darüber bekommt man dann, sagen wir mal, fast 100 Prozent der Nutzer mit so einer PureConnection ausgestattet. Es gibt natürlich auch hier wieder eventuell sehr restriktive Netzwerke, wo es nicht funktioniert, aber das Leben ist hart. Genau. Und was wir sehen ist, mit diesem Set-Up bekommen wir das so weit hin. Das ganze Protokoll insgesamt, also zusammen mit diesem Stoon und diesem Törn, nennt sich dann Interactive Connectivity Establishment Protokoll, das ICE Protokoll. Das haben wir schon in den vorherigen Anfragen ein bisschen gesehen. Da gab es immer solche Zeilen. A ist gleich Candidate. Das sind die sogenannten ICE Candidates. Also, das sind Möglichkeiten, wie man den entsprechend eine Browser dann erreichen kann. Also, was das wir hier sehen, das sieht nach einer lokalen IP-Adresse aus, die 192, 168, 147, 100. Das ist die Adresse in unserem Büro von meinem Rechner, falls ihr mal in unserem Netzwerk seid, könnt ihr dann wissen, wo auch mein Rechner steht. Und das ist das Einfachste, das man natürlich als Browser rausfinden kann, indem man einfach die Netzwerkinterfaces abfragt. Und deswegen steht das schon der Affe und Anzer dran. Und was man dann zusätzlich noch macht, ist, dass man dieses ganze Protokoll mit dem Stoon-Surfer abläuft. Und normalerweise macht man das über sogenanntes ICE-Trickling. Das ist so, dass man nach und nach über diesen Sickling-Surfer noch mehr Informationen über sich herausgibt. Das bedeutet, wenn ich jetzt zum Beispiel mich mit Kilian, der auch das erste Schritt schon sofort diese Verbindung aufstellen kann, weil ich mich zu den lokalen Netzwerk-Adresse verbinden kann. Und wenn das nicht funktioniert, dann probieren wir es weiter, machen diesen ganzen Stoon-Aplauf und können nachher vielleicht noch herausfinden, wie es wirklich funktionieren kann übers Internet. Und da kommen diese ICE-Trickling-Messages nachgeliefert, die dann an sich genauso aussehen, plus noch ein bisschen komplexer dafür, dass sie eben diese Informationen halten, wie es dann weitergeht. Ja, das sah ja jetzt schon relativ komplex aus. Und die Frage ist natürlich, wie kann man das jetzt in sein eigenes Projekt integrieren? Wie viel Aufwand ist das jetzt aufzunehmen, eventuell so etwas wie Palaver zu schreiben? Ich habe hier mal ein kleines Beispiel mit der Palaver-Klein-Bibliothek. Also das ist die Bibliothek, mit der man dann WebRTC nutzen kann, die aus Palaver entstanden ist. Jetzt gehe ich mal ein bisschen durch. Oben hat man so ein Channel. Das ist eine WebSocket. WSS bedeutet WebSocket Secure. Das ist dann TLS verschlüsselt. Das ist die Verbindung zu dem Signaling-Surfer, der einem dann diese Arbeit abnimmt, dass man sich miteinander verbinden kann. Dann gibt es dieses Session-Objekt, was so ein bisschen das zentrale Objekt ist. Dann gibt es Session on Local Stream Ready, das bedeutet, wenn mein Video Bild fertig ist, dann kann ich das an mein Videotech attachen und kann sagen, ich habe mein lokales Videobild, jetzt kann ich den Raum betreten. Dann hat man das noch on Peer Stream Ready. Das bedeutet, wenn irgendein anderer Stream Ready ist von einem anderen der in dem Chat drin ist, dann gucken wir erstmal, ist man es selber, dann hat man es ja schon abgearbeitet und ansonsten legt man neue HTML5-Videotech irgendwo, sagt, ich tue jetzt meinen Videostream reintun und falls der Peer irgendwann mal sagt, ich bin jetzt weg mit dem Peer on Left, dann entfernt man das Ganze wieder aus seinem Dom und am Ende sagt man noch Session Innet, damit das Ganze angestoßen wird, kann da als Option noch den Student-Surfer reingeben und mit so relativ wenigen Zeilen kann man das Ganze schon abarbeiten. Diesen gesamten komplexen Prozess, der dann im Hintergrund läuft, dann kann man sich nicht wirklich mit auseinandersetzen. Es gibt natürlich noch andere Möglichkeiten Web-LTC zu nutzen, zu meinen kann man es natürlich komplett selber machen. Es gibt aber noch viele andere Bibliotheken, die das umsetzen. Ich habe hier mal noch ein Beispiel von ATClib, das ist eine Bibliothek, an der ich gerade arbeite, die ein bisschen nutzerfreundlicher ist, hoff ich dann am Ende, wo man dann so einen Raum auch wieder anlegen kann, zum Local Ad Stream, wo man dann wieder das eigene Videobild hinzufügt, das kann man dann wieder an Videotech anfügen und dann immer, wenn peer joined kann man wieder seinen Dom anlegen dafür und das Left ist wieder genau das gleiche und dann am Ender Room Connect. Also da gibt es viele Möglichkeiten, wie man Web-LTC nutzen kann und kann man sich einfach irgendwas raussuchen, was man da haben will. Die Frage ist natürlich, was jetzt mit der anderen Infrastruktur, die wir da integriert haben, wir haben ja zum einen noch den Zickling-Surfer da habe ich auch was Kleines geschrieben, was man einfach nutzen kann. Ein Easy-Need-Zickling nennt sich das, wenn man zum Beispiel einfach schon Node-Projekt hat, kann man das einfach in die Node-App integrieren. Da habe ich hier mal ein kleines Code- Beispiel dafür, mit so wenig Code kann man dann ein Zickling-Surfer integrieren. Den Zickling-Surfer kann man genauso standalone laufen lassen und auch noch machen kann. Es gibt zum von Palava-Projekt, gibt es genauso einen Zickling-Surfer, den man einfach nutzen kann. Also Zickling-Surfer ist kein Problem. Alles, was ich bisher gesagt habe, ist natürlich Open-Source. Ich denke, das muss man nicht dazu sagen, wenn wir uns auf den Datenschworn befinden. Und das letzte, was da noch ist, die Stune und Turn-Surfer, da gibt es einige Stune und Turn-Surfer, die schon relativ alt sind und natürlich dann auch etabliert. Weil es einfach genauso zu der SIP-Infrastruktur, was die voice-over-IP-Infrastruktur ist, die genauso von den Telekom und allen anderen genutzt wird, ist. Da kann man dann zurückgreifen und sich einfach einen entweder einen Stune-Surfer installieren auf seinem Surfer oder einen der freien Stune-Surfer nutzen. Also da gibt es auch Stune-Surfer, wo man einfach sagen kann, ich trage den jetzt hier ein und die sind zur freien Nutzung freigegeben. Also so kann man relativ einfach sich so eine Web-DTC- Infrastruktur aufsetzen bzw. vorhandenes nutzen. Als nächstes kommen wir jetzt noch mal ein bisschen dazu, wie das Ganze dann on the wire aussieht, wie dann die eigentlich Übertragung aussieht und natürlich immer wieder mit, wie sieht das denn eigentlich in Bezug auf Sicherheit aus. Das ist der Protokoll-Stack von Web-DTC, was wir hier haben ist, wir schauen es uns mal ganz an, die eine Seite ist einfach der normale HTTP-Protokoll-Stack, den man so schon kennt. Also da hat man HTTP12, darunter ist hoffentlich TLS, weil man will ja ein bisschen sicher sein, dass man das verschlüsselt. Wenn man sein Sickling nicht verschlüsselt, dann kann man es eigentlich auch bei dem Rest gleich sein lassen. Und auf der anderen Seite wird es dann interessanter. Da haben wir dann nämlich diese RTC-Pier-Connection, die wir ja schon kennen. Und da haben wir zum einen dieses SRTP. RTP ist ich sage es heute schon, komme ich wieder zu dem zurück, was ich schon ein paar Mal gesagt habe. Man nutzt ganz viel die Infrastruktur von dem Voice Over IP, von dem SIP. Und RTP ist das gleiche Protokoll, wie man da nutzt. Also es ist genauso, wenn ihr über Voice Over IP telefoniert, ist es genau das gleiche Protokoll. Es wird auch teilweise zum Video Streaming und so eingesetzt. Und SRTP steht dann dafür, dass es verschlüsselt ist. Also da hat man einfach nochmal eine Verschlüsselung und was dann jetzt natürlich interessant wird bei der Verschlüsselung, wie funktioniert dann der Schlüsselaustausch. Denn wenn man mit irgendjemandem verschlüsselt, hat man da ja noch nichts davon. Und wenn der Schlüssel irgendwann bekannt ist, kann es natürlich auch Probleme geben. Für den Schlüsselaustausch gibt es zwei Methoden. Zum einen gibt es die Methode SDES. Die sieht ungefähr so aus, das habe ich mal aus so einer Offeranzer rausgenommen. Und da steht der Schlüssel einfach so drin in dieser Offeranzer. Es fällt natürlich dem ein oder anderen vielleicht schon auf. Wenn man da einfach so den Schlüssel reinschreibt, kann natürlich auch der Signaling Surfer einfach so den Schlüssel sehen. Und falls der Signaling Surfer zufällig auch Zugriff auf das Netzwerk hat, dann hat er, wenn man Pech hat, auch einfach, kann er den kompletten Stream dann aufnehmen und entschlüsseln. Da haben wir also schon mal ein Problem. Das wurde dann natürlich erstgestellt. Das ist mittlerweile nicht mehr wünscht, dass man SDES benutzt. Also es ist eine Anforderung, dass man die andere Variante nutzen soll. Die DTLSSRTP heißt. DTLS klingt schon mal nach TLS. Kennen wir ja schon. Also der SSL nachfolgern gewisserweise und ist einfach TLS für Datacramps, also für UDP-Verbindungen. Was man hier macht bei diesem DTLSSRTP, ist man das, was man ein TLS-Handshake macht. Über diesen TLS-Handshake hat man sich danach auf einen Schlüssel geeinigt. Und diesen Schlüssel benutzt man dann einfach für das SRTP-Protokoll. Also am Anfang sieht das, was man spricht, nach TLS aus und danach macht man ganz normales SRTP, wenn man sich auf den Schlüssel geeinigt hat. Und was man dann im Signaling dafür noch überträgt, ist der Fingerprint, von dem Zertifikat, dass man sich jeweils zeigt bei diesem Verbindungsaufbau, damit man sich auch sicher sein kann, dass Dänige, der gerade versucht zu einem eine Verbindung aufzubauen, dass der auch wirklich die Person ist, mit der man im Signaling gesprochen hat. Das ist nicht eine normale Zertifikatheraschie, sondern es ist wirklich, das wird sozusagen temporäres oder also es ist nicht genau festgelegt, ob das ein temporäres Zertifikat ist, aber es vorgezeigt wird, sondern es wird eben irgendein Zertifikat gezeigt, von dem das da hinten der Fingerprint ist, wo man genau weiß, das ist das Zertifikat. Ich tue jetzt mal so, als ob das im Signaling-Prozess wäre, ansonsten kommen wir danach noch dazu. Also es ist so, man weiß danach genau, dass man mit demjenigen spricht, mit dem man im Signaling gesprochen hat. So weit rum kommen wir danach noch. Für das erste Problem, das das Signaling-Prozess oder mit welchem Netzwerk ist, ist das das auch immer noch nicht. Das kann ja das Signaling-Prozess immer noch falsch herausgeben. Ach, ihr seid so gut für meinen Vortrag. Also zu dem Problem komme ich noch. Genau. Aber wir können jetzt erstmal so tun, als hätten wir das Problem gelöst. Also man kann sich zumindest sicher sein, dass man mit der Person spricht, von der man denkt, dass man mit ihr spricht, nachdem man mit dem Signaling-Surfer gesprochen hat. Können wir uns darauf einigen, genau. Die andere Seite ist, jetzt sehen wir natürlich, wenn wir jetzt noch mal genau darauf achten, dieses TLS hat da schon ein bisschen reingeluckt in dieses SRTP. Das sollte das bedeuten, dass der Schlüssel-Austausch DTLS funktioniert. Und was man jetzt bei dem Data Channel macht bei diesen beliebigen Nutzdaten, ist, dass man einfach eine SCTP-Verbindung aufbaut. Also SCTP ist nochmal ein Protokoll, das einem ermöglicht, sowas wie UDP und TCP-Verbindung zu emulieren über ein Paketorientiertes Protokoll. Normalerweise fährt man das auf IP-Ebene, aber wir tun einfach und das nochmal vollkommen durchzugehen, wir tun UDP-Pakete nutzen, die in Eisprotokolle verpackt werden, die DTLS verschlüsselt werden, die dann per SCTP gepackt werden und am Ende haben wir da Nutzdaten drin. Also es ist ein relativ komplexer Stack, aber das ist das, was man nutzt und es funktioniert. Genau, wer hätte das gedacht, es ist auf dieses Verfahren mit nötig die ich jetzt einfach nochmal kurz durchgehe. Alice und Bob haben einen Zickling-Surfer, denken sie senden eine Offer, denken sie bekommen meine Ansage und bauen eine Peer-Connection auf. Das ist das, was aus ihrer Sicht passiert. Was aber in Wirklichkeit passiert, es gibt den bösen Chuck. Der Zickling-Surfer ist unter Kontrolle von Chuck. Der Zickling-Surfer sendet die Offer an Chuck weiter oder Chuck hat einfach den Zickling-Surfer so gebaut, dass es manipuliert wird und Chuck sendet dann eine manipulierte Offer an Bob weiter. Genau das gleiche passiert mit der Answer, was hier natürlich einfach passiert ist. Man wechselt natürlich die Fingerprints aus von den Zertifikaten. Wenn man sich ganz einfach machen will, kann man auch noch die ganzen Eisnachrichten auswechseln, und dann ist es so, dass was am Ende passiert, einfach das ist. Man baut eine Peer-Connection zu Chuck auf, von beiden Richtungen Chuck schickt das alles einfach weiter und solange Ellos und Bob ihre IP-Adressen gegenseitig nicht kennen, um das zu verifizieren, ist es einfach so, dass das nicht auffällt, außer dass ein bisschen mehr Latenz drin ist, als üblicherweise. Also, es ist einfach so, dass die Leute das direkt zu einem schicken, wenn es drin ist, als üblicherweise. Also, das ist natürlich immer ein Problem, wenn man diese Infrastruktur nutzt. Was uns aber eventuell auffallen könnte, diese Struktur erinnert relativ stark an das, was wir vorhin schon gesehen haben mit der MCU. Das ist an sich genau die MCU-Struktur. Dass man nie genau weiß, wie man sich denn gerade verbindet. Und da liegt nämlich auch überhaupt noch das große Problem da drin, ist ja auch, wenn man jetzt so eine Web App lädt, kann man sich überhaupt sicher sein, was denn diese Web App tut. Wenn man jetzt so ein normales Desktop-Programm hat, kann man sagen, ja, ich lad mir das darunter. Ich lese jetzt den Code oder verlass mich darauf, dass irgendjemand anderes den Code gelesen hat. Und da liegt das auf meinem Rechner rum und kann das immer ausführen. Ich kann mich immer genau darauf verlassen, dass es genau das Gleiche ist, dass man morgen komplett anders aussehen als so, wie ich es gestern gelesen habe. Man kann sich an sich nie auf solche Web-Applikationen komplett verlassen, solange man die nicht wirklich unter seiner Kontrolle hat, auf dem eigenen Surfer, die Web-Applikation ist und man sich komplett auf das SSL verlassen kann, mit dem man sich dahin verbindet. Von daher hat man nie 100-prozentige Sicherheit mit so einer Web-ADC-Applikation. Was aber jetzt nicht bedeuten soll, dass es sicher ist. Es ist vielleicht einfach sicher genug für gewisse Anwendungsfälle und man kann es definitiv einsetzen. Am Ende will ich nochmal über die einzelnen Sachen drüber gehen, die wir zwischendurch gesehen haben. Kamera- und Mikrofonzugriff haben wir. Ich gehe kurz das durch und dann. Kamera- und Mikrofonzugriff haben wir. Natürlich die Gefahr, dass sich irgendwelche perversen Menschen bei jugendlichen Damen auf den Rechner verbinden, mit einer einfachen Anfrage abgewährt. Was wir beim Eis gesehen haben bei den Interactive Connectivity Establishment, alle PIRs erhalten alle IP-Adressen dieser Maschine. Das bedeutet, man kann zum einen, kann man das sehen als Sicherheitsproblem für eine Detox-Attacke auf dieser IP. Das ist eine mögliche Gefahr und zum anderen ist es auch so, dass man das zum Fingerprinting benutzen kann. Also das ist eine relativ große Gefahr, wenn man einfach diesen Eisprozess startet und dann all diese IP-Adressen raus bekommen kann, vielleicht wart ihr schon mal, es gibt von der, ich weiß nicht mehr genau wer es war, aber es gibt so ein Projekt, wo der Fingerprinting über die Browser-Daten gemacht wird und da bekommt man schon richtig viele Bits hin. Und wenn man dann auch die lokalen und öffentlichen IP-Adressen dazu nimmt, dann wird es noch richtig fies. Da gibt es leider kein, hey, willst du das gerade machen dazu? Also das ist noch eine Gefahr, das Fingerprinting dazu, wie es derzeit in den Browsern implementiert ist, umgeht es meiner, also soweit ich weiß, kann sein, also klar, weil es schon gefixt ist, leider auch die VPNs von, also die Torbrowser und so weiter haben es deaktiviert, weil es ansonsten die Proxies umgehen würde. Und genauso wäre wieder Fingerprinting-mäßig, wenn man das öffentliche IP, wenn das Zoom-Protokoll nicht noch weiter editiert ist, mit rausgeben. Was wir alle schon viel früher, als ich es gehofft hab, festgestellt haben, Automizifizierung der Piers ist nicht so einfach. Kann man sich nie hundertprozentig sicher sein und man muss natürlich komplettes Vertrauen in den Website-Code haben. Aber grundsätzlich, ich hoffe, es ist dabei auch umgekommen, dass, solange man nicht komplett ein Palaver-Surfer auf seinen eigenen Surfer aufsetzen kann und das nutzen kann, wenn man das soweit alles unter Kontrolle hat und nicht komplett, als er das komplette Paranoia-Protokoll fährt, dann kann man sich schon hinreichend aufsetzen, wenn man das so weit unter Kontrolle hat und nicht komplett, als er das komplette Paranoia-Protokoll fährt, dann kann man sich schon hinreichend darauf verlassen und das in gewissen Szenarien einsetzen. Und ich hoffe, ich konnte auch am Anfang ein bisschen Freude auf das, was man mit WebTC in Zukunft machen kann, noch vermitteln, dass man ein bisschen kreativerer einen Umgang noch mit dem Website machen kann. Und ansonsten bin ich jetzt noch offen für Fragen und hier sind noch meine Kontaktdaten. Die Slides sind auch offen und ich bin glückbar inklusive Source-Code und ansonsten schon mal vielen Dank für die Aufmerksamkeit. Ich habe mal noch eine Frage. Ja, die dritte ganze Zeit erdenken, das ist ja bei Freemason bei mir. Das ist ja auch, das ist ja auch, habe ich WebTV, das ist noch hier, das heißt, ich habe die kurzen Dingerfrills angezeigt, man kann die über 20 Millionen Abfragen oder so, die Altenliste, ist das denn bei WebTC nicht so wichtig, denn das Abfragen und die kurzen Zeiten, die mit dir zu lassen, das ist ja nicht so wichtig. Ich frage dir, was ist das denn bei WebTC? Also das, also das Ding ist, das wurde ich auch schon letztens, als ich auf der Interfugen Chemnitz war, wurde ich das Gleiche gefragt, habe mich leider in diesen 10 Sekunden nicht darüber nachgedacht, da hat nicht sofort die Lösung gefunden, der letzte Punkt, Vertrauen in Website-Code. Denn wenn ich jetzt sage, ich hau jetzt über den gleichen Kanal, sage ich jetzt zum einen, hier, der Fingerprint sollte in Wirklichkeit aus Sicht des anderen, das sein und ich zeige einfach das an. Du weißt halt nicht, was der Ja-was-Kriptcode macht, solange du den nicht jedes Mal, wenn du ihn lädst, reviewsst. Also wenn du der Website vertraust, dann kannst du hoffentlich auch dem Cycling-Surfer vertrauen, die die Website genutzt wird. Wenn du deine eigene Website, deinen eigenen Cycling-Surfer betreibst, dann ist alles egal. Also dann können wir die Szenarien egal sein. Gibt es leider derzeit nicht, also das wäre an sich die Lösung, das ist auch was, worüber ich schon nachgedacht hab, was man sozusagen Plug-in schreibt, was dann auf die internen Daten zugreift. Also das wäre eine Möglichkeit, das zu machen. Wobei dann wieder die Zuordnungen zu den einzelnen Piers, sozusagen wenn man in einem Multi-User-Chat ist, dann ist da eine Liste hier, mit diesen Leuten bist du gerade im Raum, ist vielleicht auch nicht optimal, aber es wäre die einzige Möglichkeit, dass man sozusagen ohne den Website-Code vertrauen zu müssen, da irgendwie rankommt. Das wäre etwas, was man machen könnte. Da hinten, oder war das schon weg? Also ja, das ist eben immer, am Ende läuft es darauf hinaus, irgendwie muss es angezeigt werden. Du brauchst irgendwas außerhalb des Websites-Codes, dem du dann vertrauen kannst. Das Problem, also, ich hab anderthalb Antworten oder so drauf, also was ich optimal finde oder so, wo, wenn Jamin Kellermann vor Jahren da schon mal hier einen Talk gehalten hat mit, es wäre richtig cool, wenn man Javascript haschen könnte und dann einfach sagen kann, ich vertraue diesem Stand von dem Javascript und immer wenn ich wiederkomme, sehe ich, das ist noch der gleiche Code. Mir wäre nichts, mir wäre nichts bekannt, dass man eben das für den User transparent machen kann. Also, dass man sagen kann, deshalb der User sich darauf verlassen kann, dass es immer wieder, wenn er wiederkommt, das Gleiche ist und wenn es was anderes ist, dass er dann notifiat wird. Das wäre was Cooles. Und die andere Hälfte kurz noch, wenn man sich die Datei einfach speichert, hat man das Problem, dass mindestens Chrome der Meinung ist, dass wenn man eine ... dass das nicht Web-ATC-würdig ist, dann gibt dir dir kein Get-User-Media, dann bekommst du überhaupt keine ... ... überhaupt keine Videodaten von dir, dann musst du dir noch einen kleinen Web-Surfer starten, lokal. Ja? Also bischen in der Richtung, wo das liegt, wenn du hier hast, dann ... ... da gibt es speziell zwei Apps, also die Teilfotsage ist eine Produktion von Apps, das hat einen Comic-Mob, wo du sagst, was du in der Web-Seite ... ... das ist eigentlich sowas in der Richtung, ich weiß nicht, wiebei ich das zertifiziere, ich weiß nicht, wie ich das zertifiziere, ich weiß nicht, wie ich das zertifiziere, ich weiß nicht, wie ich das zertifiziere, ich weiß nicht ... ... also das geht ja in gewisser Weise auch in Richtung dieses Buttons von Firefox, dass man das da integriert, ja, also das wäre definitiv ein Weg, den man da gehen könnte, dass man das soweit integrierten, den Browser und dass man da ... ... auf diesem Stand der App dann sich sicher sein kann, dass es sicher ist, ja. Also es gibt einige Möglichkeiten, das so lokal für sich zu regeln, aber ich denke, das Einfachste ist, wenn man sich jemanden besorgt, den man vertraut oder selbst für seine Community, die Person ist, der man vertraut und sich da ... ... genauso wie man lokalen Email-Surfer aufsetzt, sich dann lokal so ein Web-ATC-Videokonferenz surfer aufsetzt und danach nie wieder Skype anfassen muss, also das wäre der Weg, den ich, glaube ich, gehen würde, ja. Also da bin ich grad nicht 100% auf der Höhe, also weiß ich jetzt nicht genau, wie es ist, können wir nochmal genauer gucken. Und weil wir noch einen Hinterdeck, das ist einfach noch, ich glaube, das ist nur ein Hinterdeck, ja, kannst du das einfach sehen? Ja. Also es gibt auch noch einen Hinterdeck, das ist so was, der war auch veröffentlicht auf der Seite. Also da, muss ich sagen, habe ich bisher noch gar nicht so groß dran gedacht, dass man das da ja auch im Betten könnte, ja. Ja, ich möchte sagen, wir haben ein bestimmtes Anlassfenster und wir können irgendwie ein Intervindern und so, aber ich möchte das auch einseitbar. Ja, also da Cross-Site-Scripting ist da nochmal was Interessantes, ja. Gut, noch mehr Fragen, da hinten ist noch. Eine ganz spezielle Frage ist, wenn man jetzt kein Pausen hat, aber was sind denn da die zähle Krisen, z.B. hohes Datenschwellen? Ja. Oder, also bei mir ist es speziell, nach die ganze Umgebung, wo ich gerne bauen würde, ich habe eine Datenschelle, die ist mal denkbar, ein Rutschees, oder nur, jetzt muss groß immer was und die schickt ein Bild raus und vielleicht noch ein Datenschelle mit. Das wäre so, guck, um das eine Pause anbieten kann. Bei einer Pause ist heutzutage so die moderne Grün, jeder, der eine ganz schnelle Grün für irgendwas hat und man sagt, man hat eine Pause, aber da geht das mal rein. Also grundsätzlich, man muss halt irgendwie das alles, die rechte Seite davon, alles implementieren. Also es gibt gewisse Ansätze, also es gibt einen Ansatz, der hat den Firefox ausgehöhlt, hat alles Grün und so weiter rausgenommen und ist dann eine Note Plug in. Also das ist teilweise von 2013 meine Information, ich habe da schon ein bisschen nicht mehr gesucht, die letzte Zeit. Und ich bin der Meinung, es gab auch mindestens ein Projekt, was versucht hat, noch mal Native nachzuschreiben, PeerConnection und so weiter. Also da, ich persönlich bin bis zu der SRTP-Ebene schon hochgekommen und habe den Echo Surfer geschrieben. Also ist auch auf GitHub, auf unserem GitHub Account, wenn du da irgendwie vielleicht mit klar kommst, da müsste man dann nur noch das SRTP befüllen, eventuell, und das SCTP machen. Also da wäre man schon ein bisschen weiter. Aber... Also das Krasse daran ist halt auch immer dieses, was für mich am nervigsten war, war wirklich dieses SRTP-Parsen und so. Und da sinnvoll drauf reagieren. Also das wird da die größte Herausforderung sein, wenn mir irgendwie eine Mail schreibt oder so, so kann ich noch mal gucken, ob ich Zeug wiederfinde oder einordnen kann, was da sinnvoll wäre. Also... Da kann man noch mal irgendwie gucken, ob man da was Sinnvolles findet. Okay, wenn dann keine weiteren Fragen sind, dann würde ich für den nächsten Vortranken hier den Platz räumen. Dann noch mal vielen Dank für die Aufmerksamkeit.