Music. Willkommen liebe Hörerinnen und Hörer zum Podcast Dicke Bretter. Wir haben heute einen Gast, auf den wir uns schon sehr freuen. Aber bevor wir den vorstellen, werden wir ein paar Sätze sagen zu dem Konzept von Dicke Bretter, falls jemand von euch diesen Podcast noch nie gehört hat, was wir nicht hoffen.
Wir wollen ein bisschen erklären, wie Gesetzgebung, Regeln, Standards zustande kommen, wie auch die Diskussionen darum verlaufen, Welche Institutionen daran mitwirken und dafür haben wir immer so einzelne Beispiele und dieses Mal war es glaube ich ein bisschen überraschender als bei den letzten Podcasts, weil wir uns über Protokolle und Standards unterhalten wollen, aber dazu gleich mehr.
Zunächst sagen wir mal, dass wir im August 2023 sind. Falls ihr das hört, irgendwann 2090 oder so, dann wisst ihr, wann wir sind. Und wir sagen, wer wir sind, bevor wir unseren Gast vorstellen, nämlich... Ich bin Elisa Lindinger, hallo. Hallo und ich bin Constanze Kurz. Heute fehlt jemand von unserem Dreierteam, aber dafür haben wir einen tollen Gast. Das ist nämlich Raphael Robert, von dem wir schon gehört haben, dass er französische Wurzeln hat.
Und jetzt sagt mal erstmal was, damit wir wissen, ob das Mikrofon funktioniert. Ich hoffe doch. Gut. Einwandfrei. Ja, wir freuen uns besonders, dass du da bist, weil du sozusagen uns etwas vorstellen wirst, nämlich eigentlich zweierlei eine Institution und aber auch einen bestimmten technischen Standard. Und wir in diesem Prozess möglichst lernen wollen, wie entsteht der eigentlich,
Warum engagiert man sich da? Wie kommt man zu einem Ergebnis? Und vielleicht auch, wie gerät man da rein? Das ist so ungefähr, worüber wir so sprechen wollen. Und wir freuen uns natürlich auch deswegen, weil du an einem Standard mitwirkst, der potenziell Milliarden Menschen betreffen wird und auch eine gewisse politische Relevanz hat. Also im Prinzip die Essenz von dem, was wir hier gerne machen. Absolut.
Genau. Und am Anfang, klar, wollen wir ein paar Sachen wissen über dich. Sag doch mal, was machst du eigentlich so? Ja, ich bin auch beruflich eigentlich genau da beheimatet, also sicheres Messaging, Wahrung der Privatsphäre in dem Bereich. Ich war früher viele Jahre lang für die Sicherheit zuständig bei dem Messenger Wire, den vielleicht einige
kennen. Seit etwas über zwei Jahren bin ich jetzt bei Phoenix R&D. Das ist eine kleine Firma, die ich leite und wir haben uns eigentlich der Forschung und der Entwicklungen verschrieben, genau in dem Bereich. Also Ende-zu-Ende-Verschlüsselung. Minimierung von Metadaten, alles im Bereich Messaging. Und da wir ja heute niemanden überfordert wollen, wir versuchen Fachbegriffe zu vermeiden. Metadaten sind typischerweise die Verkehrsdaten der Kommunikation.
Wer mit wem und wann in der Regel, die sehr gut auswertbar sind. Und vielleicht noch ein Satz zu Wire. Wire ist ein Messenger und der ist sehr beliebt im im US-amerikanischen Raum, habe ich auch zahlenmäßig mal gesehen in Europa, aber nicht so verbreitet. Stimmt nicht? Korrigiert mich. Das müssen wir nochmal recherchieren, glaube ich. Wir fordern einfach mal unsere Hörerinnen und Hörer auf, das nochmal uns in den Comments als Infopunkt darzulassen.
Genau, gute Idee. Ich weiß jetzt so ein bisschen von der Hacker-Community, aber das ist vielleicht auch ein bisschen outdated, denn Messenger-Konzepten... Genau, ich meine, da kann man vielleicht einen kurzen Abriss machen.
Das ist ein Messenger, der durch viele Phasen gegangen ist, der anfangs so ein allgemein tauglicher Messenger war, sich dann umorientiert hat hin zu einem sicheren Messenger, insbesondere eben für Verbraucher, und dann noch mal einen Schwank gemacht hat und sich eigentlich mehr auf Firmen konzentriert. Okay, und was bist du von deiner Ausbildung her? Studiert habe ich Physik, aber in dem Bereich habe ich nie gearbeitet und bin dann relativ schnell...
Eigentlich zu meiner Leidenschaft gekommen. Okay, aber wir haben ja schon... Versendling oder Verschlüsselung? Das war weder noch damals. Wir haben das ja schon häufiger mal gehört. Physiker haben eine sehr mathematik-lastige Ausbildung und in der Regel kommen sie früh mit Programmieren in Kontakt. Und insofern ist man ja vielleicht zu dieser Technik-Community immer relativ nah, oder? Genau, ja. Also das war in meinem Fall das Programmieren tatsächlich damals.
Da bin ich ja auch wieder hin und zurück gekommen und bereue es auch nicht. Das ist schön zu hören. Nun ist es so, du hast es schon erwähnt. Unser eigentliches Thema inhaltlich ist das Messaging, ich weiß gar nicht, gibt es ein ordentliches deutsches Wort dafür? Messaging klingt ja nun auch nicht gerade so geil. Nachrichtendienst ist auch nicht das richtige Wort. Die Übermittlung von Nachrichten in ansehnlichen Apps, die man in der Regel auf Smartphones hat, aber nicht nur.
Und darüber wollen wir heute inhaltlich reden, aber auch über die Institution, die diese sogenannten RFCs, also Request for Comments, hervorbringt. Also ein großes Thema, aber eigentlich gar nicht so schlimm, haben wir im Vorgespräch schon gelernt. Genau. Soll ich nochmal weiter? Ich frag mal weiter. Wie bist du dazu gekommen, dich irgendwie mit Standards und wie sie zustande kommen zu beschäftigen und dann auch noch so reingeraten, dass du jetzt einer der Autoren eines solchen Standards bist?
Ja, in Teilen war es sicherlich auch Zufall. Also das war jetzt nicht etwas, was minutiös geplant war. Manchmal landet man halt irgendwo und in dem Fall war das halt deswegen so, weil sich die Frage stellte im Messaging-Bereich brauchen wir nicht überhaupt einen Standard, um Ende-zu-Ende-Verschlüsselung zu ermöglichen. Aber es gibt ja bereits Messenger, die Ende-zu-Ende-Verschlüsseln. Genau. Die Messenger gab es und die Technologie gab es eben auch, in Teilen zumindest.
Es gab aber diesen Standard nicht. Und das haben einige Leute so gesehen, die dann so circa 2016, 17 angefangen haben, darüber, darüber zu sprechen und überhaupt nach Lösungen zu schauen, und auch ein bisschen zu verstehen, was sind eigentlich noch die Probleme, die wir da lösen wollen. Ist das, was wir jetzt haben, schon gut genug? Oder brauchen wir da noch andere Dinge?
Zu dem Zeitpunkt gab es verschiedene Protokolle. Sicherlich das Signalprotokoll, oder das, was man heute als Signalprotokoll kennt. Damals hieß das Axolotl oder Double Ratchet. Es gab andere noch. Davor gab es das Off-the-Record-Protokoll, OTR. Es war sogar ziemlich breit benutzt, zumindest erinnere ich mich daran. Genau, in manchen Kreisen wurde das sehr stark benutzt. Das ist die Jabber-XMPP-Fraktion.
Genau, es hat aber nie so wirklich diese Massentauglichkeit erreicht damals und der Grund dafür war eigentlich ganz einfach. Das war ein exzellentes Protokoll, in vielen Hinsichten hatte sehr viele moderne Sicherheitseigenschaften.
Das klingt jetzt ein bisschen speziell, aber was ich damit meine, ist, es war ein relativ modernes Protokoll, hatte aber einen gravierenden Nachteil und das war für eine Art der Kommunikation gebaut, wie man sie von Skype kannte damals, wenn ihr euch erinnert, da mussten beide Seiten gleichzeitig online sein, damit eine Nachricht überhaupt durchging.
Da ging es also nicht, dass eine Seite, die dann verschickt hat, offline gegangen ist und dann sehr viel später die andere Seite online gegangen ist. Also das ist, was man heute unter dem Begriff asynchrones Messaging kennt. Warte mal, ich will nochmal zu dem Anfang zurück. sagst, das war so 2015, 2016 rum, das war aber auch genau die Zeit, wo Messaging ziemlich explodiert ist, einfach von Nutzerzahlen und den verschiedenen Anbietern, die es so gab, korrekt?
Ja, genau. In den Jahren davor gab es so eine Art Transition zwischen dem Messaging, was eigentlich zwischen Desktop-Computern stattfand, und auf einmal aber auf Smartphones stattfand, weil das vorher halt technisch nicht wirklich ging, also das Internet auf Smartphones war halt nicht besonders gut. Es gab keine Apps auf den Smartphones, die durchgängig verfügbar waren.
Und deswegen hat sich eigentlich eine völlig neue Art von asynchronen Messaging etabliert, als Ersatz für das, was man von SMS eigentlich kannte. Es war deswegen auch so erfolgreich, weil es halt meistens kostenlos war oder deutlich günstiger als SMS.
Jetzt hast du so ein paar Defizite angesprochen, die du bei Off the Record war ein Beispiel oder auch bei dem Signal-Protokoll, weil damals so anders hieß, genannt hast, diese Defizite oder kannst du sie erklären, ohne dass man großartig technisches Vorwissen haben muss? Vor allen Dingen, was die Komplexität angeht. Könntest du drunter brechen?
Genau, bei dem Off-the-Record-Protokoll war das Defizit eigentlich im Wesentlichen die Tatsache, dass man dieses asynchrone Messaging auf Smartphones damit nicht machen konnte. Das war es eigentlich. Und das ist das, was das Single-Protokoll dann aufgegriffen hat, und hat daraus eine asynchrone Version gemacht, die dann eben deutlich geeigneter war für Smartphones. Und das ist eigentlich schon das Ende der Geschichte an der Stelle. Das ist, was das Signal-Protokoll eben so populär gemacht hat,
weil das auf einmal überall eingesetzt werden konnte. Also in Signal selbst, aber es wurde eben auch von anderen Ländern nachher verwendet. Es gab noch andere, die halt nie so populär geworden sind, Wie z.B. Wicca, erinnert ihr euch vielleicht an den Messnetter, den gibt es, glaube ich, theoretisch gerade immer noch, aber die wollen den nicht weiter betreiben für Verbraucher. Ohne E schreibt sich das. Ohne E, genau.
Ist US-amerikanisch, wurde aufgekauft von Amazon, ich glaube, vor zwei Jahren ungefähr. Und, naja, die hatten ein eigenes Protokoll, was auch sehr gut war, aber was nie sehr weite Verbreitung gefunden hat eigentlich. Die eigentliche Frage war aber, wie bist du dahin geraten? Genau, ich war ja nun mal im Messing Space unterwegs, weil ich bei WIRE war damals. Und da hat man sich eben auch mit der Frage beschäftigt, was will man da machen.
Und da kamen halt mehrere Leute zusammen, eben auch aus der Forschung. Da gab es ein prominentes Paper, das nannte sich End-to-End-Encryption, also plural. Und da wurde ein Konzept vorgestellt, das sich ART nannte, Asynchronous Ratcheting Trees. Das ist jetzt sehr technisch, aber das war ein Vorschlag, wie man in größeren Gruppen sehr viel effizienter Ende-zu-Ende Verschlüsselung machen kann.
Das war technisch neu in dem Sinne, weil Ende-zu-Ende Verschlüsselung immer mit gewissen Kosten einhergeht, gerade was Gruppenkommunikation angeht, wo man dann typischerweise für jeden Teilnehmer in der Gruppe dann individuell nochmal die Nachrichten verschlüsseln musste. Das war dann da auf einmal nicht mehr der Fall und trotzdem war die Sicherheit gut.
Und das war so ein bisschen der Auslöser. Das ist letztlich nicht das, was in der MLS gelandet ist, aber das hat die Debatte aus akademischer Sicht so ein bisschen losgetreten. Kannst du noch sagen, was dann bei euch so ein bisschen die Entscheidung real hat werden lassen oder dazu geführt hat, das wirklich jetzt auch in der Standardisierung einzubringen? Gab's das, ihr seid alle zusammen und habt gedacht, so jetzt sitzen wir hier beim BIO und machen das einfach mal? Oder wie war das?
Genau, also das ist so ein bisschen am Rande von verschiedenen ITFs besprochen worden. Und naja, ich glaube, der Auslöser war letztlich, dass was so der technologische de facto Standard war, also das Signalprotokoll damals, dass es einfach nicht wirklich verfügbar war. Also es gab keine vollständige Spezifizierung davon. Das heißt, man konnte jetzt nicht irgendein Dokument lesen und das selber nachimplementieren. Und ferner gab es eben auch keine Implementierung unter einer permissiven Lizenz.
Das heißt, wer das verwenden wollte, musste das sehr kommerziell von Signal lizenzieren. Das haben Firmen auch gemacht. Die Großen haben das eben gemacht. Facebook hat das gemacht. Skype hat das gemacht. Google hat das gemacht. Aber das war halt erst mal eine Hürde für die Verbreitung von Ende zu Ende. Du hast den Begriff jetzt erst einmal genannt, wir müssen ihn erklären. Die IETF erwähnen. Wir haben noch nicht gesagt, wo der Standard entstehen sollte.
Das ist nämlich durchaus nicht die einzige Standardisierungsorganisation. Aber sag doch mal dazu, warum dort. Und was ist die eigentlich? Genau, was macht ihr da eigentlich? Also offenkundig bist du kein Ingenieur im engeren Sinne, aber man kann sich da einbringen, auch wenn man kein Ingenieur im Wortsinn ist. Also um es vielleicht einmal kurz auszusprechen. IETF steht, das ist die englische Abkürzung, für die Internet Engineering Task Force. Deswegen auch die Frage nach dem Ingenieur gerade.
Genau, im weiteren Sinne betreiben wir ja Engineering, also so nennt man ja die Entwicklung und das Programmieren mittlerweile auch. Ja, das stimmt. Genau, also das ist eine Organisation, das ist eben eine Standardisierungsorganisation, die gibt es schon seit einer ganzen Weile.
Und ich glaube seit den 80er Jahren hat das angefangen. Es ging damals um das Internet, also darum, dass wenn man auf einmal mehr Netzwerke zusammenschließt, muss man sich eben auf Standards einigen und da kann man halt nicht jeder so sein Süppchen kochen und darauf hoffen, dass das nachher funktioniert. Also da muss man sich wirklich zusammenschließen und einen gewissen Konsens erreichen, was das angeht.
Und das hat natürlich in den Jahrzehnten danach Fahrt aufgenommen, genau wie das Internet eben Fahrt aufgenommen hat. Und das ist eine Organisation, die in gewissen Bereichen Standards setzen will, nämlich dem offenen Internet sozusagen. Es gibt andere, das hast du ja schon angesprochen, die sind aber meistens deutlich restriktiver, was auch die Teilnahme angeht.
Welche willst du nennen? Also genau, die ITF hat den großen Vorteil, dass das zumindest theoretisch eine sehr offene Organisation ist, wo man als Individuum eigentlich mitmacht und nicht als Firma zum Beispiel. Und du bist natürlich auch nicht angestellt, sondern das ist eine Form von Engagement, würde ich es mal nennen. Mhm, das ist eine gute Wortwahl. Da wird sehr viel aus einer inneren Überzeugung auch gemacht. Die Leute, die da mitmachen, machen viel davon in ihrer Freizeit tatsächlich.
Das sind oftmals Leute, aber eben nicht nur, die bei großen Firmen arbeiten. Die das zu einem gewissen Grad eben auch sponsoren, indem die ihren Mitarbeitern ermöglichen, da hinreisen zu können, Reisekosten tragen und so weiter.
Das in ihrer Arbeitszeit machen lassen, aber selbst bei den sehr großen Firmen, die sich das sehr locker leisten können, ist es trotzdem so, dass die Leute in ihrer Freizeit das auch mitmachen, weil die das mehr aus diesem Engagement raus machen, und das weniger als Job sehen insgesamt.
Also bist du da eher die Ausnahme? Du gehörst jetzt nicht zu einem riesen Konzern, aber von den am Ende sechs Autoren, zu dem Standard kommen wir ja nochmal genau, da sind wir noch nicht ganz so genau drauf gekommen, aber da sind ja nun die Mehrzahl ist von großen... Konzerten kann man schon sagen bezahlt. Du bist ja eher die Ausnahme. Genau, zumindest mittlerweile. Als es anfing, waren noch einige bei Forschungseinrichtungen
und Universitäten und sind dann später zu den Konzernen gewechselt. Zwei davon konkret. Das heißt, in dem Rahmen war ich vielleicht ein bisschen die Ausnahme. Aber es gibt auch andere Arbeitsgruppen, wo auch Studierende mitmachen können. Also es ist überhaupt nicht so, dass man eine sogenannte Affiliation haben muss, also eine Zugehörigkeit zu einer Firma.
Man kann da also auch wirklich ganz persönlich hingehen und da mitmachen, insofern man halt irgendeine Kompetenz vorzuweisen hat, die dazu passt natürlich. Oder auch ohne, würde ich mal sagen. Ich war da nämlich auch schon und meine Kompetenz kann man vielleicht in Frage stellen. Aber tatsächlich, das ist, wenn die Reisemittel und die Kosten für die Teilnahme vorhanden ist das erstmal allen offen. Und auch eine Online-Teilnahme war schon vor der
Pandemie quasi immer vorgesehen. Da war das tatsächlich total früh dabei und hat sich, soweit ich das gesehen habe, in der Pandemie auch noch mal verstetigt und ausgebaut, was natürlich die Zugangshürden auch echt noch mal abbaut. Also insofern ist das schon ein sehr besonderes Umfeld, finde ich. Auch für jetzt Leute, die vielleicht nicht aus dem Westen sind, sondern aus anderen, Kontinenten, die lange Reisewege hätten. Oder Visa-Probleme, all diese Geschichten.
Genau, also das ist natürlich eine ständige Diskussion, die auch gerade jetzt nochmal geführt wird. Für die Konferenzen, die abgehalten werden, wo werden die abgehalten und so weiter. Wer kann dann kommen, für wen ist das ein Problem? Kannst du noch was zu der Struktur sagen? Also ihr gehört zu SEC, was Security ist. Gibt's, oder kannst du sagen, wie viel verschiedene Abteilungen es da so gibt? Ich weiß tatsächlich die Zahlen nicht. Aber eine Menge, oder?
Es gibt mehrere, ja, und die haben auch unterschiedliche Größen. Also das sind Areas, um das mal im englischen Jargon zu sagen, und die haben da so einen Area Director, der dann dafür zuständig ist. Und die einzelnen Areas unterteilen sich dann wiederum in Arbeitsgruppen, also Working Groups. Und Working Groups, die haben sogenannte Chairs, die die Working Groups dann eben anführen. Und im Wesentlichen aufpassen, dass die Regeln eingehalten werden.
Zusehen, dass ein gewisser Fortschritt gemacht wird. Sich aber typischerweise nicht beteiligen an der tatsächlichen Arbeit in den Arbeitsgruppen. Könnten Sie wahrscheinlich auch nicht, ne? Also einfach von der Menge her, oder? Hin und wieder kommt es mal vor, aber dann müssen die ganz klar ihre Rollen auch trennen. Ich spreche jetzt nicht als Chair, sondern ich spreche jetzt als Autor von einem Dokumenten zum Beispiel. Ihr habt einen relativ bekannten Chair, ne?
Wir haben bei MLS zwei Chairs. Nick Sullivan, der bei Cloudflare, ich glaube sein Titel war Head of Crypto, mich recht erinnert war. Der ist da glaube ich auch nicht mehr. Und Sean Turner, der, der zweite Chair war und der im Alltag deutlich aktiver auch war und die Meetings mitgestaltet hat. Na dann sag doch mal den Alltag, obwohl du schon den Alltag ansprichst. Wie leistet der nun im Alltag? Genau, also es gibt eben verschiedene Formen, wie man sich da einbringen kann.
Aber vielleicht nochmal ganz kurz zurück zu den Arbeitsgruppen. Also die müssen natürlich erst mal zustande kommen. Es gibt halt diese Areas, die sind relativ fix und innerhalb der Areas gibt es halt Arbeitsgruppen und da müssen sich erst mal genügend Leute zusammenfinden und ein Thema ganz klar benennen und das auch umreißen können und dafür gibt es auch einen Prozess, also es gibt für alles einen Prozess bei der IETF.
Prozess, der nennt sich BOF, das ist die Abkürzung und das steht auf Englisch für Birds of a Feather und das kommt aus dem Satz Birds of a Feather flock together. Das heißt Leute, die sich ähnlich sind oder die ähnliche Gedanken haben, die finden dann zueinander. In einem Schwarm. In einem Schwarm, ja.
Genau und naja, also transponiert die Idee dahinter ist halt bei der RTF, dass dass Gleichgesinnte sich da zusammenfinden und dann diskutieren, welches Problem die eigentlich bewältigen wollen und wie.
Und dann gibt es ein wichtiges Dokument, bevor eine Arbeitsgruppe entsteht, das nennt sich Charter, also eine Charter, in der dann drinsteht, worum es eigentlich geht, was dazugehört, also welches Problem man bearbeiten will, aber auch ganz konkret, was man nicht bearbeiten will, dann reingehören soll, dass man das abgrenzen kann. Problemauffriss, würde ich das mal so beschreiben. Das ist auch öffentlich, das ist im Prinzip komplett transparent.
Sehr guter Punkt. Alles ist komplett öffentlich. Also diese Dokumente sind öffentlich, die Meetings werden in aller Öffentlichkeit abgehalten, Mailinglisten sind immer öffentlich, von Natur aus schon. Und das ist das Schöne daran, man kann das halt immer nachlesen, immer nachvollziehen, diskutiert wurde, wie Entscheidungen dann auch getroffen wurden und kann auch jederzeit Einwände
äußern. Also zurück zu dem Entstehungsprozess. Da wird halt erstmal so eine Charta definiert, dann wird eben geguckt, in welche Area würde das überhaupt passen und da wird einem dann so ein bisschen geholfen von den Veteranen, die das halt schon öfters gemacht haben. Das sind schöne Worte, die sind teilweise 20 oder 25 Jahre alt. Ja, genau, es gibt da so Urgesteine. Haudegen ist das Wort, glaube ich. Und irgendwann, so ein Boff kann mehrfach stattfinden.
Ist am Anfang vielleicht auch gar nicht so offiziell, aber irgendwann gibt es einen Working Group Forming Buff und das ist dann der, idealerweise der letzte in der Reihe und da wird halt eine Charter vorgestellt. Und dann braucht man halt Konsens von allen Leuten, die dann im Raum sind, also das muss auch vorher angekündigt werden, dass jeder eine Chance hat, da hinzukommen.
So und wenn dann Konsens besteht, dass die Charter in Ordnung ist und dass das Problem relevant ist, dass das auch in die Area passt und so weiter, also es gibt so ein bisschen Kriterien, Dann entsteht formal so eine Arbeitsgruppe und dann wird geschaut, wer da das Chairing machen will. Und ab dem Moment hat die dann Chairs und dann muss auch vorgelegt werden, welche Arbeitsdokumente diese Arbeitsgruppe erstellen soll.
Also das kann sich natürlich noch ändern, aber man muss mit einem konkreten Vorschlag da reingehen. Und man muss sich ab dann an diese Charter halten. Also Chair, wir wollen ja keine Fachbegriffe, der Chairs sozusagen, der, würde man sagen, Vorsitzende. Das sind die Vorsitzenden, genau. Du hast ja schon vorhin die Aufgabe umrissen. Wir wollen ja nur... Guter Punkt. Genau, und ab dann kann man im Rahmen dieser Charter aktiv werden, bei den Dokumenten.
Und dann gibt es, das haben wir ja schon erwähnt, dreimal im Jahr trifft man sich in Person im Turnus, also meistens aus Nordamerika, Europa und Asien, wenn nicht gerade Pandemie ist. Und zwischendrin kann es noch Interim-Meetings geben. Die sind dann spezifisch für eine Arbeitsgruppe. Und die müssen, ich glaube, ein bis zwei Wochen vorher angekündigt werden. Oh, das ist Short Notice sozusagen, kurzfristig. Das ist relativ kurzfristig.
Ui. Man kann dann auch wieder online mitmachen oder das passiert irgendwo vor Ort, das hängt vom Meeting halt ab. Das kann man dann entscheiden. Da sind die Formalitäten nicht mehr ganz so hoch, es muss aber trotzdem alles nur öffentlich und transparent sein. Die werden auch meistens aufgezeichnet. Und da passiert meistens die eigentliche Arbeit, weil da ist man im kleineren Kreise und da kann man sich dann auch mal über Dinge streiten in Person.
Wohingegen bei diesen drei Terminen im Jahr, da versucht man eher so ein bisschen zu zeigen, was man eigentlich erreicht hat. Da sind dann wesentlich mehr Leute mit im Raum, die dann auch manchmal Fragen stellen, die dann nicht so ganz dazu passen. Und im ITF-Jargon heißen die so ein bisschen despektierlich Touristen manchmal, weil die
die halt nicht direkt dazugehören. Man muss dann oft wiederholen Dinge, die man eigentlich schon besprochen hat und erklären werden, wo man eigentlich weiterkommen will. Das gibt es bei anderen Standardisierungsgremien sicherlich auch. Was man braucht unbedingt ist Konsens. Also das ist ein ganz zentrales Element bei der IETF, man braucht Konsens. Es gibt diesen Ausdruck Rough Consensus and Running Code. Das ist nur ein Ausschnitt aus so einem etwas längeren Credo eigentlich.
Und da geht es eben darum, dass man nicht irgendwie ein Wahlsystem hat, wo Mehrheiten entscheiden, was jetzt gemacht wird, sondern wo man vielmehr schaut, dass man einen Konsens hinbekommt und insbesondere, wenn man halt Meinungen hat, die stark auseinander gehen, dass man das berücksichtigt in dem Moment. Aber ohne den Running Code. Ihr habt eine Spezifikation geschrieben, ihr habt keinen Running Code. Wir haben auch Running Code geschrieben. Aber nicht innerhalb des RFCs, oder?
Nee, das passiert immer außerhalb des RFCs. Also der Code gehört nicht dazu, ja. Stimmt, eine neue Abkürzung. Möchtest du sie gleich auflösen? Nee, nee, bin ich hier der Experte, also genau. Rausgekörpert ganz am Ende ist ein sogenannter RFC, jetzt im Mitte Juli, ne? Guter Punkt, ja. Den haben wir noch gar nicht jetzt im Stand der Diskussion. Bis dahin gibt es nur die Arbeitsgruppe und die hat wiederum Dokumente.
Die nennen sich auf Englisch Drafts. Und das sind also Arbeitsdokumente, die dann offiziell von der Arbeitsgruppe als solche bezeichnet werden. Also, da wird dann vorgeschlagen, da finden sich ein paar Autoren zusammen und sagen, okay, wir würden gerne einen Draft zu folgendem Thema machen und dann muss die Arbeitsgruppe diesen Draft dann quasi als Arbeitsdokument der Arbeitsgruppe annehmen auch. Also, jeder kann einen Draft anreichen zu jeder Zeit, der hat aber keine besondere Relevanz.
Der hat erst dann wirklich Relevanz, wenn die Arbeitsgruppe den für gut befindet. Der muss ja auch nicht fertig sein zu dem Zeitpunkt, sondern der muss im Kleineren auch wieder nur klar umrissen sein, was der eigentlich beschreibt und welches Problem der lösen will. Aber auch konsensual. Das muss, alles ist konsensbasiert in dem Moment.
Aber der eigentliche, also sozusagen das Endergebnis, der ist ja nicht statisch, sondern der heißt ja schon so, Request for Compensate, auf Deutsch so viel heißt wie, ey, gib mal Kommentare ab. Warum heißt der so? Das ist ein guter Punkt. Also der Name passt eigentlich nicht ganz dazu, weil der ist eigentlich statisch. Also der ist wirklich in Stein gemeißelt in dem Moment.
Also diese Drafts, um nochmal kurz darauf zurückzukommen, die haben halt erstmal so einen gewissen Lebenszyklus, bis die so einen Reifegrad erreichen, wo die dann eben vorgeschlagen werden für die Standardisierung. Und ab dem Zeitpunkt wird es dann so ein bisschen formaler. Also bis dahin haben die Leute relativ inoffiziell einfach daran rumgeschnitzt, an dem Dokument.
In dem Moment gibt es dann einen sogenannten Last Call von der Working Group, da hat man nochmal zwei Wochen Zeit oder meinetwegen auch mal länger, wenn man sich da einig ist, wo jeder seinen Senf nochmal dazu abgeben kann und später wird das Dokument dann an ein weiteres Gremium weitergereicht, das nennt sich Steering Group, IESG, Internet Engineering Steering Group und das besteht dann aus ganz anderen Leuten, die mit der Arbeitsgruppe
nichts zu tun haben. Die begutachten das dann und wenn das wiederum sämtliche formalen Kriterien erfüllt, also und bis dahin kann aber immer noch jeder ganz, öffentlich auf der Mailingliste oder sonst wo Anspruch erheben. Das ist eigentlich ein klassischer akademischer Reviewing-Prozess. Also wie man es in der Wissenschaft kennt, gucken andere Experten, die nicht direkt damit zu tun haben, drüber und können aber auch einen Feedback-Kanal zu euch, korrekt beschrieben.
Ja, es ist so eine Art Peer Review, wobei die Kriterien auch nochmal so ein bisschen anders sind in dem Moment. Es passiert vorher schon so ein bisschen Peer Review innerhalb der Arbeitsgruppe, idealerweise. Aber das ist dann wirklich nochmal ein getrenntes Gremium. Und wenn das soweit ist, die Hürde ist dann schon deutlich höher, also da muss das Dokument eine gewisse Relevanz haben, eine gewisse Reife und so weiter.
Und dann im allerletzten Schritt geht das zu dem sogenannten RFC Editor, Und da kommt das RFC jetzt überhaupt zum ersten Mal ins Spiel. Das war früher mal über Jahre hinweg eine Person, mittlerweile sind das mehrere. Und die verpassen im Dokument nochmal so den letzten Feinschliff, was das Sprachliche angeht.
Da das halt von oftmals mehreren Autoren geschrieben wird, die auch unterschiedliche Englischkenntnisse haben, unterschiedlichen Stil und so weiter und sich nicht immer so formal präzise ausdrücken, wie es erforderlich wäre für so einen Standard, wird das alles nochmal unter die Lupe genommen und da werden dann Korrekturen vorgeschlagen und die Autoren können das dann nachher auch nochmal, die müssen das formal annehmen, diese Korrekturen.
Aha, das ist vielleicht ein guter Punkt, um ein paar RFC-Funfacts nochmal einzustreuen, denn das Ganze hat ja eine tolle, inzwischen echt wahnsinnige, geschichtliche Dimension. Und tatsächlich, wie du schon sagtest, die RFCs stehen ja zeitlich vor den ersten Treffen der Internet Engineering Task Force. Also der erste RFC ist von 1969 und vielleicht auch das Spannende, die sind so quasi aufsteigend einfach durchnummeriert. Also wir fangen am Anfang an. Manche sind auch nicht mehr dokumentiert.
Also ich glaube, manche können wir heute gar nicht mehr so richtig rekonstruieren, was da drin stand. Und auch total spannend, relativ schnell noch im einstelligen Bereich geht es dann wirklich darum, sich auch erstmal in diesen RFCs selber Regeln zu geben und dann bis hin, was du gerade sagtest, sogar die sprachlichen Feinheiten dort abzustimmen. Also es gibt RFCs, die nochmal definieren, was heißt eigentlich shall, also sollen oder könnten oder sollten.
Also wo genau nochmal abgegrenzt wird, was heißt dann dieses Wording eigentlich, was heißt diese Begrifflichkeit, wenn sie verwendet wird, um das eben auch nochmal referenzierbar und verständlich zu machen. Das erinnert an Juristen, oder? Also das ist total wie Verwaltungsdeutsch vielleicht auch. Und da sind wir ja natürlich auch im Policy-Bereich. Also ich glaube, die Parallelen drängen sich in dem Fall auf.
Genau, und vielleicht gibt es noch so dreistellige RFCs, die heute noch relevant sind, wie TCP oder UDP und so weiter. Aber weißt du, welche Nummer ihr habt? Weißt du es auswendig? Wir haben 9.420. Okay, da hat sich einiges getan seit den 700ern der beiden alten Protokolle. Naja gut, aber an den Nummern sieht man, es ist jetzt auch nicht so häufig, weil der Prozess lang ist. Du hast ihn ja, glaube ich, auch ziemlich verständlich beschrieben.
Ich finde, er wirkt heute, so wie du ihn jetzt beschreibst, schon relativ akademisch. Da ist die Hürde daran mitzuwirken, ist wahrscheinlich tatsächlich ein gewisses Kompetenzlevel, ne. Aber das ist natürlich auch gewünscht, denn die Menschen, die diesen RFC am Ende dann produzieren, aus ihren Gehörden, sollen natürlich auch möglichst wissen, worüber sie reden und eine gewisse Erfahrung haben mit dem Feld, nicht wahr?
Also das ist ja eben, warum ist der Name denn hier blieben, wenn man überhaupt nicht Kommentare anfordern will? Ich habe da jetzt auch keine Antwort drauf. Da müsstest du mal einen Boff gründen. Genau, das könnte man machen. Ja, soweit ich weiß, ist RFC auch nicht was, was jetzt spezifisch für die ITF ist. Das wird auch in anderen Gremien verwendet. Die haben sich den Begriff wahrscheinlich damals einfach nur geliehen und der ist geblieben halt, würde ich vermuten.
Aber also, wie du schon sagst, es ist relativ formalistisch natürlich, was das angeht. Aber das muss es auch sein, weil die Tragweite halt sehr groß ist. Ach, speaking of Tragweite.
Also das ist doch eigentlich ein Punkt. Nicht alle RFCs, also ihr habt ja sozusagen einen guten Teil des Weges fertig und wir können gleich noch über den Code reden, du hast gesagt, ihr habt den Zeitgleich rausgehauen, würdet ja nicht alle Spezifikationen machen, aber ein Guteil der RFCs, würde ich mal sagen, ist von nicht so hoher Relevanz für Milliarden Menschen. Bei euch ist es anders. Warum? Also reden wir doch mal über den Inhalt.
Gerne. Also klar, natürlich, das hängt total davon ab, in welchem Bereich man unterwegs ist. Hier in dem Fall ist es Messaging. Und Messaging macht man meistens zu mehreren, sonst ist es nicht so spaßig. Na ja, zwei, nicht? Also ist ja so eine untere Grenze, oder? Zwei ist eine untere Grenze, aber es ist selten der Fall, dass irgendjemand einen Messenger rausbringt, der nur für genau zwei Leute funktioniert. Also das Zielpublikum ist meistens relativ groß in dem Bereich und kann enorm skalieren.
Also wir wissen ja, wie groß Messenger werden können. Wenn man jetzt einen Teil der Technologie austauscht in so einem Messenger, dann betrifft das gleich die ganze Nutzerbasis. Wobei, als ihr angefangen habt, es gab kein Matrix, es gab kein Telegram, so diese neue, nicht nur unbedingt für den privaten oder beruflichen Austausch zu nehmen, sondern richtig große Gruppen zu bilden, war definitiv noch nicht da, oder? Als ihr angefangen habt.
Also doch, es gab sowohl Matrix wie Telegram 2018. Oh, dann sind die älter als ich dachte. Also gerade Telegram ist, glaube ich, mit einer der ältesten. Die sind schon seit 2000, ich will nicht die falsche Zahl sagen, aber 2012 gefühlt unterwegs. Und diese großen Gruppen, es geht also weniger darum, diese Telegram-ähnlichen Gruppen jetzt bedienen zu können, sondern überhaupt darum, Gruppen effizient bedienen zu können. Also auch mit Dutzenden Teilnehmern, bis hin zu Hunderten vielleicht.
Und warum ist das so wichtig? Der Grund dafür ist einfach der, dass eben die meisten Leute Messaging auf einem Smartphone verwenden. Smartphone hat nur eine Batterie und die geht schnell leer, wenn man es zu viel verwendet. Und da muss das Messaging dementsprechend effizient sein. Und der Status quo war vor MLS, dass man einfach die Wahl hatte, Entweder wir machen es sehr sicher, auch in Gruppen, aber dann geht es eben auf die Batterie und auf den Datenverbrauch.
Der Geld kosten kann und auch Geld kostet effektiv in vielen Fällen. Oder aber wir drehen die Sicherheit runter. Das war so die Stellschraube, die man hatte. Diesen Trade-off wolltest du nicht verstehen. Und das ist effektiv, was WhatsApp zum Beispiel gemacht hat. Gemacht hat. Die verwenden zwar das Signalprotokoll für 1 zu 1 Kommunikation, aber in Gruppen hat es einfach nicht mehr die gleichen Sicherheitseigenschaften. Und das war nicht so ein toller Trade-off.
Okay, aber jetzt muss ich nochmal auf diesen... Wie... Ich kann das total verstehen. Ich glaube, viele, die jetzt zuhören, werden auch verstehen können, nein, das ist kein guter Trade-off. Bei Trade-Off würde man übersetzen mit Abwägung. Keine gute, ja genau. Aber wie in aller Welt kommt man darauf, als einer von vielen Milliarden Personen sich hinzustellen und zu sagen, ey, da kümmere ich mich jetzt drum.
Da mache ich mich mal an Standardisieren. Das ist jetzt nicht unbedingt so naheliegend, oder? Naja, aber wie gesagt, das war ein bisschen so eine Gruppenbewegung. Also aus der akademischen Gemeinschaft kamen dann einiges an Vorschlägen, gerade um diese Effizienz zu bringen. Also das ist tatsächlich nicht was, was man eben so spontan unbedingt entsteht. Das muss man schon mal recherchieren. Und was eben aber aus der Firmenwelt kam, war eben diese Abwesenheit von einem Standard.
Also sämtliche Firmen, die im Messaging-Bereich tätig waren, haben gesagt, ja, wir hätten gerne was Gutes, idealerweise auch noch so effizient, wie es hier gerade schon besprochen wird, aber dann bitte als Standard, sodass wir das alle verwenden können. Dass das ab jetzt die neue Basis ist, mehr oder weniger. Und man kann es natürlich immer noch besser machen. Aber wenigstens haben wir überhaupt schon mal was, weil es ist für eine Firma relativ kostspielig, so was selber zu machen.
Auch für die Großen und das weiterzuentwickeln. Es gibt auch deutliche Nachteile, das bei der ITF zu machen, das muss man auch ganz klar sagen. Oh bitte, jetzt aber raus damit. Das mögen auch nicht unbedingt alle Leute. Also ein Faktor ist zum Beispiel die Zeit. Es dauert erst mal länger.
Konsens zu haben zwischen Parteien, die in der echten Welt dann auch noch Konkurrenten sind, Und es ist nicht immer so einfach, wenn man dann eben versucht, mit verschiedenen Akademikern von verschiedenen Unis das auch noch zeitlich zu koordinieren, wann die ihre Analysen machen, wann die Zeit dafür haben, das sind ganz andere Zyklen und das dauert dann einfach mal länger. Also im Fall von MLS hat das jetzt fünf Jahre gedauert, das hätte man deutlich schneller
machen können, gar keine Frage. Okay, da sind in der Zeit so einige Messenger gestorben, neu dazugekommen und also… Naja, das sowieso. Und die Akademia war wahrscheinlich auch ein Stück weiter, oder? Klar, natürlich. Das geht immer weiter. Deswegen ist MLS wahrscheinlich auch nicht das Letzte, was wir sehen werden. Nachteil ist also die Geschwindigkeit. Weitere Nachteile? Einer reicht ja vielleicht auch. Du hast von Nachteilländen gesprochen.
Also ja, im Fall von MLS weiß ich jetzt nicht, ob es so gravierende weitere Nachteile gibt, aber es kann sein, dass man Kompromisse eingeht, die nicht so toll sind. Das haben wir jetzt nicht, also das ist jetzt sehr theoretisch. In dem Fall, wenn also verschiedene Hersteller zum Beispiel verschiedene Dinge haben wollen, die nichts miteinander zu tun haben, dann kommt dabei was raus, was wirklich so zusammengestückelt ist.
MLS ist schon ziemlich aus einem Guss. Insofern haben wir das Problem zum Glück nicht. Okay. Das heißt, wir haben jetzt eine Art von technischer Spezifikation. Aber also erzähl doch mal, du hattest vorhin schon mal gesagt, Rough Consensus und Running Code. Also was ist denn nun mit dem Running Code? Was ist denn nun mit den technischen Umsetzungen dieser Spezifikation, die er da macht? Die gibt es schon, ist das richtig?
Ja, genau. Also das ist eben auch eine formale Anforderung der ITF, dass es diesen Running Code geben muss. Running Code heißt, jemand hat was programmiert und das funktioniert auch halbwegs. Und es ist nicht absehbar, dass es gar nicht funktionieren würde. Es muss also nicht so fertig sein, dass man es jetzt in eine App gießen kann und an einen Endverbraucher. Weitergeben kann, aber es muss erkennbar sein, dass es eben funktioniert. Und das ist, was man mit Running Code meint in dem Moment.
Hast du mit dem Code, also ich weiß, dass du mit der Spezifikation zu tun hast, hat das mit dem Code auch zu tun? Ja. Ja, mit beiden. Aber das ist ein Kennzwang, ne? Die Autoren können auch... Das müssen nicht die Autoren sein, aber irgendjemand muss es halt machen. Also, weil das muss ja da sein. Und typischerweise sind das eben auch die Autoren. Gerade bei jetzt Drafts, die komplexer sind, ist es halt wichtig, den Code zu haben, um beweisen zu können, ja, es funktioniert auch.
Und was man eben sehen will in dem Moment ist, dass es verschiedene Implementierungen gibt, die dann auch zueinander kompatibel sind. Ich habe zwei gesehen. Bei welcher hattest du zu tun? Mit OpenMLS, das ist eine Implementierung in Rust. Es gibt noch eine andere, die wurde von Cisco geschrieben, die ist in C++ geschrieben. Beide sind unter einer permissiven Lizenz veröffentlicht. Ich glaube, das müssen wir auch erklären. Du kannst ja nicht immer diese Fachbegriffe...
Klar, also Quellcode, wenn er denn öffentlich ist, muss unter einer gewissen Lizenz veröffentlicht werden, damit klar ist, was man mit dem eigentlich machen darf. Und es geht konkret um Urheberrecht. Wenn man eben keine Lizenz dazu packt, dann greift das ganz normale Urheberrecht und das ist ein bisschen zu eingeschränkt, weil dann dürfte man den Quellcode eigentlich überhaupt nicht verwenden, wenn man nicht selber geschrieben hat, also nur sehr eingeschränkt eben, nicht in seiner Gesamtheit.
Und da gibt es halt verschiedene Lizenzen. Ich glaube, der Ziblatt, das war MIT, ne, Lizenz, oder? Ich glaube, das war BSD, aber das ist sehr ähnlich wie MIT. Und unter einer permissiven Lizenz versteht man eben eine Lizenz, mit der man dann im Prinzip fast alles machen kann, was man will. Also da kann man einfach den Code nehmen, den in sein eigenes Produkt, in sein sehr kommerzielles Produkt auch, was selbst nicht quelloffen ist.
Einfach integrieren und da gibt es dann keine weiteren Einschränkungen. Das ist ja auch schon in der Tradition der IETF eigentlich, ne? Also mit diesem ganzen offenen, also bis dahin ist es offen und dann hoppt da was drumherum ab. Es ist zumindest im Sinne, ja. Es ist keine formale Anforderung, dass dieser Code quelloffen ist, nach wie vor nicht. Aber hattest du nicht gesagt, ne? Also okay, das ist üblich, aber nicht… Es muss ein Running Code sein. Ah, okay, I see.
Und es ist mittlerweile so üblich, dass, wenn es nicht der Fall ist… Kipps Nase rümpfen. Ja, genau. Ah, okay. Und deswegen haben wir relativ früh angefangen mit Implementierungen, einfach weil das MLS-Protokoll als solches relativ komplex ist. Das Papier ist halt geduldig, wenn man irgendetwas spezifiziert, was sehr komplex ist, kann man auch mal schnell was spezifizieren, was nachher gar nicht funktioniert.
Weil man dann gedanklich Abkürzungen genommen hat und dann erst beim Programmieren merkt, das passt ja gar nicht zusammen, da fehlt ein Schritt und der ist völlig unlogisch oder manchmal ist das dann nur etwas Kleines, da noch so nachspezifiziert werden muss, wie man den genau macht. Wenn man wirklich Pech hat, dann hat man da was logisch Unmögliches irgendwie spezifiziert. Okay, das ist aber auch wirklich… Ja, okay, so war mir das natürlich nicht klar.
Das bedeutet aber auch, dass man die Spezifikation eher so verstehen würde, wie das unter Software Engineers verstanden wird, so eine Form von Spezifikation, während ja andere Standardisierungsgremien oder Organisationen…. Also ein bisschen akademischer verstehen, würde ich jetzt mal sagen. Das heißt, es ist auch kein Prozess nacheinander, sondern miteinander. Sozusagen Coden, Spezifikationen greifen einander, ist das korrekt? Ja, das ist korrekt.
Es gibt immer wieder Debatten darüber, was die Spezifizierung jetzt genau ist, weil sie ist eben nicht eine ganz genaue Anleitung darüber, wie man es implementieren sollte, und lässt da gewisse Freiräume offen. Genau deswegen braucht man auch den Code.
Bei sicherheitsrelevanten Protokollen wie MLS-Sets geht es eben auch darum, dass es diese ganze akademische Komponente gibt, die es jetzt bei anderen Protokollen überhaupt nicht gibt, die eine ganz andere Art von Formulismus da mit reinbringt, wie das intern strukturiert ist und so weiter und so fort. Also das ist nicht immer so ganz kompatibel miteinander, also man könnte das Ding auch einmal komplett anders aufziehen mit dem gleichen Ergebnis, aber dann wirklich anders spezifiziert
von der Struktur her. Was wir jetzt haben, ist was, was eben gut genug sein sollte, um es implementieren zu können. Und das haben wir eben auch bewiesen, indem es mindestens zweifach implementiert wird. Es gibt noch weitere Implementierungen, die jetzt gerade entstehen und auch welche, die nicht quelloffen sind und schon entstanden sind. Und das heißt, wir hatten also in den letzten Monaten jetzt vor der Publikation so eine Phase der Interoperabilitätstests.
Wo wir gesehen haben, ob diese Implementierungen eigentlich zueinander passen oder nicht. Im Im Fall von MLS ist das besonders komplex, weil es geht ja darum, in Gruppen zu verschlüsseln. Das heißt, man hat sehr komplexe Testszenarien, wo es gleich um mehrere Teilnehmer geht und da muss man sich so Szenarien überlegen.
Da gibt es dann so fiktive Akteure mit Alice und Bob und Charlie und die sind dann in einer Gruppe und wollen sich Nachrichten schicken und so weiter und dann muss man so eine Art. Playbook eigentlich schreiben. Alles erstellt die Gruppe, lädt dann Bob ein und dann Bob lädt Charlie ein und schickt eine Nachricht und so weiter. Also das nur anekdotisch am Rande. Das Testen war relativ kompliziert.
Das ist deutlich einfacher, wenn man sowas wie TLS oder so testet, wo es halt einen kleinen Server gibt. Du hast mehrere Berichter verwendet, die wir hier erklären müssen. Also wir lassen sich ja nicht mit allem durchgehen. Also das Erste ist natürlich das Wort Interoperabilität. Da können sich vielleicht einige darunter vorstellen, aber bestimmt nicht alle. Und da müssen wir, glaube ich, unbedingt darauf zurückkommen, wir müssen es jetzt mehrfach fallen lassen.
Warum in aller Welt sollte das denn sicherheitsrelevant sein? Ich glaube, wir haben das noch nicht ausreichend begründet, was das eigentlich für eine Sicherheitsrelevanz hat. Auch durchaus für den Einzelnen und nicht nur für die Firma, die den Umsatz... Sag mal aber erstmal, was zu dieser Interoperabilität und was überhaupt... was soll denn das? Genau, also unter Interoperabilität, das ist echt ein sperriges Wort, versteht man halt, dass Dinge kompatibel sind und miteinander gut funktionieren.
Überhaupt funktionieren, nicht wahr? Ja, also im Zusammenspiel miteinander funktionieren. Gibt es ein deutsches Wort dafür? Interoperabilität? Nee, vielleicht zusammen in der Arbeit? Nix Gutes ein. Also es funktioniert miteinander, aber es funktioniert auch in einem definierten Rahmen miteinander. Kann man so sagen? Genau, also im Fall von MLS ist es halt relativ klar, was da zu funktionieren hat.
Weil wir wollen ja Nachrichten Ende zu Ende verschlüsseln. Und was da einfach funktionieren muss, ist, dass an Punkt A diese Nachricht verschlüsselt wird und an Punkt B, nämlich am anderen Ende, dann entschlüsselt wird. Und da kann es noch weitere Punkte geben, weil wir ganze Gruppen gleich mit betrachten. Und nicht nur A und B. Das ist intuitiv relativ klar, was da eigentlich funktionieren muss und wie die Tests dann aussehen.
Und der sicherheitsrelevante Teil ist dann die berühmte Eve, wie sie immer heißt, dass die halt nicht in der Mitte mit reinhorcht. Genau, also vereinfacht gesagt gibt es die berühmte EVE natürlich, aber um das formal einmal auszudrücken gibt es das sogenannte Threat Modelling. Auch da fällt mir jetzt gerade kein guter deutscher Begriff zu ein, den gibt es aber sicherlich. Ich würde sagen die Angriffsmodalitäten, ne die Angriffswahrscheinlichkeiten.
Genau, also man überlegt sich eigentlich was Angreifer in der Lage sind überhaupt zu machen. Haben Angreifer. Sowas wird eben auch akademisch formal definiert. Das ist jetzt nicht nur so ein Rumgerät, also da wird wirklich klar gesagt, Angreifer haben zum Beispiel das Netzwerk unter Kontrolle oder Angreifer können zeitweise Endgeräte kompromettieren. Angreifer können passiv mitlesen oder können aktiv in die Kommunikation mit angreifen. Und diese Dinge
müssen halt erstmal spezifiziert werden. Das fasst man eben unter einem Threatmodel zusammen Und dann kann man eben sagen, okay, unter diesem Threat-Model können wir uns gegen diese Art von Angriffen schützen oder eben nicht. Gail, kannst du ein typisches Angreifer-Modell nennen, was besonders wichtig ist und mit welchen Methoden ihr sozusagen, also einfach verständlich, ihr diesen Angriff abwehrt?
Genau, also es gibt eins, was den meisten Leuten intuitiv sehr klar ist bei der Ende-zu-Ende-Verschlüsselung. Geht es eben darum, dass die Informationen, die Nachrichten selbst, an einem Ende verschlüsselt werden und an anderen erst entschlüsselt werden. Das heißt, das Angreifermodell hier ist, dass ein Angreifer in der ganzen Lebenszeit dieser verschlüsselten Nachricht nicht an den Inhalt der Nachricht drankommt. Da geht es um die Vertraulichkeit, das ist eine dieser Sicherheitseigenschaften.
Und die Vertraulichkeit der Nachricht muss halt eben gewahrt sein, Wenn der Angreifer z.B. den ... Messaging-Dienst unter Kontrolle hat. Also ganz konkret, ich sende eine Nachricht über WhatsApp, ich möchte aber nicht unbedingt Meta vertrauen als Betreiber von WhatsApp, dann hilft mir Ende-zu-Ende-Verschlüsselung in dem Kontext, dass ich sicher gehen kann, dass aufgrund dieser Verschlüsselung die Schlüssel, die dafür notwendig sind, nur bei mir und bei dem Empfänger liegen.
Und gerade nicht beim Anbieter. gerade nicht beim Anbieter. Also das ist wahrscheinlich so das Plakativste, was man dazu sagen kann. Ich glaube, das ist ein ziemlich typisches Modell des Angreifers. Genau, das ist auch nicht wirklich neu, aber das ist unglaublich relevant beim Messaging. Also genau dieses Briefgeheimnis will man ja haben in dem Moment.
Aber akademisch wird das halt noch wesentlich granularer. Dann wird sich angeschaut, okay, was ist, wenn der Angreifer noch mehr könnte, was ist, wenn er Metadaten analysiert, Das ist, wenn ein Angreifer dann tatsächlich auch Zugriff auf die Endgeräte hat und so weiter. Wollen wir da einen Tick politischer werden, Asikmen? Ja, von mir aus gerne.
Gibt es da gesellschaftliche Interessenträger, die nicht so interessiert daran sind, dass es technisch abgesichert ist, dass von einem Gerät zum anderen sicher verschlüsselt ist, weil man vielleicht Gründe vorbringen kann, warum man in die Inhalte hineinhorchen will. Damit wird das Protokoll eminent politisch. Also das wird vor allen Dingen dann politisch schwendig vom Anfang an zu setzen. Das wird dir wahrscheinlich nicht neu sein, aber tritt da mal jemand an dich heran mit diesem Problem?
Also die Debatte ist ja nicht neu in dem Sinne, also Ende-zu-Ende-Verschlüsselung gab es eben schon vor MLS. So wirklich flächenmäßig verbreitet hat die sich halt in den letzten zehn Jahren, würde ich sagen. Signal war glaube ich ein Game Changer, oder? Das Signal von Snowden hat sicherlich erst mal dazu beigetragen, dass man mehr darüber geredet hat. War Snowden für dich eine Motivation?
Ich würde das so nicht formulieren, aber das hat sicherlich dazu beigetragen, dass es mehr Bewusstsein dafür gibt. Also dir ist klar, dass es irgendwie auch relevante gesellschaftliche Gruppen gibt, die das vielleicht nicht so eine gute Idee finden, wenn man technisch absichert, dass jemand rittet nicht hineinhorchen kann. Und das auch noch potenziell zumindest in sehr großem Maße zum Einsatz kommen wird. Also es gibt natürlich verschiedene Parteien aus ganz vielen verschiedenen Richtungen,
die das erstmal vielleicht auch nicht so gut finden. Aber aus sehr verschiedenen Gründen. Achso, der Aufwand macht es natürlich auch. Weil, also gut, zum einen wurde natürlich immer angeführt in den letzten zehn Jahren Terrorismusbekämpfung, um es mal beim Namen zu nennen. Jetzt, das neueste Stichwort ist CISAM. Wir müssen das auch übersetzen, da geht es um die Darstellung von Missbrauch.
Genau, es geht also um Missbrauch von Kindern, durchaus ein sehr, sehr ernstes Thema und auch ein sehr schwieriges Thema, was in der gesellschaftlichen Tabu-Thema eben auch ist, über das man nicht so gerne und so einfach spricht, sondern...
Es taucht auch nicht wirklich auf, ich habe es mal gesucht im Archiv, wir hatten ja erwähnt, relativ, also in eurem Archiv jetzt von eurer Gruppe, das heißt die politischen Debatten sind nicht wirklich Teil der Diskussion für den eigentlichen Standard, nicht wahr?
Habe ich das korrekt vorgenommen? Ja, also die ITF ist jetzt keine politische Institution in dem Sinne, es werden immer wieder politische Debatten ja mit da mit reingetragen und das ist natürlich auch wichtig, also ich meine man muss natürlich schon wissen, warum man die Dinge macht. Bei der Ende-zu-Ende-Verschlüsselung gab es hin und wieder mal einen Anflug von Debatten, aber da war der Konsens unter den Teilnehmern so groß, dass niemand das ernsthaft in Frage gestellt hat.
Gesamtgesellschaftlich wird das sicherlich debattiert, aber jetzt reflektiert die ITF hier nicht die gesamte Gesellschaft, sondern nur einen elitären Kreis. Aber jetzt gucken wir uns die sechs Autoren mal an. Während ihr parallel den Stern da draushaut, gab es eine ganz aktive Debatte, zum Beispiel in Großbritannien? Um eine Gesetzgebung, wo sich sozusagen die Arbeitgeber von zwei der Mitglieder, nämlich Meta, also Facebook und vor allen Dingen WhatsApp, hier ganz klar positioniert haben.
Die haben gesagt, also wenn das hier gesetzt wird in Großbritannien, dass wir gezwungen werden quasi Hintertüren einzubauen, dann ziehen wir das aus dem Markt zurück. Also eine ganz aktive Rolle, die plötzlich auch von Konzernen auch wirklich laut und deutlich kommuniziert wird über Tickete. Spielt es dann keine Rolle, wenn man quasi ziemlich zeitgleich zufällig gerade mal fertig ist mit seinem jahrelangen Prozess der Standardisierung?
Also es gibt da zumindest eine Zeitgleichheit, aber diese politische Debatte ist wesentlich neuer als tatsächlich der MLS-Prozess selbst. Und gut, da stehen natürlich große Firmen als Autoren mit drauf. Das ist einfach Fakt, weil die halt Autoren waren von Anfang an. Das sind ja Menschen, nicht die... Das sind zunächst mal die Menschen und die müssen gegebenenfalls Dinge mit ihren Arbeitgebern koordinieren.
Also es gibt tatsächlich von den großen Unternehmen in Silicon Valley Arbeitgeber, die lassen einen das nicht machen. Also da darf man nicht ITF-Auto werden mit Affiliation. Es gibt so eine Firma, die eine Frucht als Logo hat, die da sehr bekannt ist. Ah, Orange. Das ist bestimmt eine Zitrone. Die Notorie dafür bekannt ist, bei der ITF nicht mitzumachen und erst seit Neuestem überhaupt ab und zu mal Leute hinzuschicken.
Also, dass die Abkürzung ITF bei so einer Apple-Entwickler-Konferenz überhaupt mal genannt wurde, ist neu. Also ich glaube, das erste Mal war letzten Sommer bei der letzten WWDC, wie diese Konferenzen heißen. Ja, also da tut sich vielleicht auch ein bisschen was, aber historisch gibt es halt Firmen, die da ganz klar sagen, nee, wir sind so verschwiegen, intern wie extern.
Das können wir uns gar nicht oder wollen wir uns gar nicht leisten, dass da irgendwie Informationen abfließen könnte in so einem offenen Gremium. Also das heißt, die Geheimdienste sind noch nicht offen, zumindest auch nicht ran getreten, nicht, dass ihr es gemerkt hättet anscheinend und auch noch nicht die Überwachungsfreundinnen da draußen. Um das zu unterwandern? Oder vielleicht auch nur das Gespräch zu suchen, ich weiß es nicht.
Also es ist mir nicht bekannt. Ich meine, die Mailing-Listen sind ja öffentlich, die ganzen Dinge auch. Und ich weiß auch nicht, was das Gespräch sein sollte an der Stelle. Also, na ja, Staaten haben so eine gewisse Dualität immer. Einerseits wollen die an Informationen rankommen, das liegt in der Natur der Aufträge oder der Legitimation, die gewisse Dienste haben. Gleichzeitig haben die aber ein genauso hohes Interesse, dass Information auch geschützt wird.
Und das hängt dann davon ab, mit wem man redet. Also der Trend geht glücklicherweise aus meiner Sicht dahin, dass man die Schutzwürdigkeit der Information. Grundsätzlich anerkennt. Ich wünschte es wohl. Leider gibt es aber eben in verschiedenen Jurisdiktionen jetzt Debatten über verschiedene Gesetzgebungen, die sehr heiß geführt werden. Wir müssen halt mal sehen, was dabei rauskommt. Du hast eine Rolle daran, du bist ein Enabler, wenn man so will.
Oh, das ist auch kein Wort. Das ist ein Gefähiger. Ja, du bist echt gefährlich. Na ja, du hilfst ganz aktiv mit, Technik in die Praxis zu bringen. Und zwar wirklich auch nicht für drei Handschellen, sondern für ganz viele Menschen. Aber ich glaube schon auch, wie du gerade sagtest, alle Staaten haben diese Dualität oder staatliche AkteurInnen haben diese Dualität.
Das zeigt ja auch vielleicht, wie unterkomplex die Debatte um, wir müssen Verschlüsselung aushebeln, um an bestimmte Informationen zu kommen, gerade geführt wird. Und dass natürlich das Interesse am Ende schon überwiegt, sich selber abzusichern und irgendwie die eigene Kommunikation zu schützen. Das ist ja schon ein gutes Zeichen. Aber ihr habt keine staatlichen Institutionen als, also als Institutionen mit, zumindest sind mir keine großartig aufgefallen.
Also bei MLS ist da niemand in den Vordergrund getreten und hat gesagt, man weiß natürlich, da diese Dinge öffentlich sind, weiß man natürlich nie, wer hat eigentlich diese Mailingliste abonniert und wer verfolgt das aktiv. Das ist immer sehr spannend. Verfolgen ist ja was anderes als mitwirken. Genau, klar. Klar, aber es gibt auch bei der ITF Dokumente, Drafts, wo die NSA offiziell bei den Autoren mit draufsteht, bei den Älteren.
Und das aus gutem Grund, weil die einfach auch ein Bedürfnis daran haben, dass Dinge geschützt werden, weil die intern schon diese Dualität haben, dass die sowohl schützen wie auch angreifen. Und das gibt es natürlich bei anderen Standardisierungsgremien auch, ja. Genau, bei den anderen Ländern ist das manchmal ein bisschen stärker getrennt. Aber es fällt noch was anderes auf. Es gibt wenig nicht-westliche Namen auf euren Mailinglisten.
Stimmt das? Ja, das stimmt. Und das reflektiert auch irgendwo, was bei der ITF insgesamt passiert. Also das sind, ich will schon sagen, gefestigte Kreise irgendwo, die sich selber immer wieder so ernähren. Und das ist natürlich ein Problem. Dazu vielleicht eine Erfahrung von mir. Ich war 2019, glaube ich, bei meinem ersten ITF-Treffen in Singapur. Und nicht nur war die erste Person, mit der ich bei irgendeinem Cocktail-Event, bei so einem Schnittchen-Event abends gesprochen habe,
tatsächlich da als Contractor für die NSA. Und ich bin aus allen Wolken gefallen irgendwie und wusste gar nicht, ob ich ihm jetzt ein Getränk ins Gesicht schütten soll oder da weiter Smalltalk machen soll. Das war also auch total spannend, damit auf so einer Selbstverständlichkeit dort sehr unterschiedliche Leute aufeinandertreffen. Und das andere ist aber auch, dass ich dort, ich habe da eher Interviews geführt, um so ein bisschen die ganze Szene zu erkunden und Bedarfe nochmal aufzudecken.
Und dass da aber auch meine Frage auf, wer ist denn eigentlich hier und wer ist denn nicht hier so demografisch gesehen, dass die kaum beantwortet werden konnte. Und ich glaube jetzt seit 20... 2021 werden tatsächlich demografische Berichte auch veröffentlicht, die nochmal Auskunft darüber geben, wer ist da eigentlich. Demografisch? Demografisch, Herkunft, Alter, Gender. Ich habe keine Frauen gesehen. Na schon, doch, doch. Also nicht in der Gruppe.
Das weiß ich nicht in der Gruppe, aber tatsächlich, da gibt es ein Missverhältnis, das ist nicht 50-50, aber es gibt durchaus Frauen bei der IETF. Und auch Herkunftsregionen und bin ich für die Zivilgesellschaft hier, bin ich für die Wirtschaft hier, bin ich für die Wissenschaft und Forschung hier. Also das ist ganz spannend, dass da jetzt auch schon, habe ich das Gefühl, auch mehr Interesse da ist, nochmal zu gucken, wer ist denn eigentlich nicht hier.
Insofern ist die Frage spannend, aber ich glaube auch gerade ziemlich in den Köpfen vieler Menschen. Ja, da setzen sich natürlich auch gewisse Traditionen fort. Aber wenn man darauf blickt und bemerkt, ist ja schon erstmal der erste Schritt getan, oder? Würdest du es denn wieder tun? Also grundsätzlich ja. Ich meine, das war jetzt natürlich nicht wenig Arbeit. Und zum Teil, ich bin auch noch in anderen Arbeitsgruppen mit engagiert. Hast du noch andere Engagements zum Beispiel? Na ja, jetzt aber.
Ich hatte ein sehr kurzes Engagement in einer Arbeitsgruppe, die sich Privacy-Pass nennt, die wesentlich kleiner ist, wo es um ein etwas kleineres Problem geht. Es gibt eine neue Arbeitsgruppe, die vor kurzem entstanden ist, die nennt sich Mimi. Mimi? Oh, da können viele mitmachen. Da können viele mitmachen. Nur Mimi. More Instant Messaging Interrupt, zum Glück haben wir schon darüber gesprochen, was Interrupt bedeutet.
Und in der MLS-Arbeitsgruppe selbst wollen wir jetzt ein bisschen schauen, was es noch an Bedarf gibt, den wir nicht erschlagen haben im ersten Anlauf, im Sinne von Erweiterung für das Protokoll. Und weiteren Code? Würdest du daran auch noch mitwirken? Ja, und das tun wir auch faktisch. Also unser Alltag ist tatsächlich so ein bisschen, das hast du schon gesagt, sind irgendwie Enabler von Ende zu Ende Verschlüsselung. Das werde ich mir auf jeden Fall merken, mich demnächst so vorstellen.
Soll ich dir ein T-Shirt für meinen Mann machen? Nein, tatsächlich. Er schimpft doch auch wirklich, oder? Nein, das geht tatsächlich. Ich ziehe das ein bisschen so in den Kakao, aber ich finde es sehr gut. Weil tatsächlich ist das das, was wir auch machen wollen. Wir wollen halt andere in die Lage versetzen, Ende-zu-Ende-Verschlüsselungen verwenden zu können. Und ein Schritt war natürlich, erst mal eine Spezifizierung dafür zu haben. Anderer Schritt war, eine Implementierung dafür zu haben.
Das heißt wirklich Running Code, den man auch verwenden kann unter einer permissiven Lizenz, damit da die Hürde so gering wie möglich ist. Und der nächste Schritt ist es dann zu sehen, was braucht es denn eigentlich noch drumherum? Weil mit so einem Ende-zu-Ende-Verschlüsselungsprotokoll haben wir eigentlich nur so den Kern. Also wir haben uns das Ganze irgendwie als Auto vorgestellt, haben wir jetzt den Motor gemacht, aber der Rest vom Auto fehlt halt immer noch.
Und vielleicht können wir dann auch das Getriebe oder sonst was dazu bauen. Und das ist jetzt, wo wir dran arbeiten, konkret. Also für mich war das eine große Erkenntnis, dass das so ein gemeinschaftlicher Prozess ist. Also dass das eben nicht so eine Abfolge ist, erst mal spezifizieren und dann den Code schreiben, sondern dass das zusammen gemacht wird, aber das schließt sich natürlich ein bisschen aus dieser Organisation in gewisser Weise.
Wusste ich so nicht und ist ja vielleicht auch nicht, stimmt nicht unbedingt jetzt für jeden RFC, wenn man jetzt auf die Geschichte der RFCs guckt oder so, aber erscheint mir auch irgendwie so ein Ansatz, nachvollziehbarer Ansatz für eher praktische Probleme, was sie ja sind, ne. Also, aber um auf meine Frage zurückzukommen, würdest du es wieder tun, würde ich ein Och ja daraus hören.
Oder ich bin schon dabei, habe ich eigentlich rausgehört. Genau, zum guten Teil bin ich dabei, deswegen stellt sich die Frage gar nicht. Aber würde ich nochmal eine Zeitreise machen, würde ich nochmal zurückgehen? Ja, ich würde es nochmal machen. Gewisse Dinge würde ich sicherlich anders machen. Also vielleicht wirst du mal ans Veteranenden, wie wir die vorhin genannt haben. Irgendwie 25 Jahre ITF, hier sind meine RFCs. Das glaube ich nicht. Ich habe da keinen langfristigen Plan.
Das ist sehr zweckgebunden bei mir. Wenn da die Ziele erreicht sind, dann sind die erreicht. Was würdest du denn jemandem raten, der... Sich auch gerne einbringen will und das vielleicht für sich selbst eine Option findet? Ich würde die Person erst mal ermutigen, das zu machen, weil das nicht immer so ganz klar ist, wie man überhaupt mitmachen kann. Also es gibt glücklicherweise bei der ITF sehr viel schriftliche Dokumentation, die man auch filmen kann.
Oh, was für ein Understatement! Das ist ein Wust! Genau, das ist gleichzeitig der Nachteil. Man ist so ein bisschen erschlagen.
Man ist auch erschlagen von diesem Formalismus und was natürlich auch beängstigend wirkt, das muss man auch klar benennen, sind diese gewachsenen Strukturen, sind, naja, so demografische Ungleichheiten, sind Hürden, um da mitmachen zu können, eben man muss erstmal dahin reisen können und so weiter, muss die Zeit haben, muss das Budget dafür haben und dann eben auch der Umgangsstil kann befremdlich wirken am Anfang.
Ich fand das eher nett zumindest. Er ist nicht unbedingt unfreundlich, er ist im Vergleich zu anderen Communities auch sehr nett, aber er kann anschüchternd wirken in dem Sinne, dass man sich vielleicht nicht traut, da mitzumischen, weil man den Eindruck hat, da sind Leute da, die haben sehr viel Kompetenz, man selbst hat die nicht unbedingt. Man will nichts Falsches sagen auf so einer Mailing-Liste, von der man gar nicht weiß, wie viele Tausende Leute da eigentlich mitlesen.
Und in dem Sinne würde ich die fiktive Person, die da jetzt mitmachen will, nur ermutigen, das trotzdem mal zu versuchen. Gibt es da so Mentoren, Einstiegshilfen, irgendetwas? Also es gibt Einstiegshilfen, es gibt so Orientierungen zumindest bei den Konferenzen selbst, wo das einem auch nochmal ein bisschen näher gebracht wird und so weiter.
Wie gesagt, man könnte es auch alles theoretisch nachlesen, aber auch da ist die Hürde irgendwo groß, Ich weiß nicht, was man eigentlich nachlesen soll und wo. Die nächste Sitzung der IETF wird ja auch nicht zu weit entfernt von hier stattfinden. Die ist im Herbst, wenn ich richtig informiert bin, in Prag. Also eine schöne Zugreise von Berlin oder von vielen anderen Orten in Deutschland entfernt.
Und ich weiß nicht, ob das noch so ist, aber zumindest früher gab es durchaus auch gerade für Leute, die noch studieren oder promovieren, Stipendien von der IRTF, der Internet Research Task Force. Also ich weiß nicht, ob ihr euch da noch drauf bewerben könnt, aber tatsächlich das Finanzielle ist ein Faktor an der Teilnahme.
Aber vielleicht gibt es da auch noch Möglichkeiten, die Interessierte, potenzielle, fiktive oder reale Interessierte ausschöpfen können, um wirklich einfach mal reinzuschnuppern. Und ich glaube, auf der Meldingliste den Mut aufzumachen, ist tatsächlich schwierig, bei so einem Treffen mal dabei zu sein. Das macht es dann schon konkreter. Ja, wahrscheinlich senkt das die Hürde. Also gut, dass du es ansprichst.
Gibt es diese Hürde tatsächlich? Die Teilnahme kostet einfach was, es ist günstiger, wenn man es online macht, aber dann ist es eben auch nicht unbedingt das, was man haben will. Die Kosten werden einem in Sonderfällen wohl erlassen, aber die Sonderfälle sind relativ wenige, so wie ich das verstanden habe. Also das ist mit einer der Kritikpunkte, dass es diese finanzielle Hürde gibt für Interessierte.
Ich hätte ja noch eine letzte Frage. Das ist quasi eine Gretchenfrage. Kann ich die noch loswerden? Welchen Messenger benutzt du? Ich musste diese Frage stellen, ich warte schon die ganze Zeit darauf. Na, und? Warum? Wir haben noch keinen MLS-basierten Messenger, aber da werden auf jeden Fall welche kommen. Ja, schön. Aber welchen benutzt du nun und warum? Im Alltag verwende ich momentan Signal, tatsächlich. Du hast also deine Telefonnummer abgegeben. Das ist einer der großen Kritikpunkte, ja.
Hast du nur einen Messenger? Ich verwende natürlich auch mehrere, einfach weil ich daran interessiert bin, die zu vergleichen und zu sehen. Hey, Lisa, hast du auch den Eindruck, er will es nicht sagen? Naja, es ist ja auch die Frage mit der Schleichwerbung und so weiter, aber... Also die Frage wäre einfacher, welchen Messenger verwende ich nicht, aber sagen wir mal... Lass mich raten, Telegram. Guter Punkt, ja. Telegram versuche ich zu vermeiden, habe ich aber mal Spaß, es halber.
Nein, wahrscheinlich musst du dich ja auch im Feld auskennen, du willst es wenigstens mal probieren. Klar, das ist wirklich auch berufliche Neugierde in dem Moment. Das heißt, du hast so einen Messenger-Zoo auf deinen diversen Endgeräten. Das ist ja auch niedlich. Ja, Raphael, dann wollen wir uns ganz doll bedanken. Du bist ein sehr, finde ich, geduldiger Erklärbär. Ich finde jedenfalls den Prozess, den du beschrieben hast, sehr gut verständlich.
Und trotzdem, wir so ein bisschen festgestellt haben, dass die Organisation ja noch ein bisschen offener sein könnte und diverser, ist es glaube ich trotzdem ein recht einladenden Eindruck, zumindest bei mir hinterlassen. Also wer sich jetzt so für Engineering interessiert, denke ich, sollte da mal reinschnuppern. Ansonsten empfehlen wir selbstverständlich MLS zur Lektüre. Ich denke, der Überblick, den ihr geschrieben habt, der ist auch durchaus lesbar.
Also den Problem aufrisst und so, den kann man schon verstehen, zumindest nach dem Hören von unserem Podcast, hoffe ich doch. Und ja, dann bedanken wir uns und hoffen, dass du unser kleinen Podcast, der die Dicke Bretter heißt übrigens. Weiterhin treuer Hörer bleibst und dass du auch in Zukunft dicke Bretter bohren wirst. Denn so ein Standardisierungs- oder jedenfalls der Versuch einer Standardisierung ist ja offenbar ein ordentlich dickes Brett. Ja, wirklich. Danke, Raphael.
Ja, vielen Dank, dass ich hier sein durfte. Hat mir auch viel Spaß gemacht. Tschüss, liebe Hörer. Bis zum nächsten Mal. Music.