Wo wir sind, ist vorne, Folge 31. Heute desinfizieren wir das Internet.
Herzlich willkommen bei Wo wir sind, ist vorne.
Frontend Fakten Frotzeleien.
Der Late-Night-Frontend-Talkshow rund um Webdesign und Entwicklung.
Es reden sich um Head und Kragen, HTML-Fundamentalist Moritz Gießmann und JavaScript-Jongleur Konstantin Groß.
Hallo, da sind wir wieder und wir sind heute zu dritt.
Wir haben mit an Bord den Frederik oder Freddy Braun.
Hi, schön, dass du da bist.
Hallo.
Ja, mir gar nichts überlegt für die Begrüßung.
Eigentlich können wir direkt mit unserem Bier starten, weil wir sind alle heute am Start.
Genau, weil ich noch wenig gesagt habe, fange mal an.
Ich trinke heute aus Brügge immer noch belgisches Bier, ein Bruxezot oder Bruxezot.
Ich habe keine Ahnung, wie es richtig ausgesprochen wird, dass so ein lustiger Clown vorne drauf und ich sage mal, 6 Prozent ist diesmal nicht so schlimm, wie es schon mal war im Stream.
Ja, bin mal gespannt, wie es schmeckt.
Ich mache mal hier wieder ein bisschen Alze mehr.
Das ist aber schön.
Freddy, was hast du Gutes?
Ich trinke zwei Getränke. Einmal für die Stimme, vielleicht hört man es ein bisschen, ein Halswärmer Tee. Der ist nicht nur für die Stimme, der ist auch für den Geschmack, muss ich sagen. Und dann nur für den Geschmack, Lamsbräu, dunkelalkoholfrei. Ich mag gerne Dunkelbier, sehr würzig, sehr lecker. Das ist eins meiner Lieblingsbiere.
Cool. Ja, kommt auf jeden Fall auf meine interne Liste für Getränke. Ja, ich habe ein Bier vom Discounter meines Vertrauens. Tatsächlich, aber es ist nicht so ein Dosenbilligbier, sondern so ein Craftbier, ein Irish Craft, The Crafty Brewing Co. Lager. Und das, ja, habe ich gedacht, sieht nicht schlecht aus, probiere ich mal aus. Mal gespannt, was das kann. Ja, dann zum Wohl.
Zum Wohl. So. Prost.
Okay. Habt ihr noch was oder starten wir direkt mit der Retro?
Starten wir doch, oder? Jawohl. Jo.
BW SIV präsentiert die Retrospektive.
Ja, wir beginnen mit einem Desaster. Und ich habe nicht so richtig tief in die Technik reingeschaut.
Ich weiß nur, dass alle Builds bei uns rot waren. Let's Encrypt.
Da hat sich was geändert. Da ist so ein, ich glaube, diese Root-Stelle, da hat sich irgendwie geändert.
Das Stammzertifikat ist abgebrochen. Ja, das Stammzertifikat, genau.
Also ein bisschen was technisch kann ich sagen, wenn du da nichts ... Ich will dazu nichts sagen. Achso, du willst da nichts zu sagen.
Ja, ich würde dazu sagen. Ja, ich würde es, glaube ich, ich würde es kurz erklären wollen. Ja, gerne.
Also ich bin jetzt auch nicht komplett drin, so in Kryptografie und Zertifikatsgeschichten, aber es ist so, dass bis vor einigen Jahren war das ja immer noch so, dass SSL-Zertifikate sehr viel Geld gekostet haben, wenn man die hatten, wenn man die wollte.
Und dank Let's Encrypt, ist, glaube ich, eine allgemeinnützige Organisation sogar, gibt es das jetzt quasi kostenlos und relativ einfach auch oft integriert in diesen Serververwaltungsschnittstellen und so.
Und das basierte aber darauf, das ist ja immer so ein Level of Trust, es gibt diese Stellen, die das da offiziell signen und dafür bürgen quasi, dass der Inhalt auch dem entspricht, was man behauptet.
Und wenn da jetzt jemand Neues auf den Markt kommt und sagt so, ja, wir bieten das jetzt an, dann muss ja jemand dafür bürgen, dass das auch tatsächlich alles so seine Richtigkeit hat.
Und deswegen war das so eine Zertifikatskette, nicht ein einziges Zertifikat, sondern es wurde quasi dafür gebürgt, seitens von einem etablierten Anbieter, dass das alles seine Richtigkeit hat.
Und inzwischen ist es so, dass dem Let's Crypt Zertifikat, dem eigentlichen, tatsächlich auch direkt vertraut wird.
Und dieses Hintergrund Zertifikat, dieses Root Zertifikat, das ist jetzt eben abgelaufen Ende September.
Und das ist das, was zu den Problemen geführt hat, weil gerade ältere Systeme, die halt noch im Zertifikatsspeicher nicht die entsprechenden Änderungen drin haben und die entsprechenden Updates bekommen haben, dem eigentlichen Zertifikat eben nicht vertrauen.
Und dadurch kamen diese Probleme.
Ja, mega nervig. Kann ich dir nur dazu sagen.
Ja, und vor allem halt, also ich meine, so Sachen wie Slack war halt down und darauf basieren wir halt auch unsere Kommunikation.
Und das ist halt einfach, wenn das einen halben Tag einfach nicht geht, hat schon Impact auch so auf größere Firmen.
Nicht, dass ihr denkt, der Podcast, nein, wir nutzen sowas nicht.
Nee, nee.
Das muss ja Konstantin.
Genau.
Sollen wir gleich zum Nächsten?
Ja, gerne.
Wir waren am, wann war's denn?
Letzte Woche Donnerstag, 30. September war das.
Da waren wir beim Jonas Tech Up und haben dort unsere Folge 28 quasi nochmal aufgegriffen.
Das waren die CSS-Eigenschaften, die wir noch nicht kannten und haben die dort als Demos gezeigt im Livestream.
Und man kann das, wer es verpasst hat, weil wir haben es nämlich auch verpasst im Podcast direkt anzukündigen, der kann das in der Mediathek von Jonas nachschauen.
Da kommt der Link in die Shownotes und vielleicht interessiert es ja jemanden, das Ganze nochmal in Aktion zu sehen.
Genau.
Und wer wissen will, wie das aussieht, wenn ich meinen Rechner mal an die Grenzen treibe, so bis der Ton abstürzt, dem sei das auf jeden Fall empfohlen, weil das war letzten Endes, das werdet ihr dann sehen.
Da gab es am Ende ein kleines Problem und das war tatsächlich, dass mein Mac gesagt hat, nee, Speicher ist jetzt voll, mach mal bitte Apps zu.
Genau.
War eine gute Erfahrung.
Jetzt weiß ich auch mal, wie das aussieht.
Das hatte ich nämlich vorher noch nicht geschafft.
Ja.
Aber schon, das ist ja heute recht schnell, genau.
Ja.
Genau, dann kommen wir zum nächsten Punkt.
Das war ein Gespräch, was ich im Stream schon mit den Leuten hatte, aber auch mal mit einem Kollegen geführt habe und wir haben da auch schon drüber gesprochen.
So die Frage, was ist eigentlich eine Podcast-Folge wert, haben wir uns mal gestellt.
Das ist gar nicht so leicht zu beantworten.
Also so, ist eine Podcast-Folge ein Euro wert?
Würdet ihr einen Euro für eine Podcast-Folge bezahlen?
Nicht, dass wir unseren Podcast kostenpflichtig machen wollen, aber es war so ein interessanter Gedanke.
Also ist das irgendwie, wenn ich jetzt am Abend in der Kneipe ein Bier trinke für 3,50, das sind dann quasi drei Podcast-Folgen, also wenn man das mal so gegenüberstellt.
Und ich fand es ein interessantes Gedankenspiel.
Konstantin, was wäre dir in der Podcast-Folge denn wert?
Ja, also ich bin da tatsächlich auch nicht so dabei beim Spenden, ich bin aber auch nicht so dabei beim Hören.
Also ich höre relativ wenig Podcasts und relativ unregelmäßig.
Aber so im Grunde finde ich jetzt ein Euro pro Folge tatsächlich nicht viel.
Also je nachdem, wie oft die natürlich rauskommt.
Wenn die jetzt jeden Tag rauskommt, dann wären das schon sieben Euro in der Woche.
Aber also gerade für so, wie wir veröffentlichen alle zwei Wochen in Euro pro Folge, finde ich jetzt nicht viel.
Gibt es einen Podcast, der jeden Tag veröffentlicht?
Ich weiß es gar nicht.
Keine Ahnung.
Naja, es gibt halt viele Radiosendungen, die viele Leute als Podcasts hören.
Die gibt es natürlich dann schon täglich, gerade auch so kurze Sachen.
Was ich zum Beispiel sehr, sehr gerne höre, wenn ich Wärmung dafür machen darf, ist das WDR-Zeitzeichen.
Das ist jeden Tag 15 Minuten ein Jahrestag, ein Todestag, irgendwas aus der Geschichte.
Und immer meines Erachtens nach höchst interessant.
Manchmal technisch, manchmal Kultur, manchmal, keine Ahnung, Politik.
Ja, der ist täglich.
Aber den bezahlen wir ja schon durch unsere Runde.
Wobei, ich weiß nicht, ich glaube, da kommt es, glaube ich, auch auf den Gehalt und wie viel mir das bringt und auch auf die Länge an.
Ob ich dann sagen würde, was ist das wert?
Also 15 Minuten jeden Tag werden mir jetzt nicht jede Folge in Euro wert.
Ja, 15 Minuten ist natürlich völlig anders als der typische Tag.
Man könnte ja sagen, eine Minute, einen Cent, dann würden wir mit einer Stunde …
Dann würden wir noch mehr reden, damit wir die Zeit aufblähen.
Nein, nein, natürlich nicht.
Genau, also alles, was ihr von uns kriegt, könnt ihr ja auch kostenlos konsumieren.
Wir wollen auch, dass das so bleibt.
An der Stelle aber dann noch ein riesiges, riesiges Dankeschön an die größte Spende, die wir bislang bekommen haben.
Ich sage jetzt nicht wie viel, ich sage nur Danke, Susanne.
Ja, vielen Dank, Susanne.
Das war echt der Hammer.
Als ich die Mail gekriegt habe, habe ich gedacht, das kann nicht wahr sein.
Total verrückt.
Vielen, vielen Dank.
Und vor allem, normalerweise sind wir es gewöhnt in letzter Zeit, wenn wir Spenden kriegen, dann passieren die während dem Stream, weil die Leute dann auch quasi direkt ihre Props kriegen in Form eines Overlays.
Und dann noch einen kleinen Text reinschreiben können, der dann vorgelesen wird.
Aber das kam jetzt einfach so unvermittelt zwischendrin und es hat uns ja sehr, sehr gefreut.
Genau.
Dann?
Dann geht es schon weiter.
Den Begriff Internet-Ausdrucker, den benutzt man ja gerne, um so den Zustand der Digitalisierung in Deutschland zu skizzieren.
Und wir hatten jetzt tatsächlich eine Anfrage von einem Kunden, wo wir gerade den Relaunch machen, ob wir nicht die alte Webseite bitte ausdrucken könnten.
Komplett.
Weil wir machen ja da eh ein Backup davon.
Und das ist sehr umfangreich, diese Webseite, muss man wissen.
Das sind irgendwie, keine Ahnung, über tausend Seiten mit News und so.
Und darauf angesprochen meinten sie dann, ja ne, die News brauchen wir ja nicht.
Also sind es nur noch ein paar hundert Seiten.
Aber auch die wollten sie also ausgedruckt haben.
Und so eine Webseite auf A4 zu bringen, ist immer die Frage, wie sinnvoll das ist.
Und eine Seite hat dann halt vielleicht auch mal mehrere A4-Seiten noch.
Also wären wir doch wieder bei tausend Seiten gewesen.
Und das Ziel war also, also die Chefs, die sind nicht so digital anscheinend.
Und die hätten das dann doch gerne in Papierform, um sich den Umfang überhaupt mal vorstellen zu können.
Und außerdem würden sie uns dann gerne die Textpassagen auch streichen oder einfügen,
die auf der neuen Webseite angepasst werden sollen.
Ah nein, auf dem Papier, sehr gut.
Ja, also ich will mich jetzt nicht lustig machen, deswegen, ich sag auch keine Namen,
aber ich fand's einfach krass, dass es das noch gibt.
Also dass Menschen halt wirklich so undigital denken, dass das eine ganz plausible Methode erscheint.
Also es gibt auch, wie sag ich das jetzt, ohne jemandem auf die Füße zu treten,
es gibt nicht ganz niedrigrangige Mitarbeiter von großen Tech-Unternehmen,
deren Workflow auch so aussehen soll, hab ich gehört.
Ja.
Also die sich Dinge, die digital sind, zur Korrektur ausdrucken lassen,
handschriftliche Notizen machen, das dann einscannen und wieder einscannen lassen
und dann wieder zurückschicken an denjenigen, der es gebaut hat, der die Änderungen einarbeiten soll.
Also das ist Realität.
Da bin ich mir relativ sicher, hab ich gehört.
Ja, krass. Also ich fand's lustig, dass halt wirklich jemand das Internet ausgedruckt haben möchte.
Ja, vor allem auch so viel dann, ne?
Weißt du, bei dem, was ich da gehört hab, da geht's um vielleicht ein oder zwei DIN-A4-Seiten,
die da am Ende rauskommen, aber halt irgendwie tausend.
Und wir würden es gerne einmal alles durchlesen, korrigieren, Korrektur lesen,
Passagen streichen und dann bitte wieder durch Magie ins Netz, bitte.
Ja, also auch der Aufwand.
Also ich meine, der Aufwand für uns alleine, alle Seiten durchzugehen.
Also gut, ich hätte einen Crawler geschrieben, der die dann zumindest mal abspeichert.
Und das dann auszudrucken und auch zu sichten, dann die Änderungen wieder zu überführen.
Ich meine, dafür gibt's ein CMS am Ende.
Ja, wir haben's aber, glaube ich, jetzt verargumentiert bekommen, dass das,
also dass wir das gerne machen können, aber dass das sehr teuer werden würde.
So kann man's immer ganz gut besprechen, ne?
Wir würden das schon machen.
Hier erstmal so einen Kostenvorhang schlagen.
Ja, kein Problem.
Wir machen das auch gerne, für diesen Betrag.
Ja, für den Betrag hätte ich das gerne gemacht, ja.
Ja, du, ich meine, wenn du, wenn du, wenn der Betrag stimmt und du dann sagen kannst,
also ich würde den bitte relativ hochschrauben und dann sagen, klar, kein Problem, kostet, kostet 500.000.
Ja, ich glaube, das wollten sie dann irgendwie doch nicht mehr.
Oh, das ist ja, sehr traurig.
Okay.
Das war's zum Internet ausdrucken.
Dann kommen wir ...
Hört ihr mich noch?
Ja, ja, ja.
Ich bin auch schon gebannt.
Voll.
Es sah gerade so aus, als ich guck in so ratlose Gesichter.
Da ist ja was los.
Ähm, genau.
Wir reden ja heute auch über Security und es gab ja ein schönes Twitch-Leak.
Wir haben in unserem Stream schon drüber gesprochen.
Ähm, unendlich viele Repositories und auch Auszahlungsdaten sind geleakt worden.
Und, äh, das ist ...
Also, natürlich, da wir auch auf Twitch selbst streamen, war das natürlich eine interessante Geschichte.
Ähm, ich hab ...
Ich sag's mal so, ich hab da mal reingeguckt, äh, in diese Daten und es ist unendlich viel.
Und ich kann mir fast ...
Also, es ist natürlich möglich, dass jemand so was von außen abschneuchelt, aber irgendwie wirkt's auf mich wie ...
Als ob da jemand von innen das irgendwie hat vom Blaster fallen lassen.
Es ist so weitreichend.
Es sind so viele Sachen.
Ähm, es ist ...
Ich weiß nicht, hast du's auch mitgekriegt, Freddy?
Ja, ich hab's auch gehört und ich fand's relativ abgefahren, weil halt irgendwie alles dabei ist, ne?
Von Quellcode über Datenbank bis hin zu Backups und ich weiß es nicht.
Also, ich hab's auch nur so ...
Ich hab mir den Liegen nicht angeguckt, die haben mir nicht runtergeladen.
Aber was ich so gehört hab in den Medien, das ist schon, äh, ist schon abgefahren.
Also, man sieht auf Twitter ganz viele Screenshots und so.
Und also, teilweise wurden irgendwelche, äh, Fotos auch von, von Whiteboards oder sowas, hab ich mal gesehen.
Ähm, krass.
Ja, und, und, also wirklich, also wirklich die Repositories mit allen Commits.
Also, du kannst dir die komplett anschauen.
Du kannst von vor etlichen Jahren, äh, sehen, wie die Dienste sich entwickelt haben und, und auch wie die arbeiten und so.
Also, wer wann was committed hat.
Krass.
Also, es ist, es ist wirklich crazy.
Ähm, und wie gesagt, also, dass, dass so, so breit da was rausgetragen wird, ich mein, das ist schon möglich durch ein Leck von außen, aber irgendwie, irgendwie wirkt's auf mich anders.
Keine Ahnung.
Ich mein, wenn es jemand von außen geschafft hat, dann großen Respekt.
Und wenn's halt jemand von außen geschafft hat, dann muss der ja irgendwie wochenlang da beliebig rein und raus gelaufen sein.
Also, das ist ja so offensichtlich, so offensichtlich von vielen, mehreren unterschiedlichen Systemen gekommen, ne?
Also, von wegen Commit History und Datenbank und das nicht gesehen.
Das hast ja normalerweise nicht alles auf der gleichen Kiste.
Von daher würde ich davon ausgehen, da hat jemand echt über, über Tage oder Wochen immer wieder rein und, äh, den digitalen LKW vollgeladen und wieder rausgefahren.
Also, das fällt halt auf.
Das sind ja auch viele Daten.
Das fällt halt auch auf.
Das taucht auf einer Rechnung auf, so.
Das ist, denke ich auch, also, wenn du ne, wenn du ne fitte IT-Abteilung hast und, ähm, ich, ich kenne das, ich hab mit solchen Leuten ab und zu zu tun, ähm, wenn da ungewöhnlicher Traffic ist, dann merken die das auch irgendwann.
Also, das, also, wenn du das, wenn du das verstecken willst, dann müsstest du das in ganz kleinen Häppchen machen und dazu ging das zu schnell, weil die Daten relativ aktuell sind auch.
Also, das ist nix, was du, was du in fünf Minuten da runterlädst.
Ähm, es war ja ein Paket, das allein, das, also, das, das Paket bei, bei BitTorrent und das waren ja lauter ZIP-Dateien, äh, ist ja schon, äh, 135, äh, 125 oder 130 Gigabyte groß gewesen.
Also, ja, irre.
Wirklich irre und, äh, ja, bin mal gespannt, was da jetzt noch kommt.
Wir haben natürlich unseren Streamkey gleich geändert, äh, mit dem Ergebnis, dass wir ihn jetzt gleich nochmal ändern mussten.
Weil Twitch gesagt hat, so, wir setzen ihn euch jetzt nochmal zurück.
Ähm, also, was da noch, ich bin auch sehr gespannt, was da noch für Fallout kommen wird, was da noch, was in diesen Daten noch entdeckt werden wird, weil das ist so ein riesen, so ein riesen Datensatz, da gibt's bestimmt noch das ein oder andere Spannende zu, zu finden, weil, ich glaub, bis du da irgendwie durchblickst, was da überhaupt alles drin steckt, ähm, das, da muss, muss ich eine Weile mit beschäftigen.
Also, ich muss sagen, wenn's kein Inside-Job war, dann hab ich ein bisschen Angst, ähm, weil ich mir denke, okay, wenn, jetzt sind ja schon Profis wahrscheinlich, die an so einem, in so einem großen Unternehmen arbeiten, wenn deren Code so angreifbar ist, dass man da wirklich an alles kommt, also im Endeffekt Zugriff auf, auf alles, ja, ähm, dann will ich nicht wissen, wie angreifbar der Code ist, den ich so fabrizier.
Und ich kann noch, äh, als, als letzten Kommentar, oh je, ja, wer weiß, was wir, keine Ahnung, will man gar nicht wissen, ne, ähm, aber wir reden ja heute noch drüber.
Genau.
Ähm, genau, so, jetzt hab ich den Faden verloren, was wollte ich eigentlich jetzt noch dazu sagen? Sag mal, Konstantin.
Bin ich wieder reingegrätscht, hab ich wieder?
Ja, du hast, du hast alles wieder kaputt gemacht, ah mein, wir schneiden's nicht raus.
Dann sind wir, wir waren bei der These mit dem Inside-Job, glaub ich.
Ja.
Ähm, egal, egal, wird nicht so wichtig gewesen sein, wenn's mir später wieder einfällt, dann, dann kommt's noch.
nach.
Genau.
Dann, äh, wenn ich das Knöpfchen finde, machen wir doch direkt weiter.
Die Property der Woche.
Auf die Property der Woche bin ich gestoßen über, äh, CSS Battle.
Da hat uns in, in unserem Discord jemand, äh, draufgeschickt.
Und das ist, wer das nicht kennt, äh, man kriegt ein Bild, 400x300 Pixel, und muss versuchen, mit CSS und HTML das nachzubauen.
Und, ähm, das wird dann durch ein, durch ein Headless Chrome irgendwie gerendert und abgeglichen, und man muss halt möglichst nah da dran kommen.
Also 100% erreichen und das Ganze mit möglichst wenig Zeichen.
Und, äh, das macht, macht Spaß und man, man lernt, äh, neue Tricks kennen in CSS, die man noch nicht kannte.
Und so bin ich auch auf dieses Offset Property gestoßen.
Äh, und wer mich, wer mich da mal hinzufügen will, man kann so Freundeslisten anlegen, da kann man seine Scores vergleichen.
Den Link packe ich auch in die Shownotes.
Und gestoßen bin ich da auf das, äh, Property Offset.
Und das ist ein Shorthand Property für Offset Anchor, Offset Distance, Offset Path, Offset Position und Offset Rotate.
Und ich hab noch nichts davon gehört.
Habt ihr das schon mal gehört, wisst ihr, was das ist?
Ich kenn das auch nicht.
Nee.
Aber ich hab noch auf der Arbeit auch C++ und nicht CSS.
Ja, okay.
Jedenfalls, ähm, ist das, also bei CSS Battle war's für was ganz komisches verwendet, was ich immer noch nicht durchstiegen hab, was da genau passiert.
Aber ich hab mich so ein bisschen gewundert, okay, Offset Path ist eben das eine Property, das damit inbegriffen ist.
Und das war dann auch Offset Doppelpunkt Path, Klammer auf, und dann in einfachen Anführungsstrichen M20,20, Leerzeichen C20,10.
Und ich dachte, hm, das klingt nach SVG.
Und das ist tatsächlich so, dass man da einen SVG-Pfad angeben kann.
Und, äh, für was das Ganze am Ende da ist, ist ein Element entlang eines Pfades.
Also das kann ein SVG-Pfad sein, kann aber auch, ähm, ein SVG, also ein Element in einem SVG referenziert sein per URL und über die ID von dem Element.
Oder einfach nur ein Strahl oder irgendwelche anderen CSS-Shapes.
Und ich kann dann mit Keyframes und dem Animation Property mittels dem Offset Position, das ich dann von 0 bis 100 Prozent, äh,
eben animieren kann, kann ich dieses Element entlang dieses Pfades bewegen.
Also wirklich CSS-native, ähm, Animation von Elementen.
Und das fand ich irgendwie krass, dass ich davor noch nie was davon gehört hab.
Ähm, ich guck mal hier auf Can I Use.
Ich glaube, es ist nämlich, na, 76 Prozent der Edge und Chrome und Firefox können's, Opera kann's, Safari kann's nicht, auch nicht im Technology Preview.
Ähm, das heißt Safari mal wieder so das Schlusslicht.
Ansonsten sieht das echt ganz, ganz cool aus.
Ja, und auch relativ witzig.
Also von der Funktionalität hätte ich auch einfach keine SVG-Pfad in CSS erwartet.
Ja, richtig, richtig.
Ich find's nur ein bisschen schwierig, dass dann, ähm, also ich hab versucht, damit rumzuspielen, weil ich wissen wollte, was die da genau gemacht haben, um diesen Effekt zu erreichen, den die da gemacht haben.
Ich, ich steig nicht so ganz durch. Ich hab mir den Pfad dann in SVG kopiert, aber irgendwie, äh, wurde da auch nix angezeigt.
Also ich frag mich, wie man da ohne Tooling das schafft, dann tatsächlich, ähm, das in der Seite jetzt einzubauen.
Also ich muss ja dann, dann schon irgendwie eine grobe Vorstellung haben, wie verläuft dieser Pfad.
Also mach ich mir vielleicht erstmal dann so ein Outline-Red oder so, dass ich überhaupt irgendwas sehen kann.
Ähm, ich kann's mir in der Praxis noch nicht so ganz vorstellen, aber es ist cool, dass es das gibt.
Dann braucht man nicht mehr solche, so CSL, äh, JS-Libraries wie Greensock oder so vielleicht für einfache Animationen.
Ähm, also bin mal gespannt. Ich hab jetzt noch keine richtig geilen Demos gefunden, nur so diese MDN-Geschichten, wo einfach so ein Pfeil da entlang fliegt.
Aber man kann zum Beispiel mit diesem, ähm, Offset-Rotate auch wirklich sagen, dass der Pfeil sich dreht, während er diesem Pfad folgt.
Und so, ne, das ist ja nicht statisch, einfach nur das Element fliegt rum, sondern es dreht sich dann auch in die entsprechende Richtung.
Ähm, das fand ich, fand ich ziemlich cool.
Das ist in der Tat sehr cool. Was ich mich gerade frage, ist, ähm, hat jemals jemand schon mal diese, ähm, SVG-Path-Syntax manuell geschrieben?
Also ich hab den schon ganz oft gelesen und für mich war immer so, aha, ja, das ist wohl Maschinengeneriert, aber ich weiß überhaupt gar nicht, was der besagt, ehrlich gesagt.
Von daher, ich bin gerade immer davon ausgegangen, dass das, äh, okay.
Ne, also ich glaube, es gibt tatsächlich SVG-Cracks, die das können. Also ich weiß halt nur, dass, ähm, ich glaub, Großbuchstaben und Kleinbuchstaben ist der Unterschied, ob es dann absolut oder relativ positioniert ist, aber ich kann dir jetzt nicht mal sagen, äh, was davon was ist, ob jetzt groß oder klein.
Und dann hast du halt, ähm, einfach Pixelwerte. Aber das ist ja bei SVG auch immer nicht so einfach, was, was ist jetzt ein, oder eigentlich Koordinaten eben, nicht mal zwangsweise Pixel.
Weil es gibt ja noch ein Viewport-Attribut, dass das dann nochmal beeinflusst, wie das skaliert wird. Und da kann ich mir eben auch noch nicht vorstellen, muss ich da was berücksichtigen, wenn das auf der Sky-Seite irgendwie skaliert und so.
Also wie das am Ende, wie ich da, ich sag jetzt, ich möchte das so und so animiert haben und wie ich dann da hinkomme mit dem Pfad, den selber zu schreiben und so, ist mir auch noch so ein bisschen ein Rätsel.
Ja, aber haben es besser als brauchen.
Ja, und das war's eigentlich auch schon. Also vielleicht, wenn jemand alten Code noch findet, so alte Demos oder Artikel da drüber, es hieß mal ursprünglich, äh, Motion, also die ganze Speck nennt sich auch Motion Path Module und, ähm, das hieß, äh, da gab's dann Attribute, die klangen so wie die jetzigen, also statt Offset Anchor dann irgendwie Motion Anchor, ähm, Offset Rotate hieß, glaub ich, Motion Rotation.
Ähm, also falls man da drauf stößt, das ist das gleiche wie dieses neue Offset. Ja, und das war's eigentlich auch schon dazu.
Cool. Vielen Dank.
Ja, und jetzt haben wir ja was, was Neues mal tatsächlich, ne?
Ah, stopp, stopp, ich hab noch, ich hab noch, ich hab noch, es kommt noch schnell was zwischen rein, bevor das Neue kommt, bevor das Neue kommt mit dem neuen Jingle, weil wir das jetzt noch gar nicht so richtig gemacht haben, ähm, wir haben unseren Gast noch gar nicht so richtig vorgestellt, äh, stimmt, ja, ähm, ich wollte noch sagen, ja, also, äh, ich, ich find, ich find's immer, ähm, doof, wenn man sich selbst vorstellen
muss, ich stell dich jetzt nur so ganz, ganz grob vor, was man so auf deiner Webseite über dich lesen kann, also, Frederik Braun ist bei uns heute zu Gast, äh, und er ist Staff Security Engineer bei Mozilla, ähm, und da über seine Arbeit und was er da so macht, teilweise reden wir dann gleich noch im Thema, ähm, genau, und jetzt, um dich ein bisschen besser kennen zu lernen, äh, Frederik, äh, haben wir uns eine neue Rubrik ausgedacht, ein neues Spiel.
Das, äh, das, äh, du weißt, du weißt schon, ich hab's dir vorher schon gesagt, gell, äh. Ich spiel mal den Jingle und dann erklärst du kurz, um was es geht, oder?
Alles klar, genau.
W-W-S-I-V. Entscheide dich.
Genau, entscheide dich, also, es ist, äh, ich bin jetzt ganz ehrlich, ähm, es ist ein Rip-Off von zwei verschiedenen Dingen, ein Ding, das entscheide dich heißt, nämlich beim Neomagazin, äh, Royal hatten die das mal, entscheide dich, allerdings werden da so mehr so lustige Quatschfragen,
und dann gibt es bei dem, äh, hab ich ja schon öfter erwähnt, der Podcast, ähm, alles gesagt von, von der Zeit, von der Zeit, von der Zeit, von der Zeitung Die Zeit, ähm, haben die ein Thema, die nennen das A, B oder Weiterspiel und ich find den Namen fürchterlich, äh, aber das Spiel ist gut, fand ich, und, ähm, ich glaube, das ist vielleicht ganz gut, um unseren, ähm, allgemein, um Gäste, äh, ein bisschen besser kennenzulernen, bevor man so tief ins Thema einsteigt.
Und das Spiel funktioniert so, ähm, es sind ganz einfache, schnelle Entscheidungsfragen, äh, sowas wie CD oder USB-Stick, äh, frag ich, und dann sollst du möglichst schnell antworten, was dir als erstes sofort in den Sinn kommt, eins von beiden, also dann CD oder USB-Stick eben, ähm, ähm, und dann geht's sofort weiter mit der nächsten Frage.
Es gibt auch keine Erklärung, ist nicht erlaubt zwischendrin, kann man gerne im Anschluss drüber sprechen, warum, falls, äh, äh, manchmal haben die Leute, äh, des Bedürfens sich zu, zu, dazu zu erklären, warum, warum sie sich für was entschieden haben, ähm, und man darf auch weitersagen, äh, aber, ähm, nur zehn Prozent, äh, der Fragen darf weitergesagt werden, ich hab jetzt grad nochmal nachgeguckt, das sind, glaube ich, warte, Moment, äh, äh, äh, du darfst dreimal weitersagen, Konstantin zählt mit.
Ich zähle mit.
Mhm.
Genau, und wir machen das, und es geht ganz flott.
Äh, äh, und jetzt geht's los.
Katze oder Hund?
Katze.
Butterfly oder mechanisch?
Äh, Butterfly.
Papier oder E-Book?
Papier.
Besitzen oder streamen?
Ähm, besitzen.
Besitzen oder streamen?
Besitzen.
Luke oder Han?
Luke.
Dark-Mode oder Light-Mode?
Dark-Mode.
RGB oder Hex?
RGB.
Pixel oder Vektor?
Warte mal, Hex ist doch RGB, Pixel oder Vektor, ich kann nur Pixel.
Okay.
Schwarz oder Weiß?
Schwarz.
Black-Hat oder White-Hat?
Ja, White-Hat.
W3C oder Watt-WG?
Ähm, beides in meinem Fall tatsächlich.
W3C oder Watt-WG?
Ich arbeite bei beiden mit.
W3C oder Watt-WG?
Du kannst weiter sagen.
Weiter.
Nano oder VI?
VI.
E-Max oder VI?
VI.
Yubi-Key oder Passwort?
Weiter.
Passwort oder SSH-Key?
SSH-Key.
iOS oder Android?
iOS.
Mac OS oder Linux?
Linux.
So, hast schon geschafft.
Brauchst du noch so ein Bing?
Ja, aber ich hab hohe Rechtsfertigungsbedarf.
Bei weiter brauchst du noch so ein Bing-Sound.
Das ich für gar nichts rechtfertigen.
Alles gut, du kannst gerne.
Das stimmt.
Man müsste eigentlich so Bing-Sounds haben noch.
Das stimmt.
Ja, wie gesagt, hohe Rechtsfertigungsbedarf.
Oder so ein Wasser so.
Bei sowas wäre es total lustig, ja genau, richtig und falsch zu bewerten, obwohl es kein richtig
oder falsch gibt.
Das ist auch richtig assi, da wird es natürlich auch nicht mehr schlimm.
Okay, vielen Dank, dass du dich drauf eingelassen hast.
Ja, witzig.
Ja, genau.
Ich muss mich beschweren.
Ich bin tatsächlich bei iOS, aber ich bin auch mit iOS nicht zufrieden, um das nochmal
hier ganz ausdrücklich zu sagen.
Und ich pendel so hin und her.
Ich finde es auf iOS mega ärgerlich, dass ich nicht den Browser meiner Wahl benutzen darf
oder nicht die Rendering-Engine meiner Wahl.
Den Browser meiner Wahl kann ich ja mehr oder weniger schon benutzen, aber es ist halt
alles Webkit.
Und bei Android gibt es halt viele andere Probleme.
Also entweder kaufe ich mir jedes Jahr ein neues Handy oder ich kriege nicht ordentliche
Updates und ich muss meinen kompletten Datenschutz irgendwie aufgeben, was ja bei iOS ein
Tacken besser ist, aber jetzt auch nicht unfassbar geil.
Und ich könnte jetzt richtig abranten, aber dafür bin ich ja nicht in der Show.
Aber leider ist es ja bei Mobiltelefon so, man muss sich für eins entscheiden.
Da ist es ja wirklich entweder oder.
Da gibt es kein weiter.
Ja, Firefox OS.
Ja, das war cool.
Das war echt cool.
Technisch gesehen.
Das hat natürlich auch seine Tücken.
Ich habe tatsächlich an Firefox OS mitgearbeitet.
Von daher bin ich dann natürlich mega biased.
Ja, da haben wir mit Chris Heilmann auch drüber gesprochen.
Der war ja dann auch involviert.
Das habe ich tatsächlich als Vorbereitung gehört.
Das war echt eine mega coole Zeit.
Und ich glaube, so witzig, so witzig wie das jetzt ist, wenn man sich anguckt, was für
Web APIs in den letzten Jahren dazugekommen ist, Firefox OS war einfach zu früh.
So, die ganzen APIs, wo wir damals gesagt haben, oh krass, wie erfinden wir die jetzt?
Wie machen wir die ergonomisch?
Wie bauen wir die in unsere eigenen Apps ein?
Wie erklären wir das Entwicklern, die Apps für uns schreiben sollen?
Die gibt es halt jetzt alle.
Und da gibt es dann halt mehr oder weniger gute Anleitungen und Spezifikationen zu.
Von Device Motion bis hin zu, habe ich vergessen.
Gibt es jetzt einfach.
Ja, ich hatte damals auch den Eindruck, dass Firefox OS ein extremer Innovationstreiber war, was
APIs anging, weil wenn du in US auf dem Browser basierst, brauchst du ja, musst du ja irgendwie
aufs System kommen bei allen möglichen Sachen.
Ja, voll.
Und das fand ich total, also mein Liebling aus der Zeit ist immer noch die Vibration-API,
wobei ich gar nicht sicher bin, ob die überhaupt noch irgendwo unterstützt wird.
Aber das fand ich total faszinierend, dass du irgendwie mit so einem kleinen Array mit so
Zeitangaben sagen kannst, jetzt vibriere mal so und so.
Das ist total cool, dass ich plötzlich sowas mit dem Handy machen konnte.
Keine Ahnung, ob die irgendwo.
Ja, ja, es gab auch relativ viele coole HTML5-Games, die da so raus entstanden sind aus eben
diesen APIs, weil viele Leute gesagt haben so, ich will mal was machen, aber ich weiß nicht,
was ich machen soll, ich probiere mal, ich fange mit dem Spiel an.
Und es sind echt ein paar witzige rausgekommen, die dann halt so obskure Interaktionen haben
mit Vibrate und so weiter.
Aber das wurde ja leider nichts.
Also es lebt weiter als, wie soll ich sagen, nicht als Smartphone-Betriebssystem, sondern
eher so als internetfähiges Feature-Phone-Betriebssystem.
Ich habe noch so ein altes Android rumliegen.
Vielleicht gibt es irgendwie eine Möglichkeit, da was drauf zu spielen.
Das wäre irgendwie spaßig.
Also ich würde es total gerne mal benutzen.
Ich habe immer nur den Simulator benutzt und habe dann so gedacht, Mensch, das mal auf
einem echten Gerät zu benutzen.
Vielleicht sollte man es irgendwann nochmal weiterentwickeln, weil es ist ja so die richtige
Philosophie dahinter, so aus meiner Sicht.
Grundgemäß ist es relativ schwierig, das auf Geräte zu bringen, weil du immer so Treiberprobleme
hast.
Das Einfachste ist, glaube ich, tatsächlich, wenn du in so eine Telefonbude in der Innenstadt
gehst und dir so ein, dir vorher eine Einkaufsliste macht, welche Telefone das sein können.
Es gibt ein paar von, ich glaube sogar von Nokia, dieses gelbe Bananen-Phone wurde wieder aufgelegt
und da ist tatsächlich ein KaiOS drauf.
Das ist der inoffizielle Nachfolger.
Also die haben es geforkt und verkaufen es relativ erfolgreich in, ich glaube, Indien, Indonesien
und so weiter als Feature-Phone.
Die verkaufen es nicht als Smartphone, aber es ist halt internetfähig und es ist komplett
HTML5-JavaScript basiert.
Und das ist relativ cool, aber es kann halt nicht so viel wie ein Smartphone, aber es kann
halt definitiv mehr als so ein Feature-Phone, wie so ein Knochen.
Da kann man ein bisschen Spaß mit haben tatsächlich, aber es ist halt auch sehr obskur.
Aber in Indonesien, oder ich bin mir nicht sicher, was deren Hauptmarkt ist, aber da sind
die tatsächlich irgendwie so das zweitbeliebteste Betriebssystem für Mobiltelefone, was schon
relativ cool ist.
Hinter Android natürlich, die auch einfach irre günstig sind in den Kategorien dort.
Ja, spannendes Thema.
Also wer mehr darüber noch hören will über Firefox OS, in unserer Folge mit Chris Heilmann,
Nummer 27, gerne mal reinhören.
Judi, dann kommen wir jetzt tatsächlich echt zum Thema.
Jawohl.
Und ich habe wieder das falsche Fenster offen und Moment.
Soll ich?
Nee, ich mache.
Hier ist WWS IV mit dem Tagesthema.
Wir haben es vorhin schon so angekündigt, so ein bisschen, dass es um was Sicherheitstechnisches
geht.
Genau.
Und ich weiß nicht, ob man das verstanden hat, was ich da am Anfang vor dem Intro überhaupt
gefaselt habe.
Wir desinfizieren das Internet.
Also die Anspielung war Hand Sanitizer, nennt man auf Englisch solche, diese, was man halt
gerade in Corona-Zeiten immer hat, dieses Handdesinfektionsmittel.
Deswegen, es geht um die HTML Sanitizer API.
Genau, und dafür haben wir unseren Gast eingeladen.
Und vielleicht nochmal so als kurze Einleitung dazu, ich erinnere mich, dass wir mal sehr,
das ist sehr, sehr lange her, in diesem Podcast über Security gesprochen haben und wo ich dann
gesagt habe, Mensch, es müsste doch irgendwie so eine native API geben, wo ich irgendwie Code
reinschmeiß und am Ende irgendwie was Sicheres rauskommt.
Das müsste doch der Browser machen können.
So lange ist das noch gar nicht her.
Das war im Juni.
Folge 28 haben wir das schon mal angesprochen.
Nee, das, was ich meine, das war noch viel früher.
Noch, noch früher, okay.
Das war noch, das war eine andere Folge.
Weil über die, über die Sanitizer API haben wir schon mal kurz, haben wir schon kurz angerissen.
Ja genau, aber damals, in dieser Folge, die ich meine, das suche ich nochmal raus, wann
das war, da wusste ich noch nicht, dass es die API gibt.
Im Anschluss daran wurden wir per Twitter drauf hingewiesen, ey, das, was du dir da wünschst,
das gibt es doch schon.
Hier, guck mal, da gibt es diesen, diesen Draft, lies doch mal.
So sind wir da überhaupt mal drauf gestoßen.
Und ich dachte, ah, cool, das ist genau das, was man eigentlich haben will.
Und interessanterweise, ähm, hab ich dann gesehen,
das, was man, das, was man immer gesagt kriegt dann, wenn man ein JavaScript verwendet,
was man dann nehmen soll, ist Dom Purify.
Und, äh, das ist die, wenn ich es richtig gesehen hab, um jetzt nicht zu viel vorweg
zu nehmen, ähm, das ist auch so ein bisschen Vorbild für diese API, wenn ich es richtig
verstanden hab.
Aber da können wir jetzt gleich noch ganz tief drin einsteigen, genau.
Vielleicht erzählst du einfach mal, wie es dazu gekommen ist, dass ihr angefangen habt, diesen
Standard zu entwickeln.
Also, es gibt so eine, es gibt so eine, es gibt so eine spezifische Geschichte für den Standard, aber
es gibt so eine persönliche Geschichte und das ist relativ witzig, weil bei mir fängt
es mehr oder weniger auch mit Firefox OS wieder an.
Wir haben nämlich gemerkt, dass wir an ganz vielen Stellen das Problem haben, dass wir eigentlich
User-Generated Content in irgendeiner Form erlauben wollen.
Aber wir wollen halt nicht beliebiges HTML in der Form erlauben, als dass dann, ähm,
die, äh, das ganze Markup, die ganze Webseite irgendwie, die ganze Web-App, die ganze Mobile-App
in dem Sinne, ähm, abschmiert und da jemand Skripte einfügt und so weiter, äh, sondern wir
wollten halt sagen, wir wollen bestimmtes HTML erlauben.
Und damals hatten wir schon gesagt, so, mh, eigentlich wäre das geil, wenn es einen Sanitizer
gab.
Und ich hab mal für Spaß rausgeguckt, es gab eine Mailing-Listen-Diskussion zu dem Thema, müsste
doch mal jemand machen im Jahr 2012.
Ähm, hat aber leider damals keiner gemacht.
Und, ähm, genau.
Und, ja, das, das Thema ist so ein bisschen in mir gereift, einfach, einfach über die
Zeit und es ist, ähm, weiß nicht, müssen wir, sollen wir vielleicht nochmal kurz über
Cross-Site-Scripting sprechen eigentlich?
Macht das nochmal Sinn?
Ja, auf jeden Fall, ja, das, ja.
Unbedingt.
Dann machen wir das vielleicht.
Die Frage ist eigentlich, ja, wozu braucht man das überhaupt?
Genau, das ist, glaube ich, das, ähm, das Schönere mit dem Anfang.
Also, eine ganz typische und ich glaube, was, ähm, ähm, ähm, einfache Statistiken
angeht, ist es, glaube ich, tatsächlich die am häufigsten vorkommendste Schwachstelle
in Software im Allgemeinen.
Cross-Site-Scripting.
Der Name ist irgendwie aus den 90ern und ist auch eigentlich ein Kackname, denn ich glaube,
das richtigere Wort, wenn man es verstehen möchte, ist HTML-Injection oder Script-Injection, weil
das, was man nämlich hat, ist, wir gehen mal von einer ganz einfachen Webseite aus, da ist
irgendwie ein Formular und du tippst deinen Namen ein und dann sagt die Webseite, hallo,
Frederik oder wie auch immer.
Und, äh, wenn man da halt HTML reinschreibt, zum Beispiel ein offenes Script-Element und
dann JavaScript, ähm, und dann auf, auf Abschicken klickt, dann kriegt man halt nicht den
eigenen Namen zurück, sondern JavaScript und dann hat man ja im weitesten Sinne den Code
der Anwendung, auf der man gerade ist, verändert.
Das ist für den Fall, dass ich das halt selber eintippe und auf Absenden klicke, ist es
natürlich total banal und nicht besonders sinnvoll, aber, ähm, stellen wir uns einfach
vor, dass, äh, dass der Parameter ausgelesen wird aus einem URL-Parameter oder sonst was, ähm,
und beliebige Angreifer halt mit einem präparierten Link, also Opfer klickt auf Link, geht auf
die Webseite und es wird halt nicht irgendein Name angezeigt, sondern Script, die vom Angreifer
geschrieben wurden.
Das ist Cross-Sat-Scripting und Cross-Sat-Scripting hat das Potenzial halt wirklich deine komplette
Webseite komplett und vollständig umzugestalten, was daran liegt, dass, ähm, natürlich es
unheimlich viele, äh, Web-APIs gibt, wie natürlich jeder Frontendentwickler weiß, dass
man die Webseite halt einfach umschreiben kann, aber was halt noch ein bisschen abgefahrener
ist mit Technologien wie, wie Service-Workern, aber auch aufgrund der Tatsache, äh, dass es
Sachen gibt, wie Broadcast-Channel und Post-Message und natürlich iFrames und die Same-Origin-Policy,
bezieht es sich manchmal auch nicht einfach nur auf diesen einen Tab, sondern vielleicht
sogar auf alle Tabs, die in dieser Webseite geöffnet werden, solange sie Same-Origin sind.
Das heißt, ähm, was ein Angreifer machen kann, im einfachsten Fall ist natürlich einfach
Formulare umschreiben und dann werden irgendwelche Passwörter nicht dahin gesendet, wo sie eigentlich
hingesendet werden sollen, sondern vielleicht an den Server des Angreifers, ähm, und, äh,
aufgrund der Same-Origin-Policy, die ich vielleicht auch kurz erklären muss, aber die meisten kennen
es vielleicht, wenn ich ein, wenn ich ein Fetch mache oder wenn ich, ähm, oder wenn ich auf den
Inhalt eines iFrames zugreifen will, dann kann ich das eigentlich immer nur dann machen, wenn
die Webseite das gleiche Origin hat. Das heißt, ähm, wenn ich in iFrame lade, dann kann ich ja über das
iFrame-Element Content-Window, Content-Document auf das Dokument zugreifen und das geht eben nur, wenn die
beiden URLs Same-Origin sind. Und Same-Origin heißt, dass, ähm, das, ähm, das, äh, URL-Scheme, äh, und der
Hostname und der Port übereinstimmen. Das heißt, HTPSExample.com kann HTPSExample.com und dann irgendeinen
anderen Pfad als iFrame-Dingsen und dann können die sich gegenseitig über DEM-APIs verändern und
modifizieren. Das geht halt natürlich nicht, wenn die eine Webseite A ist und die andere Webseite B.
Genau. Und aufgrund dieser Same-Origin-Policy heißt halt auch, wenn du einmal JavaScript ausführst als
Angreifer auf einer bestimmten Webseite, dann kann man das benutzen, um sich mehr oder weniger
persistent als Angreifer für den jeweiligen Benutzer, ne, es ist ja immer nur auf der Nutzerseite im
Browser, ähm, sich über die ganze Webseite quasi ausbreiten über verschiedene Methoden. Ähm, und das
macht es halt relativ haarig. Und, ja, wie ich bereits gesagt habe, es ist, ähm, es ist eine der am häufigsten
vorkommenden Schwachstellen. Und wenn man halt einmal Scripting injiziert hat, dann kann man alles tun, was man
halt so tun kann. Und, ähm, Cross-Site-Scripting ist, ähm, ich hab mal, äh, ich hab mal in der Diskussion gesagt,
das ist einfach, einfach irre peinlich, wenn man bedenkt, dass das Web jetzt irgendwie ungefähr 25 Jahre alt ist
und HTML und JavaScript gibt's jetzt schon länger. Und wir haben es halt immer noch nicht gelöst. Und das ist halt,
einfach mega ärgerlich. So, und, ähm, und mit, äh, mit relativ neuen Trends, sag ich mal, für Single-Page-Application,
wobei es eigentlich ja schon mit Web, Keyword Web 2.0 und Ajax vielleicht angefangen hat, aber auch mit
Electron-Apps und so weiter, passiert halt immer mehr Logik und immer mehr Teil der Webseite funktionieren
halt im Browser und sind halt in JavaScript und im Frontend implementiert. Und halt nicht einfach nur, ähm, ähm, äh, Dokumente, die angezeigt werden
und das wirklich heavy passiert dem Backend. Nee. Es passiert halt immer mehr im Frontend und je mehr Code man hat,
umso wahrscheinlicher ist es, dass man mal einen Fehler macht. Und von daher ist, ähm, ist Cross-Site-Scripting
halt auch ein bisschen ein größeres Problem geworden. Nicht nur, weil, weil es häufig vorkommt,
sondern weil der Impact ein anderer ist, ne? Weil, weil es wahrscheinlicher ist, dass es vorkommt.
Und wenn du in der Electron-App, ähm, Cross-Site-Scripting hast, witzigerweise, hast du Zugriff auf ganz, ganz andere
APIs, weil Electron ja eine native Anwendung ist im Betriebssystem und du kannst tatsächlich damit,
kannst tatsächlich mehr oder weniger in den Computer damit hops nehmen und nicht einfach nur so, äh,
da werden jetzt die Passwortformulare oder so geklaut. Also das ist richtig, ist richtig hässlich.
Cross-Site-Scripting, das hätten wir eigentlich gerne, hätten wir eigentlich gerne gelöst.
Also das ist so ein Teil der Motivation. Ähm, und ein anderer Teil der Motivation ist, ähm,
einfach, dass ich am Thema Cross-Site-Scripting und Web-Sicherheit sehr, sehr lange arbeite.
Also ich habe schon zu Studienzeiten habe ich mich sehr mit Web-Security beschäftigt und fand es immer irgendwie spannender,
mir den Browser-Teil anzugucken. Also JavaScript und Frontend und was kann man da machen,
und was gibt es für neue APIs und was kann man damit für Schindluder treiben und was passiert,
wenn man da hier irgendwie was eingibt, was eigentlich nicht sein sollte und so weiter.
Und, ähm,
naja, das hat mich dann irgendwann halt am Anfang meiner Karriere zu einem Praktikum und dann zu einer Vollzeitstelle bei Mozilla geführt
und dann habe ich auch noch viel Web-Sicherheit gemacht und dann halt irgendwann Firefox OS
und jetzt schlussendlich, ähm, arbeite ich an, an GECO, also der Rendering-Engine von Firefox,
dem Browser selber.
Und ich habe halt immer gedacht, so, pfff, das muss doch mal, irgendwie muss man sich überlegen, wie man das löst.
Und es gibt ja auch super viele Ansätze und es gibt ja auch viele, die es mehr oder weniger erfolgreich gelöst haben.
Es ist ja nicht so, als wäre das ein, ein, ich sag mal, von akademischer, wissenschaftlicher Perspektive ein ungelöstes Problem.
Das ist es ja gar nicht, ne?
Also, wenn du wirklich nur Namen annehmen möchtest, zum Beispiel in deiner Webseite,
dann erlaubst du halt auch nur typische Zeichen für Namen.
Und das ist vielleicht nicht das kleiner oder größer Zeichen, was man für HTML braucht.
Ähm, und, ähm, dann gibt es natürlich Beispiele für bestimmte Frameworks,
die es einfach ganz, ganz wunderbar gelöst haben, indem sie dir komplett die Arbeit abgenommen haben,
wie du mit dem DOM und mit der Webseite sprichst.
Also, also Stichwort React, du machst ja in React, machst ja niemals irgendwas mit GetElementById oder in der HTML gleich oder so,
sondern das ist ja alles, alles in deinen React Components, die ganze Logik und wie dann nachher der DOM manipuliert wird
oder die Seite umgeschrieben wird, das macht ja komplett React.
Und dann weiß es halt, was ist Inhalt, was sind Daten und was ist Markup und was ist ein Template,
das der Entwickler geschrieben hat und kann es halt sehr, sehr schön auseinanderhalten.
Heißt aber auch für mich als Entwickler, ich muss mich darauf verlassen können, dass die Library das auch entsprechend richtig macht.
Und wenn es halt doch mal eine Lücke gibt und durch die Verbreitung von React und anderen Libraries ist die dann halt im Endeffekt in Millionen von Seiten drin.
Und wenn die dann nicht rechtzeitig aktualisiert werden, dann habe ich da eventuell ein großes Problem.
Völlig richtig, das hast du natürlich bei React wie bei jeder Library auch, genau.
Und genau, also wenn du ein Framework hast, was dir die komplette DOM-Interaktion abnimmt, dann ist es natürlich mega gut.
Dann ist es relativ einfach zu lösen.
Und dann gibt es natürlich viele punktuelle Lösungen, wo man sagt, ich mache hier mal irgendwie ein Escaping
oder ich ersetze Zeichen durch Entities und dann ist es vielleicht nicht scharf gestellt.
Und dann gibt es von einem guten Freund von mir, von Mario Heiderich, natürlich auch die Library DOM-Purify,
die das Ganze in JavaScript implementiert, dass ein String angenommen wird, zu HTML geparsed wird.
Dann wird dieser kleine Document-Tree quasi abgelaufen und dann werden Elemente, die nicht erlaubt sind, rausgeworfen.
Also du übergibst ein String, zum Beispiel Paragraph-Element, bla bla bla, Paragraph-Element schließt
und dann wird das in HTML geparsed und dann ist HTML ja normalerweise ein Baum und dann wird er halt abgelaufen.
Und dann gibt es eine Liste von guten und eine Liste von bösen HTML-Elementen.
Und dann kannst du halt einfach sortieren, bevor du es in dein Dokument schiebst.
Und das sind so all die Dinge, die so in dem Kontext existieren
und es gibt auch relativ viel, was gut funktioniert, serverseitig mit Template-Libraries verschiedenster Art.
Manche machen es gar nicht, manche machen es richtig gut.
Ein gutes Beispiel, was ich noch kenne, ist zum Beispiel das Templating in Django
und ich habe länger kein Django mehr gemacht.
Ich glaube, es ist immer noch Ginger 2, vielleicht liege ich falsch.
Aber Ginger 2 macht es gut und ich weiß, es gibt noch ein anderes.
Und ich glaube, dass Ginger 2 vielleicht nicht gerade der Standard in Django ist.
Jedenfalls wird dann einfach escaped.
Ich weiß es doch nicht.
Wir arbeiten mit Django, aber so tief bin ich da nicht drin.
Mein Punkt ist jedenfalls, es gibt auch relativ viele gute Templating-Libraries, die das im Backend machen.
Was sich aber herausgestellt hat, und da hat tatsächlich auch mein Freund Mario Heidrich relativ gute Arbeit gemacht auf der akademischen Seite im Rahmen seiner Doktorarbeit,
die jetzt auch schon einige Jahre her ist,
wo er Stück für Stück über verschiedene Angriffe und verschiedene Methoden entwickelt und herausgearbeitet hat,
dass es auf wirklich grundlegender theoretischer Basis kaum bis gar nicht möglich ist,
dieses Escaping und Encoding garantiert sicher im Backend zu tun.
Weil du nämlich immer das Problem hast, dass du mit einem potenziell anderen Browser sprichst, als du denkst.
Und jeder Browser ja immer so ein kleines bisschen unterschiedlich ist.
Und sobald der Server halt denkt, ich parse das HTML mal so und baue das mal um und das wird schon passen,
dann macht er halt eine Annahme darüber, wie der Browser das tut.
Und das kann halt falsch sein.
Ja, das ist ja so ganz beliebt.
Und sobald das falsch ist, baust du halt, was die Hacker, da gibt es auch ein schönes Paper zu,
was man mal lesen kann, wenn schlechtes Wetter ist, kommt ja jetzt der Herbst,
baut man eine sogenannte Weird Machine und die lässt sich im weitesten Sinne auch irgendwie programmieren oder entwickeln.
Und dann schreibst du halt ein mega abgefucktes Markup, was aber genau so gebaut ist,
dass es der Server so versteht und der Browser so versteht und dann macht es halt doch wieder Knall.
Als der beliebte Angriffsvektor so mal einen uralt Browser nehmen,
der bestimmte Sicherheitsrichtlinien nicht hat und dann mal gucken, was so zurückkommt.
Da gibt es einige interessante Sachen in der Richtung.
Ja, voll.
Und was ich dann für mich irgendwie, ich weiß nicht, entschieden oder begriffen habe, ist,
ich habe gedacht, es ist cool, dass es viele richtig machen,
aber wenn du es richtig machen willst,
dann musst du halt tatsächlich doch vielleicht das ein oder andere Paper lesen
und ein bisschen vergleichen und Libraries und das kannst du halt irgendwie keinem zumuten.
Und dann habe ich gedacht, ich meine, das Wichtigste, was so ein Sanitizer macht,
ist ja HTML-Parsing und ein bisschen durchsortieren.
Das ist an sich nicht schwierig, aber andererseits, ich muss mal kurz meine Katze aus dem Zimmer jagen,
die macht ja gerade wahnsinnig, die hat irgendwas zum Spielen entdeckt.
Ihr habt bestimmt witzige Übergangsmusik, ich bin gleich wieder da.
Jetzt wird es aufgehört.
Jetzt wird es wieder Witz rausgraben.
Witzig.
Mir war das relativ wichtig, diesen einen Punkt zu machen.
Jetzt bin ich raus.
Nee, warte.
Also meine Erkenntnis oder meine Schlussfolgerung aus dieser ganzen Komplexität ist eigentlich,
HTML-Parsing macht der Browser schon die ganze Zeit.
Und das kann der Browser relativ gut.
Das ist so das Hauptding, warum wir den bauen.
Und ich glaube, das sollte einfach nicht in der Verantwortung eines Entwicklers sein.
Also wenn du eine Web-Anwendung baust,
dann sollte Cross-Sat-Scripting nicht komplett allein dein Problem sein.
Dann sollte es nicht heißen, ja, da gibt es ein Problem, muss er halt lösen.
Das ist nicht unser Bier.
Das passt mir halt nicht.
Und ich habe für mich das hohe Ziel und ich glaube, dass das auf jeden Fall schwierig wird zu erreichen.
Aber ich glaube, also ich weiß, das ist ein steiniger Weg,
aber ich glaube, es ist möglich, so weit zu kommen, zu sagen, wir geben die Verantwortung ab.
Also die Entwickler sagen, ich muss mich darum nicht kümmern.
Es gibt eine Schnittstelle im Browser, die kann ich benutzen.
Und der macht das für mich.
Und der macht das nicht nur für mich und meine Webseite,
sondern der macht das auch für mich und meine Webseite
und exakt den Benutzer, den ich gerade habe.
Weil du halt nicht diesen Fehler oder diesen Mismatch haben kannst
zwischen zwei unterschiedlichen HTML-Parsern im Backend oder in der Library
versus das, was der Browser tatsächlich versteht oder verstehen möchte,
sondern du kapselst das einfach.
Du sagst halt, das ist die Aufgabe des Browsers, nur der kann das, der kann das gut.
Und wenn der das nicht gut macht, dann ist es halt ein Problem des Browsers
und nicht ein Problem von jeder Webseite da draußen, von denen es halt einfach viel zu viele gibt.
Als dass man sagen könnte, ja, da müssen wir halt alle beheben, das geht ja nicht.
Und im Worst Case, ich weiß nicht, ob wir das für einen Sanitizer-API-Bypass machen würden,
aber im Worst Case kann halt so ein Browser-Update innerhalb von 24 Stunden verfügbar sein.
Und dann ist es halt nicht ein Problem, was du in deiner Webseite lösen musst.
Und das ist so eine Welt, wo ich unheimlich gerne hinwürde.
Cool.
Und das ist so die Motivation.
Ja, ja, ja.
Wie gesagt, es ist ein steiniger Weg und ich gehe noch.
Aber ich denke, es ist einfach an der Zeit zu sagen,
das kann nicht jede Webseite.
Und dann good luck, so, versuch halt mal.
Das passt mir irgendwie nicht.
Genau, das ist so ein bisschen die Motivation.
Jetzt habe ich ganz schön tief ausgeholt, aber ich hoffe, das wird einigermaßen klar.
Ja, ich kann noch kurz nachtragen.
Die Folge, in der ich mir das gewünscht habe, dass es das gibt,
das war die Folge Nummer 17, Tagged Template Literals.
Darum ging es.
Und der Zusammenhang war, genau, der Zusammenhang war,
naja, diese Template Literals, die sind ja eigentlich eine coole Sache in JavaScript,
aber wenn man damit HTML baut, was eigentlich ziemlich bequem ist damit,
also so, dass es wirklich zum Templating, zum HTML-Templating nimmt,
dann hast du das Security-Problem ist dadurch nicht abgenommen.
Das ist immer noch genauso da wie vorher.
Wenn du die wieder in die Seite reinpackst, hast du genauso ein Problem.
Darüber haben wir da gesprochen, habe ich gesagt, hey, das wäre doch super.
Und es gibt DOM Purify und will man aber nicht immer sich eine JavaScript-Library
dafür noch reinziehen?
Ja, klar, sollte man machen, will man aber vielleicht nicht immer.
Und dann wurden wir in den Kommentaren darauf hingewiesen,
dass es das doch irgendwie gibt.
Und da wurde auch schon der Draft damals verlinkt.
Das war am 16.11.2020 kam der Kommentar.
Genau.
Ja, genau.
Mit Template Strings.
Ja, geht so.
Ich komme wieder.
Ich kann auch einen schlechten Dead-Joke erzählen,
wenn du noch dafür ein bisschen Zeit brauchst.
Mach mal.
Oh, warte mal, jetzt habe ich meinen Einsatz verpasst.
Warte, ich habe noch einen.
Ich habe noch einen.
What do you call a pile of cats?
A mjaunten.
Wow.
Das ist ein gut vorbereitet hier.
Wir können alles überbrücken.
Herrlich.
Okay, gut.
So, ich glaube, die Katze benimmt sich jetzt.
Okay.
Ist eigentlich ein Kater übrigens.
Ah, okay.
Und wenn er gleich aktiv am Podcast teilnimmt,
stelle ich ihn vielleicht auch noch vor.
Aber wir versuchen es mal ohne.
Aber wir können auch mal eine Folge mit ihm machen.
Kannst du ihm sagen?
Dann gibt er jetzt Ruhe.
In der nächsten Folge sei dann offiziell eingeladen.
Wie sieht eigentlich so ein Headset für eine Katze aus?
Das muss man irgendwie noch erfinden, glaube ich.
Das stehe ich mir relativ witzig vor.
Jetzt wird es ihm zu blöd.
Ja, geil.
Ja, das war auf jeden Fall so.
Wie seid ihr drauf gekommen und was ist so der Hintergrund zur API?
Genau.
Den nächsten Punkt musst du ja mal uns erklären.
Das verstehe ich gar nicht, was du meinst.
Ja, das erkläre ich kurz.
Das kam nämlich aus derselben Richtung wie mein Wunsch damals.
Weil ich habe mal eine Stelle gebaut im Code, wo ich wusste, da kommt User-Generated-Content rein.
Also es ist immer Cross-Side-Scripting anfällig.
Und wollte da ganz, ganz, ganz sicher gehen, dass da kein Quatsch passiert.
Und dann habe ich unseren Security-Experten gefragt und er gesagt, ja, entweder nimmst du halt DOM-Purify oder eben DOM-Methoden.
Also du baust dein HTML nicht in einem Template irgendwie, in einem String, den du da am Ende rausgibst, sondern du baust dein HTML, lässt es den Browser quasi machen mit DOM-Methoden.
Das wird total eklig und hässlich, weil du machst jedes Attribut mit, äh, äh, warte mal, Add-Attribute, ich weiß gar nicht mehr genau.
Set-Attribute, ja, ja.
Ja, Set-Attribute, genau.
Und jedes HTML-Tag generierst du einzeln über DOM-Methoden.
Es wird ein fürchterlicher Spaghetti-Code, aber man kann so sich HTML zusammenbasteln.
Das habe ich damals gemacht.
Ja, aber das war einfach, wenn man das sich jetzt nochmal anguckt, es ist furchtbar, was dabei rausgekommen ist.
Und, äh, es wäre so viel einfacher gewesen, du baust dein HTML-Template einfach und, äh, schmeißt es gegen irgendeine API und dann, äh, raus damit und gut ist.
Das, das ist das, was ich noch meinte, ja.
Das ist super witzig.
Ich habe tatsächlich genau die gleiche Diskussion auch mal geführt und der Entwickler hat halt nicht gesagt, ja gut, dann mache ich es halt, sondern der hat gesagt, du bist ja bekloppt, das mache ich nicht.
Und dann habe ich tatsächlich, habe ich tatsächlich ein Tool geschrieben, ich müsste mal gucken, das gibt es bestimmt noch irgendwo.
Ich habe das genannt HTML2DOM.
Und dann gibst du einen HTML-String ein und der generiert der JavaScript-Code, der halt macht the Create-Element, äh, Reset-Attribute und dann, ähm, Append-Child und so weiter.
Aber das ist halt auch, muss man dazu sagen, ich sage mal 2012, war 2013er JavaScript.
Das heißt, es sind halt auch noch echt ätzende Methoden, um all diese Dinge zu machen.
Fantastisch, natürlich, es liegt total nahe, dass man das automatisieren kann, klar.
Hat mir auch mega viel Spaß gemacht zu schreiben, aber ich wurde nicht ernst genommen, ich wurde nicht ausgelacht.
Und der Code ist halt auch nicht schön, der generiert wird, also sorry.
Du kannst es vielleicht sagen, als Build-Step vielleicht, aber du kannst nicht den Leuten sagen, hier, ähm, mach das mal.
Man könnte auch, äh, bestimmte Files sagen, hey, da, als Build-Step, bitte mach, ja, doch.
Das war aber, glaube ich, auch vor der Ära, dass man, dass man irgendwelche Build- oder, oder Webpack-Tools hatte, von daher.
Aber wie würdest du das bewerten? Würdest du dann auch sagen, also DOM-Methoden verwenden, jetzt mal egal, wie hässlich das ist, ähm, das ist schon eher safe, oder?
Es hängt mega, mega davon ab. Also, ich möchte jetzt keine Allheilmittel versprechen, aber, ähm, erstens bin ich ein großer Fan von DOM-Purify, muss ich sagen.
Also, ähm, kann man ruhig mal verwenden. Die haben auch einfach einen guten Track-Record, was, was Security-Issues angeht.
Also, es werden halt mal welche drin gefunden, aber dann gibt's halt sofort ein Update.
Und die haben eine Mailing-Liste, wo du halt lesen kannst, es gibt ein Update, und dann machst du das halt.
Ähm, was, glaube ich, einfach im Vergleich mit jeder anderen Library, finde ich, schon einen Tacken, Tacken besser ist.
Und die sind halt, die haben halt einen guten Draht zur Security-Community.
Also, wenn jemand einen geilen Bypass findet, dann kriegen die das halt auch mit.
Und, ähm, klar, du kannst halt auch DOM-Methoden schreiben, das ist auch definitiv sicher und richtig,
aber je nachdem, wie groß halt dein, ähm, dein Markup wird, dein HTML-Template oder was,
wird's auch super schnell hässlich.
Und das will ich halt auch nicht, nicht arg befürworten.
Ja.
Was man ja irgendwie machen kann, was ich mir noch nie so hundertprozentig angeguckt hab,
ist, es gibt ja das Template-Element, wo du tatsächlich was reinschreiben kannst.
Und dann gibt es noch das Slot-Element, wo du tatsächlich sagen kannst,
hier soll jetzt was reingelegt werden.
Damit kann man relativ nett etwas Template-Ähnliches bauen,
aber es fehlt von der Ergonomie extrem viel.
Aber auch das nimmt dir natürlich nicht dein, ähm, dein komplettes Escaping ab.
Wenn du halt doch irgendwie ein bisschen HTML erlauben willst, ist es immer schwierig.
Also User-Generated HTML erlauben willst.
Ansonsten sag ich halt immer, vielleicht machst du einfach statt in HTML Text-Content.
Aber das geht natürlich nicht immer.
Ja.
Ja, in diesem Fall ging das nicht, weil da ging es darum, Suchvorschläge zu highlighten,
den eingegebenen Begriff.
Ja.
Und da hast du dann sofort HTML gleich drin.
Und du weißt halt echt nicht, was da jemand reinschreibt.
Also es ist, äh, ja.
Okay.
Gut, dann kommen wir doch vielleicht mal, äh, zur API selbst.
Wir haben jetzt schon viel drüber geredet, ähm, um das, irgendwas drumherum.
Irgendwie kam es dazu und was für ein Problem soll gelöst werden.
Aber wie soll das Ding denn eigentlich funktionieren?
Ähm, was wir uns erhoffen, was ein bisschen, als das erste Mal mir jemand gesagt hat, wie
wäre es denn damit, dachte ich so, ah, das ist ein bisschen, ich erzähle es mal.
Also die Idee ist tatsächlich so, dass du dir einen Sanitizer baust, ein Sanitizer-Objekt,
über einen Constructor, einen New Sanitizer und dann wirfst du da ein paar Options rein.
All diese Options sind optional.
Es gibt ein Default und für den Default wollen wir versprechen, dass der XSS safe ist.
Unter bestimmten Bedingungen, auf die wir später nochmal eingehen können.
Und Optionen, die du halt reingeben kannst, sind Elemente, die ich erlauben möchte, Elemente, die ich explizit nicht erlauben möchte,
äh, Attribute, Custom-Elements und wenn du Custom-Elements erlauben willst, dann musst du mir auch sagen, wie die heißen.
Äh, sollen HTML-Kommentare rausgeworfen werden, ja oder nein.
Und was wir auch gerade versuchen und das ist eigentlich sehr, sehr gerne, ähm, eine Tür, die ich auch zu, weiter zuhalten möchte, ist,
dass man den Sanitizer nie so konfigurieren kann, dass der was erlaubt, was unsicher ist.
Also, dass du tatsächlich niemals als Options reintun kannst und dann erlaub mir noch das Script-Element.
Ähm, da bin ich mir nicht sicher, ähm, wie sehr das den Leuten gefallen wird, wenn die halt sagen, ja, ich bin mir aber doch ziemlich sicher,
dass das in dem Fall an der Stelle folgendes Attribut doch in Ordnung ist, ähm, weil ich auch weiß, wie, ähm, wie verärgert ich schon mal darauf reagiert habe,
dass eine API nicht das gemacht hat, was ich dachte, dass sie machen würde, weil ich doch, weil ich doch das jetzt will.
Ähm, aber gleichzeitig denke ich, wenn wir sagen, das ist, das ist unsere Verantwortung und wir wollen das in den Browser geben
und wir wollen das Problem halt langfristig loswerden, dann möchte ich halt gerne weiterhin genau diese Tür zuhalten.
Genau, aber es gibt auch, die steht halt in der Spezifikation, äh, eine Standardliste von Elementen, die wir für sicher halten und die wir erlauben
und, ähm, das Einzige, was du also quasi mit den Optionen machen kannst, ist, du kannst die Liste kleiner machen.
Ja, also, wenn du sagst, ich möchte vielleicht kein, äh, New Lines oder keine Bilder oder was auch immer,
dann kannst du die halt rausnehmen, aber alles in allem ist das schon mehr oder weniger alles und dann hast du halt ein Sanitizer-Objekt.
Und dieses Sanitizer-Objekt ist jetzt quasi nicht viel mehr als der, der Container für deine Konfiguration,
die du für deinen bestimmten Use Case oder für deine bestimmte, ähm, für dein bestimmtes Feld, wo du gerade was rendern willst, hast.
Ähm, und den kannst du an anderer Stelle übergeben und jetzt wird's ein bisschen funky.
Also, ähm, wir erstellen tatsächlich einen neuen, eine neue Funktion auf dem, ähm, Prototypen von allen HTML-Elementen.
Also, ähm, jedes HTML-Element hat ja diverse Funktionen, wie zum Beispiel setAttribute und, und Properties wie .innerHTML.
Ähm, und wir haben uns eine neue Funktion überlegt, die einfach setHTML heißt.
Und da wirfst du dein Input rein.
Also, du hast, äh, documentbody.setHTML.
Und der erste Parameter ist der Input.
Und der zweite Parameter sind zum Beispiel der Sanitizer.
Und dann macht er das einfach alles.
Und der Witz ist halt, dass an der Stelle der Sanitizer wieder optional ist.
Das heißt, als Entwickler, im einfachsten Fall, kannst du ersetzen documentbody.innerHTML gleich Input, wobei Input vielleicht böse ist,
und ersetzt einfach diese komplette Zeile durch documentbody.setHTML.
Das ist eine Funktion, Klammer auf, Input, Klammer zu.
Und du hast dein XSS-Problem im besten Fall einfach gelöst.
Weil nämlich der Default-Sanitizer verspricht, weil der Default-Sanitizer verspricht, es gibt kein Crosshead-Scripting.
Mit einem Sternchen, aber zu dem Sternchen möchte ich in ungefähr zehn Minuten nochmal kommen.
Okay, okay, ich hab's schon notiert, wir kommen nochmal auf die Bedingungen.
Auf jeden Fall.
Und wenn du halt sagst, ähm, mein Formular möchte halt bestimmte Elemente nicht erlauben, ich möchte keine Bilder,
ich möchte wirklich nur, ich sag mal, bold, italics, underline, durchgestrichen und vielleicht, keine Ahnung, listen oder so,
äh, dann übergibst du halt noch deinen Sanitizer in der Option, äh, und dann macht zHTML genau das und mehr nicht.
Und das ist so das Grundgerüst der API.
Und ich glaube, dass wir damit sehr, sehr bis fast alle Use Cases abfrühstücken können.
Interessantigerweise hatten wir als ersten, ähm, Working Draft von unserer API was ganz anderes,
nämlich, dass das Sanitizer-Objekt eine Funktion hat, die heißt einfach Sanitize und dann wirfst du da einen String rein
und dann wird der halt für dich Sanitize und dann kriegst du den wieder zurück, was eigentlich extrem genau das ist,
was Dom Purify heißt, nur mit ausgetauschten Namen, statt Dom Purify.
Purify haben wir Sanitizer, Sanitize, ähm, wir haben aber zwei relativ coole Sachen gemerkt
und da muss ich eigentlich, nee, muss ich mich definitiv sehr bedanken bei meinem, ähm, Arbeitskollegen,
der, ähm, Mitautor des HTML-Specs ist, Anne van Kesteren, äh, der hat nämlich gesagt,
das ist ja eigentlich eine richtig geile Idee, aber was du halt machst im Sanitize unten drunter ist,
du nimmst einen String, baust daraus einen HTML-Baum, dann sortierst du diesen HTML-Baum durch,
wirfst irgendwelche Elemente raus, dann machst du aus dem Baum wieder einen String,
dann gibst du das dem Entwickler und der wirft den String wieder in den Dom
und dann wird das wieder geparst und dann baust du wieder einen Baum.
Das ist ja Blödsinn.
Dann hab ich gesagt, das stimmt.
Das ist die Kurzfassung.
Ich glaube, es hat Wochen gedauert, bis ich gesagt habe, das stimmt.
Ähm, aber das war so eine richtig spannende Erkenntnis, wie ich fand.
Also ich wollte, ich wollte gerade, ähm, erstmal spielen mit den Pausen und der Verzögerung,
sich nicht ins Wort zu fallen.
Wir kennen das mal heute.
Ähm, ich hatte nämlich, als du das gesagt hast, äh, mit dem Sanitize einfach als Funktion,
das war intuitiv auch das, wie ich es erwartet hätte ursprünglich.
Und, äh, meine Anschlussfrage wäre jetzt, gibt's aber trotzdem zusätzlich die, äh, Funktion
oder die Möglichkeit zu sagen, gib mir einfach aus dem String eine gesanitizte Version als String zurück?
Gibt's das trotzdem noch irgendwie oder ist das dann komplett ersetzt worden?
Jein. Jein.
Du kannst dir natürlich ein Dummy-Element erstellen, das zHTML aufrufen und dir dann das innerHTML rausholen.
Ähm, es gibt nämlich noch ein anderes Problem und das ist tatsächlich von der Security-Perspektive
einen Tacken schwergewichtiger, weswegen wir da tatsächlich sehr, äh, wie soll ich sagen,
äh, große Kurskorrektur.
Ich hab tatsächlich, ähm, von einem halben Jahr gedacht, so, die Sanitize-API, wir sind fast fertig.
Und dann große Kurskorrektur.
Ähm, was mir nämlich dann auch noch aufgefallen ist, auch da wieder, ähm, schön, dass man nicht
alleine dran arbeitet, auch wieder gutes Feedback von, ähm, von den Leuten, die an den HTML-Spezifikationen arbeiten.
Ähm, es gibt tatsächlich, wenn man das ganze HTML-Spec liest, was ich natürlich keinem empfehlen kann, ähm, aber, ähm, wenn man das, wenn man die, das
das Unterkapitel Parsing liest, dann gibt es zwei Algorithmen zum HTML-Parsen und einen davon müssen wir halt zwangsläufig benutzen, wenn wir es spezifizieren.
Und der erste ist, du paarest ein Element, nein, du paarest ein komplettes Dokument, ein komplettes HTML-Dokument, so wie es der Browser auch macht, wenn er eine Webseite aufruft.
Ähm, und dieser Algorithmus gibt dir zurück ein komplettes Dokument.
Das wollen wir ja in unserem Fall nicht.
Also, gucken wir uns die zweite Funktion an.
Das ist der sogenannte Fragment-Parser.
Der parsst ein HTML-Fragment, braucht aber definitiv als zweiten Parameter neben dem Input ein Kontext-Element.
Und dann parsst er, und zwar komplett unterschiedlich in Abhängigkeit des Kontext-Elementes.
Und wenn er dieses Parsing gemacht hat, dann gibt er dir halt so ein Fragment, also so ein HTML-Bäumchen mit, was halt kein komplettes Dokument ist.
So, und der Witz ist halt, dass das Security-Relevant sein kann.
Und zwar, wenn wir uns einfach nur das einfachste Beispiel angucken, was passiert mit HTML-Input, den wir schreiben, wenn er in einem Text-Area-Element ist,
versus was passiert mit Input, den wir schreiben, wenn er in einem Diff-Element ist.
Und das wissen ja die meisten.
Wenn du im Text-Area HTML schreibst, dann ist das gar kein HTML.
Dann wird das als Text interpretiert vom Browser und dann wird das als Input eines Text-Area-Elements angezeigt.
Und bei einem Diff-Element halt nicht.
Das heißt, wir müssen eigentlich wissen, im Sanitize-Use-Case, wie wir das, was wir gerade aufräumen müssen,
wie soll das gepasst werden?
Wie soll das verstanden werden?
Was ist das eigentlich, was man uns da gerade gibt?
Und ein anderes Beispiel, wo es tatsächlich auch von der Funktionalität Sinn macht, ist, wenn du ein, ähm, seid ihr noch da?
Ja, ja, wir laufen.
Okay, hört einfach gebannt.
Sehr gebannt, ja.
Hat er einmal aufgewacht.
Auch ein relativ gutes Beispiel, finde ich, von der Verständlichkeit her, ist, wenn du ein Diff-Element hast und Diff.in HTML equals
und dann, äh, Table-Row oder Table-Td-Element machst, ähm, dann funktioniert das nicht.
Dann werden die weggeworfen, weil es nämlich keine Tabellen, Zeilen außerhalb von Tabellen gibt.
Ähm, sondern dann werden die weggeworfen, es wird alles, was da drin ist, wird dann genommen.
Ähm, aber halt diese, diese Zeile hier, tr, fuba, tr schließt, die wird halt komplett anders gepasst in einem Diff als in einem Table-Element.
Im Table-Element hast du tatsächlich einen neuen Row und im Diff-Element nicht.
Das heißt, an ganz vielen Stellen funktioniert HTML-Parsing gar nicht so, wie ich bis vor wenigen Monaten noch gedacht habe
und wie, glaube ich, extrem viele Entwickler auch nicht gedacht haben.
Und das Problem ist halt, wir können Sanitizing nur lösen, wenn wir auch das Parsing lösen und zwar eindeutig und korrekt.
Und was halt noch darüber hinaus kommt, neben der, okay, Parsing ist nicht korrekt und wir haben die Sorge, dass das zu Security-Issues führt,
ähm, kommt natürlich noch der, der Anspruch, den ich vielleicht anfangs auch nicht so hatte,
Aber, ähm, wenn das halt irgendwie Teil von HTML sein soll und von allen Browsern, äh, die es so gibt,
äh, dann müssen wir natürlich auch den Anspruch haben, dass dieses, dieser Sanitizer halt für alle Elemente funktioniert, ne?
Es wäre halt doof, wenn manchmal aus Versehen TR-Elemente verschwinden.
Ähm, es muss halt für alle funktionieren.
Und deswegen können wir auch nicht, das haben wir erst überlegt und so war auch meine, ähm, ich glaube,
bis vor ein paar Wochen tatsächlich meine Implementierung in Gecko so,
dass wir, dass wir heimlich ein Body-Element erstellt haben, alles da reingepasst haben
und dann die Sachen wieder rausgegeben haben.
Aber das ist halt eine, eine Komplexität und eine implizite Annahme,
die wir in der API dem Entwickler ja abnehmen würden.
Und vielleicht will der das gar nicht, vielleicht will der was anderes, ähm,
und vielleicht ärgert der sich, wenn irgendwie irgendwelche Elemente nachher verschwinden.
Deswegen können wir das leider nicht.
Und ich finde es auch ehrlich gesagt immer noch doof.
Aber ich habe eine lange Liste von Abwägungen und Pro und Contra
und was können wir stattdessen machen und können wir nicht vielleicht.
Ähm, aber zu Recht ist tatsächlich die beste Möglichkeit zu sagen,
wir versuchen einerseits den Entwickler da abzuholen, wo er ist
und das ist vermutlich in der HTML gleich
und bieten was an, was ziemlich ähnlich ist
und das heißt eben SetHTML.
Und das hat halt den richtig, richtig coolen Vorteil,
dass da der Kontext immer klar ist, ne?
Ja, klar.
Denn wenn du foo.setHTML machst, dann ist der Kontext ja foo.
Dann ist der, dann ist der nicht nur, nicht nur implizit für uns,
sondern ganz explizit für den Entwickler.
Er weiß ja genau, wo er es gerade drin haben möchte.
Ja, macht's ja auf jeden Fall.
Aber so richtig mega zufrieden bin ich leider auch nicht.
Und dann gibt's noch eine andere Funktion,
ähm, die mehr oder weniger das Gleiche macht,
ähm, aber es noch nicht, äh, noch nicht in das aktuelle Dokument reinwirft,
wo wir aber nicht so sicher sind, ob wir das überhaupt anbieten müssen,
weil, äh, SetHTML ist quasi das Gleiche, nur andersrum.
Ich, ich erklär's mal.
Es gibt eine Funktion, die heißt Sanitizer.sanitize4,
das ist noch kein besonders schöner Name,
und das möchte eben genau auch zwei Inputs,
nämlich ein Kontext-Element, da schreibe ich dann rein div,
und dann den Input.
Und was ich zurückkriege, ist halt, weil wir keine Strings mögen,
ist halt kein String, sondern ein neues div-Element,
was wir für dich erstellt haben,
da haben wir alles reingeparst, und dann geben wir's dir in die Hand.
Und dann kannst du überlegen, mach ich damit ein Append irgendwo,
ähm, oder ist mir das Performance und das neue Parsing komplett egal,
und klau ich mir von dem Element dann das innerHTML
und speichere das weg oder benutze das irgendwo anders.
Ähm, aber das möchten wir halt ganz explizit abraten,
denn wenn du's für div ursprünglich mal geparst hast,
dann solltest du's auch unbedingt in einem div später wieder benutzen
und nicht woanders.
äh, denn das kann tatsächlich zu Sicherheitslücken führen.
Und ein typisches Beispiel ist, ähm,
ähm, eine Art, eine Unterart von XSS,
die, ähm,
ähm, MXSS heißt,
M für Mutated XSS,
was tatsächlich auf der Idee basiert,
dass du bestimmtes Mark-up schreiben kannst,
bestimmtes HTML schreiben kannst,
was sich, je nachdem, in welchem
Kontext-Element es hinzugefügt wird,
harmlos ist oder eben nicht harmlos.
und dann doch zu Crossout-Scripting führen kann.
Ich hab noch nie vorher gehört, den Begriff.
Tatsächlich.
Ähm, ja, dann wünschte ich mir,
ich könnte mit einem richtig, richtig guten Beispiel ausholen,
aber ich glaube,
ähm,
also ich kenn's noch nicht.
Na, dann erklär ich's.
Warte mal, ich hab
hier einen schönen
Ding, ding, ding, ding, ding, ding, ding.
Vielleicht auch nicht.
Und das, äh, schafft's dann auch
um Dom Purify drumherum, oder?
Die haben's tatsächlich mehrere Male
um Dom Purify rumgeschafft.
Ähm,
Dom Purify enthält mittlerweile
diverse Hacks,
um
Dinge zu erkennen
oder Dinge zu erlauben,
die einfach
obskur genug sind,
dass sie sagen können,
ja, aber wir wollen das halt auch
einfach nicht unterstützen.
Wir sind in der Library,
wir machen das jetzt so,
fertig.
Ähm,
und das ist halt auch so ein bisschen
die Freiheit, die sie haben,
dass sie sagen können, so,
dein Use Case ist mir zu abgefahren,
mach ich nicht.
Wenn wir halt tatsächlich es schaffen,
ähm,
und momentan sieht's relativ gut aus,
Teil der HTML-Spec zu werden
mit unserer Sanitizer-API,
dann, äh,
dann ist es halt in Stein gemeißelt,
so, dann,
dann kannst halt erst ein Browser,
dann könnt's zwei Browser,
dann könnt's hoffentlich,
hoffentlich noch mehr,
und dann ist es Teil der HTML-Spezifikation,
das kannst du halt nicht einfach so
wegnehmen oder ändern oder sagen.
Für dieses eine Element halt nicht.
Das wär halt komisch, ne?
Ähm,
ich glaube,
ich hab ein Beispiel gefunden,
aber es ist extrem abgefahren.
Dafür sind wir hier.
Schön.
Und das basiert auf
einem Angriff von
Michał Bentkowski aus Polen,
der häufiger mal Lücken in
Don Purify findet
und dann ausführliche Blogposts überschreibt.
und, ähm,
sein,
und das ist, glaube ich,
nur mit Audio ist es schwierig.
Ich schick euch nochmal die Links
und dann tun wir das in die Shownotes.
Das macht tatsächlich Spaß zu lesen,
aber es ist extrem abgefahren.
Die Idee ist,
dass du verschiedene Elemente hast,
die verschiedene Bedeutungen haben,
je nachdem,
ob sie zum Beispiel in SVG drin sind
oder im HTML.
Ein Beispiel zum Beispiel ist,
dass es ein SVG-P-Element gibt
und ich glaube,
das ist für Path, ne?
und ein HTML-P-Element gibt
und das ist für Paragraph,
also für einen neuen Absatz
und, ähm,
natürlich,
je nachdem,
in welches Kind-Element
du halt so ein P reinmachst,
ist es natürlich was komplett anderes
und der hat es geschafft,
das für einen Angriff zu nutzen.
Ich finde aber jetzt
nur seinen anderen Blogpost
und da ist es ein komplett anderes Beispiel
und jetzt habe ich, glaube ich,
den Fehler gemacht,
ganz weit auszuholen
und dann was anderes erklären zu müssen.
Ich würde sagen,
ich würde tatsächlich sagen,
wir klammern das aus
und es ist wirklich cooler,
das ausführlich in Ruhe zu lesen,
wenn man da tiefer gehen möchte.
Genau, also,
dann liefern wir die Links nach.
An der Stelle würde ich,
würde ich das,
ähm,
das Hand-Wavy sagen,
ähm,
an der Stelle können wir uns einig sein,
es gibt Elemente,
die natürlich radikal anders
vom Browser verstanden werden,
je nachdem,
in welchem Kontext sie sind.
Eben ein Beispiel der,
der Table-Row,
die ich vorhin hatte
oder halt einem Beispiel
des P-Elements in SVG,
versus das P-Element in HTML
und dass man daraus
Angriffe stricken kann,
müsst ihr mir an der Stelle glauben,
aber halt nur für höchstens
zehn Sekunden,
weil ihr als Hörer
ja auf Pause drücken könnt
und den Link anklicken könnt
und dann wird
hoffentlich alles klar.
Sehr gut.
Und ihr beiden halt jetzt
ein bisschen länger.
Genau,
wir müssen noch ein bisschen warten.
Genau,
aber die,
ja,
also das grundlegende Problem
ist halt leider,
wir wollen den Entwicklern
eigentlich nicht so gerne
Strings geben
und das zu begründen
ist natürlich ein bisschen schwierig
und ein bisschen doof,
aber ich finde halt auch
den Performance-Aspekt
eigentlich relativ schön,
dass wir sagen,
wir wollen halt auch
den String nicht nochmal parsen,
das macht ja irgendwie
keinen Sinn,
gerade wenn es relativ viel
Input ist,
ist es ja auch doof
für die Webseite
und für die Performance,
das doppelt zu tun.
ja,
es leuchtet auf jeden Fall
ein.
Schön.
Okay,
dann haben wir so,
das ist echt so das,
ich finde das Haarigste,
aber irgendwie auch das Wichtigste,
weil wenn ich halt,
wenn ich halt nachher,
wenn ich euch nachher erwische,
dass ihr die Sanitizer-API
falsch benutzt,
dann bin ich ziemlich enttäuscht
und mehr kann ich leider auch nicht tun.
Nein,
dann ist es halt irgendwie,
also ich habe mir halt was vorgenommen
und ich möchte,
dass es klappt so
und das geht natürlich nicht darum,
dass ich persönlich enttäuscht bin,
sondern es geht darum,
dass wir was geben,
was die Entwickler wirklich,
wirklich da abholt,
wo sie sind
und da sind wir natürlich,
da ist auch das letzte Wort
nicht gesprochen,
das ist übrigens eine ganz wichtige Sache,
die ich auf jeden Fall
mehrfach noch erwähnen sollte.
Wenn irgendwas völlig blödsinnig ist
oder auf eine andere Art und Weise
vielleicht deutlich naheliegender
für den Entwickler,
also für euch Hörer,
dann müssen wir das wissen,
denn jetzt ist noch der Zeitpunkt,
wo wir die Spezifikation schreiben,
jetzt ist noch,
wo ich den Patch offen habe,
in zwei Jahren ist es halt schwierig,
so.
Natürlich sind die Feedback-Cycles
immer eher lang
und ich muss mich übrigens
für meine ganzen Anglizismen entschuldigen,
aber wenn ich auf der Arbeit
über Websicherheit rede,
dann rede ich da nie auf Deutsch drüber.
Bitte verzeiht mir.
Genau, also normalerweise ist es halt oft so,
dass man Standard entwickelt
und dann dauert das irgendwie,
keine Ahnung,
ein halbes Jahr,
dann hat man eine Spezifikation
oder wahrscheinlich sogar länger,
dann hat man eine Implementierung,
dann dauert das irgendwie nochmal drei Monate,
bis es von Fivebox Nightly
in Fivebox Release ist
und dann sagen die Leute,
das ist aber kacke.
Und dann ist es aber vielleicht zu spät.
Von daher bin ich jetzt aus diesem Grund
zum Beispiel hier im Podcast
und von daher gibt es auch Blogposts
und ich glaube künftig sogar ein paar mehr
zur Sanitizer-API,
um eben zu erklären, was wir tun,
aber auch gleichzeitig einzuladen,
hey, wenn das nicht stimmt,
wenn ihr glaubt,
dass es anders besser geht
oder wenn ihr glaubt,
dass es an manchen Stellen vielleicht okay ist,
irgendwie doch eine Abkürzung zu nehmen oder so,
dann lasst uns unbedingt drüber reden,
denn wir wollen es halt lösen.
Wir wollen es nicht machen,
wie es für uns cool ist,
sondern wir wollen es so machen,
dass es wirklich läuft.
Das ist ein sehr guter Punkt.
Ich glaube, das ist vielen auch gar nicht bewusst,
dass man die Möglichkeit hat,
so frühzeitig reinzugrätschen
und dass es dann halt schon zu spät ist,
wenn es dann halt mal in den Brunnen gefallen ist.
Da können wir gerne nachher noch drauf zu sprechen kommen,
welche Möglichkeit man da hat,
so Einfluss zu nehmen.
Können wir tatsächlich von mir aus sogar jetzt.
Ist nämlich relativ einfach.
Wenn man in Firefox unterwegs ist,
dann kann ich sehr empfehlen,
im Allgemeinen zum Website-Testing,
zum Entwickeln
oder um mal neue Features sich anzugucken.
es gibt die Firefox Developer Edition
oder einfach die Nightly Builds,
Firefox Nightly.
Da sind immer die aktuellsten Iterationen drin.
Wie gesagt, wir sind mit dem Sanitizer
noch nicht hundertprozentig fertig.
Da kann man rumexperimentieren.
In Firefox gibt es eine Prev.
Das ist ein bisschen kompliziert,
aber da gibt es auch Anleitungen im Web zu.
Man macht einen neuen Tab auf,
geht auf die Seite about.config.
Da sind die ganzen versteckten Optionen
und tippt da Sanitizer ein.
Und dann findet man eine Konfig mit dem Titel,
ich glaube,
DOM Security Sanitizer Enabled
und setzt die auf True.
Und dann kann man die Dev-Tools aufmachen
und hat einfach diesen Sanitizer-Konstruktor da.
Und es gibt auch sogenannte Sanitizer-Playgrounds,
also Webseiten,
die tatsächlich einem das so ein bisschen nahe legen,
wie das für den Entwickler aussehen würde.
Mike West hat da einen geschrieben,
der ist einfach Sanitizer.dev, glaube ich.
Nee, Sanitizer-API.dev.
Und wenn man da drauf geht,
dann sagt der für euch jetzt wahrscheinlich,
hey, ihr habt den Sanitizer nicht,
aber wenn man die Prev anhat,
dann gibt er ein Beispiel mit Input
und Kontextelement und Output und so weiter.
Ich habe es gerade live mal gemacht,
stimmt alles, was du sagst.
Live mitgetippt.
Yes, und wenn man in Chrome unterwegs ist,
dann ist das bereits in Chrome,
ich weiß nicht, ob in Chrome Beta
oder schon in Chrome Release.
Ich glaube, es ist schon in Chrome Release,
wenn man Web Experimental Web Platform Features aktiviert hat.
Also hier steht ab 96, 97 im Chrome kann man es aktivieren.
Ah ja, dann ist es, glaube ich, noch nicht Release, ne?
Genau, den 94er haben wir aktuell.
Also auf jeden Fall einfach mal damit rumspielen am besten.
Das werde ich jetzt auch gleich mal machen.
Genau, und dann kann man halt nicht sagen,
ich finde grundsätzlich was doof,
sondern kann man auch ganz spezifisch sagen,
ich finde grundsätzlich doof und hier ist ein Beispiel,
ich habe das mal, das ist immer produktiver natürlich.
Und genau, unsere Spec ist ganz einfach,
wie übrigens sehr, sehr, sehr viele Specs,
ein GitHub Repository mit Issues.
Und da steht halt zum Beispiel drin,
was wir noch nicht gelöst haben,
was wir nämlich zum Beispiel noch nicht richtig sauber gelöst haben,
ist so ein bisschen Namespacing-Sache,
wenn es darum geht,
was man als erlaubte Elemente übergeben möchte
für so obskure Sachen wie SVG oder MathML,
was ich tatsächlich bis jetzt immer nur
in meiner Web-Security-Karriere gesehen habe,
als etwas, das Leute benutzen,
Parser und Libraries aus dem Konzept zu bringen.
Aber ihr als Frontend-Leute macht wahrscheinlich
den ganzen Tag MathML.
Ja, klar.
Bin ich mir sicher.
Ich habe mich darauf spezialisiert sogar,
ich mache schon gar nichts anderes.
Also ich gehöre zu den Menschen,
die SVG schon von Hand geschrieben haben,
aber nicht die Paths.
Das muss ich zugeben,
das habe ich auch noch nicht.
Das ist cool.
Ja, und das ist zum Beispiel noch nicht so komplett klar.
Und dann auch so ein paar andere Issues,
die jetzt gar nicht so sehr sich um die API handeln
und wie das für den Entwickler ist,
sondern einfach wie wir Dinge ausformuliert haben
in unserer Spezifikation.
Und so eine Spezifikation lebt ja auch nicht alleine.
Ganz viele Begriffe, die wir benutzen,
müssen wir ordentlich verlinken mit HTML,
Spec und so weiter und so weiter.
Weil manche Begriffe halt auch teilweise ein bisschen obskur sind,
muss man einfach sagen.
Und das, was man vielleicht umgangssprachlich sagen würde,
nicht unbedingt dem entspricht,
was man sehen würde,
wenn man einfach so mit JavaScript herumspielt.
Genau, und die Google Developer Advocates
haben auch, ich glaube, gestern oder vorgestern
einen Blogpost geschrieben zur Sanitizer API.
Von daher kriegen wir gerade sowieso ein bisschen mehr Feedback
in unserem GitHub-Repo
und freuen uns tatsächlich sehr,
wenn wir ein bisschen kriegen.
Da ist der Artikel,
das können wir auch in die Show Notes werfen,
web.dev.sanitizer.
gibt es auch einen relativ frischen Artikel zur Sanitizer API.
Sehr gut, gleich mal notiert.
Aber ich werde wohl auch noch ein oder zwei schreiben müssen,
weil ich ein bisschen das Gefühl habe,
ich muss mich rechtfertigen,
aber ein bisschen das Gefühl habe,
ist es auch wichtig,
dass es ankommt mit der Tatsache,
dass wir irgendwie nicht so gerne Strings zurückgeben wollen
und uns da so zögerlich geben,
sage ich mal.
Auf der anderen Seite,
da wollte ich vorhin noch eigentlich noch mal kurz einhaken,
kann ich jetzt machen,
ist es natürlich aber auch wichtig,
dass die Fehlbenutzung möglichst ausgeschlossen wird,
also dass es möglichst intuitiv ist.
Und ich kann verstehen,
dass ihr bestimmte Sachen aus Gründen nicht machen wollt,
aber ich glaube,
da muss man gründlich abwägen an der Stelle auf jeden Fall.
Weil ich glaube,
Ich glaube an der Stelle,
wenn ich das jetzt,
wenn ich so eine API designen würde,
würde ich wahrscheinlich,
wenn ich diesen Kompromiss jetzt machen müsste,
ich würde wahrscheinlich mich für einfache Benutzbarkeit entscheiden
und für das,
für intuitive Benutzbarkeit
und vielleicht für das letzte Quäntchen
perfekt ausdefiniert oder so.
Ist schwierig,
aber ich glaube,
das macht es auf jeden Fall einfacher,
dass es die Leute verstehen.
Also ich finde nichts schlimmer,
als eine schlecht designte API,
wo ich jedes Mal nachgucken muss,
wie sie jetzt funktioniert.
Genau.
Und das ist jetzt die schlecht designte API,
wo du nur die eine Folge,
wo wir sie jetzt vorne hören musst.
Genau.
Musst nur sie so einen Podcast.
Ist tatsächlich,
ich glaube nicht,
dass sie schlecht designt ist,
aber es ist tatsächlich so,
dass ich natürlich kein API-Designer bin.
Also ich mache das,
ich habe Websicherheit verstanden
und ich glaube einigermaßen gut,
aber das ist für mich halt auch so ein Territorium,
wo ich ganz, ganz gierig bin,
Feedback zu erhalten.
Und das Gleiche gilt,
das habe ich gar nicht erwähnt,
schandhaft,
ich bin nicht der Typ,
der die Sanitizer API macht,
ich bin einer von drei Typen,
die die Sanitizer API machen.
Also die Spezifikation hat drei Autoren,
oh Gott,
Asche auf mein Haupt.
Ich mache das zusammen mit Daniel Vogelheim,
der das in Chrome implementiert
und für Google arbeitet.
Und dritter im Bunde ist Mario Heiderich,
der Entwickler von Dom Purify
und wie gesagt auch ein guter Freund von mir,
der halt auch diverses akademisches Security Research
im Rahmen seiner Doktorarbeit gemacht hat
zu eben solchen Themen
und da einfach
einfach extrem wertvoll ist
in ganz vielen Designentscheidungen
und Abwägungen,
weil er halt sagen kann,
ja, das haben wir in Dom Purify auch mal überlegt,
aber das will bis jetzt keiner.
Also machen wir das auch nicht.
Und das alleine kann manchmal einfach schon
ein extrem hilfreicher Input sein
für, wie gestalten wir das.
Aber auch wir alle drei,
weder ich noch Daniel noch Mario
sind Web-Entwickler.
Also wir sind da definitiv auf Feedback angewiesen.
Das habe ich jetzt, glaube ich, oft genug gesagt.
Mario bin ich schon ein paar Mal über den Weg gelaufen.
Der wird sich wahrscheinlich nicht erinnern.
Ich habe mal einen Konferenzvortrag von ihm gesehen
und ich war auch mal auf einem Security Workshop
von ihm, den er bei mir in der Firma gemacht hat.
Also war mir auf jeden Fall schon ein Begriff vorher.
Ja, schön.
Ich saß auch schon mal in einem Workshop drin.
Ist gut.
Ja, der ist wirklich gut.
Den kann ich wirklich empfehlen.
Ist gut.
Danach möchte man eigentlich alles wegwerfen,
was man bisher gemacht hat
und nochmal neu schreiben,
weil man dann so einige Erleuchtungen hatte,
wie viele schlimme Dinge man schon
in der Vergangenheit produziert hat,
die total angreifbar sind.
Also es ist,
da gibt es auch so,
ja, warte mal,
das hatten wir, glaube ich, auch schon mal.
Da gibt es so ein Game,
was man spielen kann im Browser,
wo man verschiedene XSSer ausprobieren kann,
ob man es brechen kann,
ob man reinkommt.
Gibt es sehr, sehr viele.
Kann ich euch auch welche mitgeben
für die Show Notes.
Gerne.
Ich hoffe, einer von euch
macht ein bisschen Notizen.
Ich bin mir nicht sicher,
ob ich mir das alles merke.
Wir machen es parallel nebenher, ja.
Danke.
Immer, wenn wir komisch
auf dem Monitor weggucken,
dann sind wir gerade
an den Notizen machen.
Wunderbar.
Genau.
Ja, wir hatten es gerade schon
über die Browser
und ich war auch kurz auf
Canary Use,
da ist noch alles ziemlich rot.
Was hast du denn so für ein Gefühl,
wie lange das dann etwa gehen wird?
Das ist natürlich immer schwierig,
aber was meinst du denn?
Ich wusste noch nicht mal,
dass wir auf Canary Use sind.
Das ist ja der Hammer.
Ja, ja, doch.
Hut, Hut, ja, alles rot, 0%.
Ja, also, ich und Daniel
arbeiten aktiv dran,
das zu implementieren in,
das ist auch so ein Denglish,
also wir machen es,
wir schreiben es auf
in der Spezifikation
und wir implementieren es gerade
für Gekko und Blink.
Das wird definitiv passieren.
Ich möchte keine Timeline,
keine Versprechen abgeben,
aber bald,
und über andere Browser
kann ich natürlich nichts sagen.
Da gibt es halt
ein paar offensichtliche
Allgemeinplätze,
die ich von mir geben kann.
Edge und Opera werden es haben,
wenn es Chrome auch hat,
genauso Brave,
weil die halt einfach
auch die Blink Engine benutzen.
Die Safari-Leute
sagen grundsätzlich ja nie was
zu solchen Themen,
leider auch
in Standard-Gremien nicht.
Also es gibt ja die W3C-Arbeitsgruppe
zur Web-Applikationssicherheit,
das ist übrigens auch
alles öffentlich
und da haben die nur gesagt,
wir finden das grundsätzlich
interessant,
aber das heißt halt
einfach nichts.
Und da werden wir halt
einfach sehen.
Was ich tatsächlich auch mache,
ein bisschen für Spaß
und weil ich da so ein
Junior-Engineer,
der mir mehr oder weniger
über den Weg gelaufen ist
und für eine ganz andere
Firma arbeitet,
der hat gesagt,
kannst du mich da mentoren,
ich möchte ein bisschen
Browsersicherheit lernen,
gibt es ein Sanitizer-API-Polyfill,
an dem wir arbeiten.
Und wie an der Stelle ist,
ich mache so ein bisschen
Mentoring
und erkläre das Beck
und dieser junge,
talentierte Junge
namens Edward,
der glaube ich,
in Kalifornien lebt,
macht größtenteils den Rest,
aber die Idee ist,
dass es halt auch
ein Polyfill geben soll,
der sich so anfühlt
wie die Sanitizer-API,
aber eben das nicht
komplett im Browser macht,
sondern natürlich
so ein paar Abstriche,
was Performance
und ein paar Abstriche,
was Security angeht.
Das ist auf jeden Fall praktisch,
dann kann man nämlich
quasi schon direkt
damit loslegen,
sobald es den gibt
und dann,
der wird ja dann
wahrscheinlich so gebaut sein,
dass falls der Browser
die Sanitizer-API hat,
dass er dann nichts macht.
Wie sich das für ein Polyfill gehört,
was ich auch übrigens
neu lernen musste,
aber man kann ja eben
if type of Sanitizer
equals und defined
oder so ähnlich
und dann
ratterst du deinen Code runter
oder so.
Genau,
das XS-Game,
was ich meinte,
was ich meinte jetzt tatsächlich,
da war das Prompt,
Prompt One to Win
von Q53,
glaube ich,
Prompt ML.
Der Link kommt in die Show Notes.
Das ist ganz witzig,
das steigert sich
von Level zu Level.
Es ist am Anfang
ganz easy,
da auszubrechen.
Man hat den Code
in JavaScript schon stehen
und aus dem man ausbrechen muss
und es wird aber schon
relativ schnell knackig
und interessant.
Da muss man dann
schon ein paar Tricks drauf haben.
Genau.
Ah, witzig.
Es gibt auch
Alert One to Win.
Das ist unter
sk.alf.nu
Ja, ich glaube,
da hast du das letzte
Woche noch nicht gesprochen.
Aber ja,
mal gucken.
Gut,
jetzt habe ich mir hier noch notiert,
Follow-up,
die Bedingungen für
XSS-Sicherheit
mit den Default-Werten
der Options.
Ja, sehr schön.
Genau, da wollten wir noch zukommen.
Und zwar gibt es,
und jetzt muss ich auch wieder
so ein bisschen ausholen,
bestimmte Angriffe,
die halt sich nicht wirklich
auf deine Web-Anwendung
beziehen im Rahmen
Crossout Scripting
und sich vielleicht auch nicht
direkt auf den Code,
den du geschrieben hast,
beziehen,
sondern vielleicht auf das
Framework.
Und jetzt kommt halt der
der Gag im weitesten Sinne.
Ich fange mal an mit,
es gibt tatsächlich
drei,
drei Sternchen.
Erstens,
ein Angriff mit dem Namen
Script Gadgets
und das ist ein relativ
cooler Research
von dem Google Web Security Team,
die Security machen
für Google.com
und alle möglichen
Google Webseiten.
Und die haben gesagt,
was wäre,
wenn eine Webseite
einen coolen
Security Mechanismus hat
und ein Crossout Scripting.
Also beides.
Wir gehen davon aus,
die Webseite hat eine Schwachstelle,
was wie ich finde
eine relativ okaye Annahme ist,
weil wenn eine Webseite
groß ist,
dann hat die halt mal
eine Schwachstelle.
So ist es leider.
Und wir gehen davon aus,
die hat einen Sicherheitsmechanismus
und dann haben die
verschiedene Sicherheitsmechanismen
durchgecheckt.
Zum Beispiel
DOM Purify,
eine relativ starke
Content Security Policy,
und ich glaube auch noch
was Drittes,
aber es fällt mir nicht ein.
Und jetzt kommt der Gag.
Die haben eine Testmatrix gebaut
in Verbindung mit
bestimmten Frameworks.
Also Bootstrap und CSP
oder Bootstrap und DOM Purify,
React und CSP,
React und DOM Purify
und dann noch so ein paar
andere Frameworks.
Und die haben halt gemerkt,
dass man relativ witzige Sachen
machen kann,
weil halt CSP
und DOM Purify
auf HTML reagieren,
aber nicht auf
Bootstrap-Markup.
Das heißt,
ein relativ schönes
Beispiel ist,
dass Bootstrap-Buttons
aus bestimmten Gründen
ihren Text haben
über
ein Data-Attribute.
Ich glaube,
du machst ein Button
auf,
und das ist jetzt ein bisschen
älteres Research,
das ist in der neuesten
Bootstrap-Version
vielleicht anders.
Du machst ein Button-Element
auf und hast da drin
ein Attribut namens
data-text, glaube ich,
und da ist der Text drin
und dann machst du
das Button-Element
wieder zu
und Bootstrap
zeigt dir das als
schönen Bootstrap-Button
an, was auch immer.
Und dann gibt es noch
ein,
genau,
und was Bootstrap
under the hood macht,
ist,
die nehmen das,
was in dem
Data-Attribut drin ist
und machen
inner-HTML.
Also das ist im
aktuellen Bootstrap
auf jeden Fall
nicht mehr so,
aber kann mit Sicherheit
sein,
dass das mal so war,
ja.
Ich glaube,
mittlerweile musst du
irgendwie data-HTML
gleich true
auch noch als Attribut
setzen
und ich glaube,
dann geht das noch.
Das kann sein,
ja.
Nie gemacht.
So,
und wenn du halt sagst,
hier ist mein harmloses
HTML
und dann guckt sich
irgendjemand das an
und sagt,
ja,
Data-Attributes,
die haben ja keine Bedeutung,
die haben ja keine Semantik,
per Definition,
kann ich ja drin lassen,
dann ist halt alles im Eimer,
ne.
Das heißt,
und deswegen haben die
das Script-Gadgets
genannt,
die haben sich
kleine,
ja,
kleine Gadgets,
kleine Werkzeuge
rausgesucht
in bestimmten Frameworks,
die es denen erlauben,
etwas zu tun,
was der,
was der gute
Web-Entwickler
vielleicht nicht tun würde
und haben die halt benutzt,
um durch die Hintertür
Crossout-Scripting
auszuführen.
Selbst,
selbst wenn du sagst,
ich passe auf mein HTML
eigentlich auf
und weil halt das,
das Script,
was die injecten,
ist halt nicht wirklich
ein Script,
sondern es ist
Bootstrap-Markup
und das Script,
was dann eigentlich
ausgeführt wird
auf deiner Webseite,
ist halt Bootstrap.
Das ist halt erlaubt.
und deswegen kannst du dich
dagegen nicht so richtig
gut absichern.
Das heißt,
das ist ein bisschen
ein Problem für die
Sanitizer-API,
dass wir halt eine
bestimmte Interpretation
haben von,
was ist böse
im Kontext von HTML
und deine Web-Anwendung
vielleicht ein ganz anderes
Verständnis davon hat.
Das heißt,
wenn du ein Framework
benutzt,
was relativ dick ist,
dann musst du dir
leider angucken,
was dieses Framework
kann und was du davon
explizit erlauben willst
oder halt nicht
und das ist ein bisschen
schwierig
und
was wir hoffen
langfristig
ist,
dass die
coolen Frameworks
und damit erzeuge
ich jetzt den Druck,
dass die tatsächlich
dir eine Anleitung geben
oder noch noch cooler
irgendwo einen
Global Sanitizer
rumliegen haben,
den du einfach
benutzen kannst.
Also das Coolste wäre,
wenn du
innerhalb irgendeinem
Framework
Code schreibst
und immer,
wenn du einen Sanitizer
brauchst,
liegt der halt irgendwo rum
als hinter einer Funktion
aus dem Framework
oder als globale Variable
oder was auch immer
gerade sexy ist.
Oder wird vielleicht
sogar automatisch verwendet,
ne?
Und du benutzt genau den.
Ja, oder genau,
oder du kannst ihn
automatisch verwenden
oder du kannst vielleicht,
du kriegst einen
übergeben,
kannst,
das habe ich glaube ich
nicht erzählt,
aber das Sanitizer Objekt
hat auch
eine GetConfig-Funktion.
Du kannst dir aus dem
Sanitizer rausgucken,
was erlaubt der gerade.
Dass du halt vom Framework
einen Sanitizer kriegst,
dir die Config anguckst
und sagst,
okay,
die übernehme ich als Baseline
und dann werfe ich
noch mehr raus
zum Beispiel.
Dass du halt irgendwie
bewusst
und gezielt
interagieren kannst
mit einem Sanitizer,
den dir das Framework gibt.
Das wäre halt irgendwie
ganz geil.
Ja klar,
oder im besten Fall
benutzt das Framework
einfach einen Sanitizer,
der ordentlich konfiguriert
ist für das Framework
und dann bist du
komplett raus.
Genau.
Das ist so ein bisschen
eine Hoffnung.
Dann gibt es
noch einen anderen Angriff,
den ich vorstellen müsste,
um zu erklären,
warum das der Sanitizer
nicht tun kann.
Und der ist relativ alt
und ich finde relativ
obskur,
aber auch relativ geil.
Das heißt
DOM Clobbering.
Ich weiß nicht,
ob ihr davon mal gehört habt.
Und zwar
wisst ihr ja vielleicht,
dass wenn du einem
HTML-Element
eine ID gibst,
dass die gleichzeitig
auch automatisch
als globale Variable
in JavaScript existiert.
So.
Das heißt
und jetzt wird es
noch ein bisschen
abgefahren.
Das gleiche gilt
für bestimmte Elemente,
ich glaube aber nicht
für alle.
Ich glaube für Formulare
und
und ich glaube
auch Hyperlinks,
bin ich sicher,
ist es auch beim
Name-Attribute so,
dass das einen globalen Namen
setzt.
Ich glaube bei Formularen
ist das so.
Und
was du zum Beispiel
machen kannst,
ist du kannst
naja nicht direkt
Variablen überschreiben,
die es im JavaScript gibt,
aber du kannst
je nachdem wie das
JavaScript geschrieben ist,
kannst du es verwirren,
indem es irgendwelche
Dinge aufruft
und denkt,
oh das ist ja schon gesetzt.
Also wenn du so
Code hast,
ist
Fubar ist gleich
Default
Fubar
oder
und dann
anderer Wert
und dieses
Default
Fubar ist halt
eigentlich gar keine
Variable,
sondern ein Element,
was ein Entwickler,
was ein Angreifer
eingeschleust hat.
Damit kann man halt
Webseiten
angreifen
und ein relativ
cooles Ding ist,
wenn du ein Formular
baust und dem,
und da bin ich mir
sicher,
die ID
oder den Namen
gibst,
ich sag mal wieder
Fubar
und dann
darunter
Radio
Input Elemente
hast
und denen
alle den Namen
gibst
Children,
dann hast du
tatsächlich,
wenn du
Fubar.children
machst,
nicht mehr die
HTML Elemente,
die die wirklichen
Kinder sind,
sondern du iterierst
nur durch die
Radio Elemente
durch.
Ach krass,
sehr gut.
Und das ist halt
ärgerlich.
Und ich
glaube nicht,
dass es tatsächlich
eine ausführliche
Liste gibt,
die bei allen
Browsern exakt
gleich ist,
bei welchen
Elementen,
welche
ID,
Namen,
etc.
Kombinationen
was genau
bedeuten und
welche
tatsächlichen
echten
Attribute
an einem
HTML Element
sich überschreiben
lassen und
welche sich
nicht überschreiben
lassen.
Das ist leider,
weil das nämlich auch
so eine
Nineties
Sache ist,
schlecht
spezifiziert
oder ich glaube
gar nicht
richtig spezifiziert
und überhaupt
nicht interoperabel,
also in jedem
Browser
einen Tacken
anders.
Und deswegen
ist es schwierig,
das ist ein
extrem wackeliges
Fundament,
dass wir das
in unserer
Spezifikation
aufgreifen
könnten.
Sonst könnten
wir ja sagen,
wir erlauben
grundsätzlich
keine,
wir erlauben
grundsätzlich
Name
und
ID
Attribute
aus,
dass sie
haben
den Wert.
So einen
absurden
Kram
könnte man
sich
natürlich
überlegen,
aber das
ist halt
wieder so
extrem
handwavy
und dann
machen wir
halt doch
irgendwelche
Use Cases
kaputt
und dann
ist es
nicht
klar
und wenn
wir den
Anspruch
haben
und den
haben
wir
halt,
dass
die
Sanitizer
API
in der
HTML
Spezifikation
landet,
also wirklich
im
HTML
Speck,
dann können
wir halt nicht
sagen,
wir funktionieren
für drei
Elemente,
aber für
diese fünf
dann doch
nicht
und dann
wieder anders,
sondern dann
muss es halt
für alle
klappen.
Deswegen
haben wir
jetzt gesagt,
wir klappern
das Thema
DOM-Clobbering
aus
und ich
bin
halbwegs
zufrieden
damit.
Interessant,
was das für
Kreise zieht.
Aber du kannst den
Sanitizer natürlich
Entschuldigung,
jetzt habe ich dich
unterbrochen,
sag nur mal bitte.
Erzähl ruhig
weiter.
Du kannst aber
natürlich den
Sanitizer so
konfigurieren,
dass du
grundsätzlich
keine ID
und keine
Name-Attribute
erlaubst.
Kann ja auch
tatsächlich Sinn
machen.
Ja,
Wahnsinn.
Aber grundsätzlich
sind die halt auch
harmlos,
von daher
schwierig,
einfach schwierig.
Und dann
habe ich natürlich
was
ganz
Einfaches,
was man aber auch
sagen muss,
wenn ich sage,
hey,
wir schützen vor
Cross-Site-Scripting.
Wir schützen
natürlich nur
vor Cross-Site-Scripting,
wenn es sich
im Rahmen
deiner
kleinseitigen
Anwendung
abspielt,
also in deinem
HTML-Java-Script,
zum Beispiel
in deiner
Single-Page-Application.
Sobald du
irgendwie
HTML an den
Server schickst
oder vom
Server zurückkommst,
dann händelt das
ja der Browser
einfach so,
als wäre es
ein Dokument,
was dem
Browser
geschickt wurde,
weil das
so bei euch
auf der Platte
liegt,
dann kann
die
Sanitizer-APA
auch nicht
helfen.
Das ist
was,
was ich glaube
ich bei der
Definition
von Cross-Site-Scripting
ganz am Anfang
unterschlagen habe,
man unterscheidet
so ein bisschen
in bestimmte Typen
von Cross-Site-Scripting
und du kannst
natürlich irgendwie
serverseitig haben
oder du kannst
es halt
clientseitig haben
und wenn du
serverseitig hast,
dann können wir
halt nichts tun,
weil da sehen wir
nichts und wir
können eigentlich
nur helfen,
wenn du das
alles mit
JavaScript machst.
Genau,
das sind so
die Sternchen
gewesen,
die stehen
tatsächlich auch
in unserer
Spezifikation.
Ist mir auch
relativ wichtig,
dass wir da
klar sind,
weil wir
wie gesagt,
wir versuchen
da was relativ
Großes zu versprechen,
dann will ich halt
auch nicht
zu viel zu versprechen
und ganz klar machen,
was unsere,
ja,
wo unsere Grenzen
sind.
Also unsere
Speck hat
tatsächlich
ein Kapitel
Security
Considerations
und da
gehen wir
das alles
einmal durch
in einer
anderen
Reihenfolge
als hier,
aber whatever.
Ich muss ja
sagen,
dass ich die
Speck,
ich habe mir
die Seite
mal angeguckt,
ich habe
nicht alles
gelesen,
muss ich zugeben,
dass ich das
aber von der
Menge her
überschaubar
und begreifbar
finde,
weil die längsten
Abschnitte
sind eigentlich
so Listen
mit Elementen
und Attributen,
das ist das,
was den Scrollbalken
klein macht,
ja,
aber ich finde,
das ist so,
der Appendix,
ja,
ich finde das,
ich finde das
sehr herrlich
begreifbar,
also es gibt ja
so Specks,
die sind,
keine Ahnung,
wie viel
DIN A4-Seiten
ausgedruckt,
um auf das
vorhin,
von vorhin
zurückzukommen
und das finde ich,
das finde ich doch
tatsächlich irgendwie
von der Länge her
durchaus,
das kann man mal
sich in einer halben
Stunde oder Stunde
mal durchlesen
und ich glaube,
dann hat man schon
ein ganz gutes
Gefühl dafür,
was einen da erwartet,
finde ich echt gut.
Schön,
das ist schön zu hören,
aber ich muss natürlich
sagen,
das wird noch ein bisschen
wachsen,
das wird noch ein bisschen
sich was ändern,
aber wir hoffen halt auch
ein paar Sachen,
das ist jetzt ein bisschen,
es ist noch nicht
hundertprozentig klar,
aber ich glaube,
die Idee ist,
dass wir,
wenn wir sowas definieren
wie setHTML
anhand,
an einem Attribut,
da muss es natürlich,
dann können wir das nicht
in unserem Speck
heimlich verstecken,
sondern da muss es halt
Teil des Doms
Specs oder das HTML
Specs sein,
ich glaube in dem Fall
sogar Domspec
und wenn wir eine Liste
und das ist,
was du gerade gesagt hast,
das ist unser Anhang
ganz unten in unserer
Spezifikation,
das ist einfach die Liste
von Elementen,
die wir für sicher halten,
da wird es glaube ich
auch noch sehr,
sehr viel Feedback
zu geben,
da bin ich auch
gespannt drauf
und zwar ganz ernst
gemeint,
da bin ich gespannt drauf,
wie wir da Leuten
irgendwie helfen können
und was da übliche
Use Cases sind
und warum wir
was entschieden haben.
was wollte ich sagen,
achso,
diese Liste von
das ist von dem
wir glauben,
sicheres HTML
für Cross-Side Scripting,
das ist glaube ich
an sich schon so eine
coole Liste einfach mal
zu haben und zu sagen,
diese HTML Elemente,
die kann ich erlauben,
wenn ich,
selbst wenn ich die
Sanitizer API
nicht einsetzen kann
und ein anderes Tool habe,
dann kann man sich
vielleicht wenigstens
auf so eine Liste
einigen und sagen,
die hier sind alle
in Ordnung
und wenn ich was
oben drauf setze,
dann vielleicht nicht
und vielleicht muss es
immer eine Untermenge
von dem sein,
was der HTML-Standard
sagt,
das ist sicher
und die anderen halt nicht
und das sind halt
alles Sachen,
wo wir hoffen,
dass wir die irgendwo
gut festschreiben können,
dass das halt tatsächlich
im HTML-Standard steht
und ich hoffe,
dass da auch andere
was von haben.
Stellt sich raus,
Unclick ist kein
sicheres Attribut.
Echt?
Crazy.
Genau.
Jetzt habe ich
ganz schön fusselig
geredet.
Ja, ich glaube,
wir haben zur
Sanitizer API
an sich jetzt
alles gesagt,
wenn dir sonst
nichts mehr einfällt,
was du unbedingt
dazu loswerden möchtest.
Heute Abend
im Bett
oder morgen früh
wahrscheinlich.
Aber nee,
ich glaube,
das Wichtigste
ist erzählt
und ich glaube,
ja,
der Hauptgrund
meiner Anwesenheit
hier ist wirklich,
dass ich sehr gierig,
dass wir sehr gierig
auf Feedback sind.
Also wenn irgendwas
komisch ist
oder anders besser geht
oder unverständlich,
dann unbedingt.
Und wenn man sich
nicht traut,
das öffentlich
auf GitHub zu schreiben,
das kann ich auch
manchmal verstehen,
dann schickt mir
eine Twitter-DM.
Ich bin
freddib auf Twitter
oder es geht auch
freddib
at mozilla.com
oder fbraun
at mozilla.com
und früher oder später
werde ich antworten.
Wahrscheinlich nicht
sofort am nächsten Tag,
wahrscheinlich auch
nicht in der nächsten Stunde,
aber ich glaube,
das muss unbedingt
nicht alleine passieren,
was wir hier tun,
sondern mit Feedback.
Ja,
also,
ihr habt es gehört.
Einfach mal melden.
Aber es dürft ihr erst machen,
nachdem ihr die Speck
ganz gelesen habt,
inklusive der Attribute-Liste.
Ja,
vielleicht,
oh Gott,
vielleicht findet ihr noch Fehler.
Nein,
ihr müsst es natürlich
nicht ganz gelesen haben,
aber wenn ihr glaubt,
vielleicht ist meine Frage
eine dumme Frage,
dann könnt ihr natürlich
vorher das Speck lesen
und in den GitHub-Issues gucken,
was ist da,
was sind da noch offene Fragen,
von denen wir wissen,
dass es die gibt,
dann könnt ihr da natürlich,
natürlich kommentieren,
aber ich weiß halt auch,
dass es manchmal so eine Hürde ist
und dass es manchmal auch
unangenehm ist,
mit Leuten zu reden,
wo man weiß,
da antworten mir gleich fünf Leute,
die voll die Ahnung haben,
vielleicht traue ich mich doch nicht,
was zu schreiben,
dann nehme ich das gerne per E-Mail an.
Und wie kommuniziert ihr untereinander
dann auch über GitHub-Issues
oder habt ihr irgendwie
noch eine Mailing-Liste?
Ich weiß,
dass es das ja teilweise
irgendwie gibt beim W3C.
Wie ist das bei euch?
Also es gibt eine W3C-Mailing-Liste,
die heißt, glaube ich,
public-web-app-sec,
also wie
web-anwendungssicherheit
at w3.org.
Das ist einfach die offizielle
Mailing-Liste der Working Group,
da passiert aber nicht so super viel.
Das meiste,
was sehr, sehr hands-on ist,
also sehr spezifisch
zu der exakten Implementierung
und dem Spec-Text
passiert eigentlich fast alles
auf GitHub.
Wir treffen uns
mehr oder weniger
regelmäßig
so eine halbe Stunde
Videokonferenz
als Autoren
untereinander,
aber nicht,
um strittige Themen
zu diskutieren,
sondern zu sortieren,
was müssen wir noch machen,
was haben wir gemacht,
was wollen wir als nächstes machen,
so ein bisschen
Stand-up-mäßig quasi.
und ganz, ganz selten,
wenn ich irgendwie
ein Patch schreibe
und merke,
hä, das ist aber komisch,
in Google ist,
in Chrome ist es anders,
im Spec ist es nicht ganz klar gesagt,
wie der das macht.
Ich hätte das jetzt so programmiert,
aber ich merke,
die Tests,
die wir geschrieben haben,
die erwarten das anders,
dann schicke ich halt einfach
direkt eine E-Mail
und sage,
ähm,
warte mal,
aber,
äh,
ich glaube,
GitHub ist eigentlich die,
die Antwort,
mein 5-Minuten-Minolog,
zusammengefasst,
äh,
GitHub-Issues.
Ne,
das finde ich auch gut.
Also,
das ist ja eine Plattform,
die wahrscheinlich auch jeder kennt
und die hat ja auch
einen sehr guten Feedback-Mechanismus
schon irgendwie integriert,
also finde ich,
äh,
finde ich sehr passend dafür.
Ja,
finde ich fast besser,
als eine Mailing-Liste
zum Kommunizieren,
gerade wenn es um sowas geht.
Weil man kann ja theoretisch,
äh,
Bezug auf eine einzige Zeile nehmen
und, äh,
sagen,
hey,
in der Zeile,
wie soll denn das?
Das ist doch,
äh,
ist doch Quatsch,
weil das
On-Click-Attribut
ist doch total sicher.
Und wenn es dann,
wenn es dann Meta wird
oder High-Level
und gar nicht so sehr
um die spezifische
Implementierung
oder,
oder wie sei so ein Algorithmus
abgebildet ist in der Speck,
sondern,
sondern den Zustand der Speck
und wie das irgendwie
früher oder später mal
zu einer
tatsächlichen,
zu einem tatsächlichen
Standard wird,
das passiert dann halt
in den W3G,
in den W3C-Foren
wie der Mailing-Liste
und so weiter.
Und da gibt es natürlich
auch W3C-Prozesse
und jetzt ist es
halt noch nicht mal
ein Working Draft,
muss ich dazu sagen,
sondern es ist ein
Community,
ein Draft
Community
Group Report,
was nichts anderes heißt,
als
da haben Leute
mal was aufgeschrieben.
Also es hat
in,
in W3C-Terminologie
hat es einfach
keine Bewandtnis.
Niemand hat sich
für irgendwas committed
und,
und sowieso.
Was aber auch ein bisschen
mit W3C-Prozessen
zu tun hat
und der Tatsache,
dass wir halt
Dinge aufsplitten müssen
und WhatWG
dann wiederum
andere Prozesse hat
und
das HTML
und der DOM-Spec
primär
und
kanonisch
von WhatWG
spezifiziert werden.
Aber ich finde es gut,
dass du es
WhatWG
jetzt mal sagst,
weil ich habe im Vorfeld
für das Spiel
recherchiert,
wie man das jetzt
eigentlich richtig ausspricht.
Ich habe es schon
so oft gelesen
und das Tolle ist,
man landet auf einer Seite,
die sagt,
ja,
du kannst das so aussprechen,
so oder so.
Ja,
der Niederländer,
mit dem ich da gerne
zusammenarbeite,
der sagt,
glaube ich,
WhatWG.
Okay,
dann sagen wir ab sofort
WhatWG.
Das gefällt mir gut.
Ich glaube,
es gibt auch welche,
die WhatWorking Groups
sagen,
aber das kann echt
verwirren.
Aber ja,
genau.
Worauf wollte ich hinaus?
Richtig,
G-Tabishus.
Okay.
Wenn jetzt jemand
zuhört und sagt,
das klingt total spannend
und ich würde gerne
irgendwo mitarbeiten
oder ich habe vielleicht
eine Idee
für einen komplett
neuen Draft,
für eine neue API,
die doch ganz cool wäre.
wie hoch sind die Hürden
an so Standards
mitzuarbeiten?
Kann das theoretisch jeder?
Natürlich mit dem
entsprechenden Hintergrundwissen
schon ein bisschen,
aber wie läuft das denn?
Das hat tatsächlich
eine gewisse Abhängigkeit
von der Schöpfungshöhe
des Beitrages
und das ist jetzt wieder
so eine W3C-Bürokratiegeschichte,
über die ich fast gar nicht,
am liebsten gar nicht
reden würde,
aber ich versuche es mal
zu erklären.
Ich kann es aber auch,
ehrlich gesagt,
nicht so super gut erklären.
Und zwar die Idee
vom W3C ist tatsächlich,
dass sehr viele Firmen
da Mitglied sind
und wenn man sich
innerhalb des W3C
als alle W3C-Mitglieder
darauf geeinigt hat,
dass etwas eine gute Idee ist
und im Rahmen einer Working Group
bearbeitet werden soll,
das heißt noch nicht,
dass es fertig ist,
sondern nur,
dass es bearbeitet werden soll,
dann macht man gleichzeitig
auch ein Claim,
dass man entweder
keine Patente hat
auf die Technologie
oder die Patente
niemals einsetzen wird.
Und ich weiß nicht,
was das bedeutet,
wenn man als,
ich sag mal,
Außenstehender
im W3C mitarbeitet,
wie das funktioniert,
weiß ich leider ehrlich gesagt nicht.
Das heißt,
die meisten arbeiten dann tatsächlich
bei einer Firma,
die auch wirklich Mitglied ist?
Die meisten.
Natürlich,
wie gesagt,
Schöpfungshöhe,
auch so ein schreckliches Wort,
aber wenn es natürlich
um irgendwelche Sachen geht,
Verbesserungen an der Spezifikation,
die nicht wirklich
was damit zu tun haben,
wie es funktioniert,
sondern eher was damit zu tun haben,
wie wir es erklären,
dann ist es ein ganz einfaches Ding,
weil dann ist es halt
keine Änderung
im technischen Sinne,
was spezifizieren wir her,
sondern nur eine Änderung im,
ich sag mal,
eine redaktionelle Änderung sozusagen.
Die sind immer unproblematisch.
Also wenn ihr zum Beispiel
etwas viel besser erklären könnt
als ich
und das halte ich für
äußerst wahrscheinlich,
dann ist das zum Beispiel
gar kein Problem.
Wenn man sagt,
ich würde gerne
ein bisschen coden,
ein bisschen probieren,
dann ist es komplett
unproblematisch
zum Beispiel
beim Polyfill mitzumachen,
weil das ist einfach
ein Mozilla-Projekt,
Open Source,
Mozilla Public License
und fertig.
Also es ist nicht nur
Open Source
und auch freie Software
und da gibt es
auf jeden Fall auch
Open Issues,
die teilweise
sehr kompliziert sind
und teilweise
überhaupt nicht kompliziert sind.
Das ist, glaube ich,
tatsächlich
besser.
Und ich weiß nicht,
ob ich,
ich glaube,
solange das noch
so ein
Community-Group-Report
ist im W3C,
kann da, glaube ich,
auch jeder rumschreiben
und machen,
was er will.
Aber ich weiß nicht,
wie sich das ändert
und wie bald das passiert.
Von daher
tut es mir leid,
dass ich da so eine
unzufriedenstellende
Antwort gegeben habe.
Ja,
alles gut.
Das gefällt mir aber auch
nicht zu sagen.
Ja, ich weiß nicht,
ob ihr mir machen könntest.
Doof.
Es gibt, also,
das ist jetzt bestimmt
keine geringe Einstiegshürde,
aber was es beim W3C
auf jeden Fall noch gibt,
jenseits von Firmen,
sind, glaube ich,
sogenannte
Invited Experts.
Das habe ich irgendwie
schon mal mitbekommen.
Genau.
Leute, die in einem
bestimmten Fachbereich,
weiß ich nicht,
sich unter Beweis gestellt haben
oder irgendwie Koryphäe sind,
dass sie da eingeladen werden
und sagen,
hey, hilf doch mal mit hier,
wir wollen hier einen Standard machen.
Ja.
Ja, das gibt es auf jeden Fall.
Aber ich glaube,
das ist den wenigsten vergönnt,
glaube ich,
in dieser Regierer Mitglied zu werden.
Ich glaube,
dass es auch ein Werkzeug ist
für Leute,
die die Anstellung
bei einer Firma verloren haben,
die denen die W3C-Mitgliedschaft
ermöglicht haben,
aber die dann trotzdem
weiter an dem Projekt arbeiten,
obwohl sie jetzt
für eine andere Firma arbeiten,
die entweder
kein W3C-Mitglied ist
oder halt für eine andere Firma
mitarbeiten,
die einfach damit
überhaupt nichts am Hut hat
und man macht das einfach
in seiner Freizeit weiter oder so.
Das ist, glaube ich,
dafür so ein bisschen ein Vehikel.
Aber auch da bin ich mir
nicht hundertprozentig sicher.
Aber ja,
das gibt es auch.
Ja, das ist...
Das ist ja, glaube ich,
gar nicht so billig.
Das geht nicht einfach dahin,
sagst du als Firma,
ich bin jetzt,
ich möchte jetzt
Mitglied sein,
dann unterschreibst du das.
Nee, es kostet Geld.
Aber wenn wir das
ordentlich aufgeteilt haben,
dann sind ganz viele,
ganz viele unserer
Elemente,
unserer Spezifikationen
im WhatWG
und da ist das alles einfacher.
Da kann nämlich einfach
jeder mitmachen.
Ich glaube,
da musst du auch so ein
Contributor-License-Agreement
unterschreiben,
dass du halt keine Patente hast
oder so,
aber das kannst du ja
als Einzelperson irgendwie
dann doch nochmal anders machen.
Also,
ich schau hier gerade,
also es ist,
für Non-Profit
mit Revenue
unter 2,2 Millionen Euro
im Jahr
kostet es pro Jahr
1.950 Euro.
Das ist die eine Seite,
das ist die eine Richtung
und wenn man ganz nach oben geht,
Profit Organisation
that has annual growth revenue
is measured by the most
recent audited statement
of greater or equal
than 800 Millionen.
Also so große Firmen.
Also Apple oder Google
oder so zum Beispiel.
Genau,
68.000 Euro im Jahr.
Aber für die ganze Firma dann,
oder was?
Für die ganze Firma, ja.
Für die ist es aber
wahrscheinlich wenig Geld, oder?
Also da brauchst du,
musst du wahrscheinlich nicht
bis zum Finanzchef laufen,
um das abgesegnet zu kriegen,
kann ich mir vorstellen.
solche Firmen funktionieren.
Bei uns muss man, glaube ich,
ab 200 Euro zum Finanzieren.
Das ist ja alles ein bisschen,
äh,
ein bisschen knapper
mit dem Geld.
Ach so, ja, genau.
Non-Profit, ne?
Genau.
Aber, äh,
ja, ja, das ist,
also wir sind,
ähm,
da kann man auch eine Sendung
drüber machen,
machen wir aber nicht.
Wir sind halt irgendwie
700 Leute oder so, ne?
Und ich glaube,
ich mache immer den Witz,
bei Google gibt es mehr
Security Engineers
als bei Mozilla Angestellte.
Also das ist einfach absurd.
Das ist einfach absurd.
Ähm,
weil das sind nämlich
irgendwie im Zweistell,
also das sind irgendwie,
ich weiß nicht,
was die richtigen Zahlen sind,
aber es sind, ähm,
im zweistelligen Tausender-Bereich,
glaube ich,
zum Beispiel bei Google
oder sowas,
da für Leute arbeiten.
Das ist einfach
ein, äh,
ein komischer Vergleich.
Aber nochmal zurück
zum Thema,
wenn du zum Non-Profit
ohne Revenue gehörst,
das heißt quasi dein
Hacker-Space
oder was auch immer,
in welchem Verein du bist,
das ist ja auch
halbwegs bezahlbar tatsächlich.
Aber warum sollte man das wollen?
Es gibt auch irgendwie
so Community,
Community-Contributor-License-Agreement
oder so.
Kann man sich wahrscheinlich
auch durchlesen.
Also es ist bezahlbar,
aber ich, ich glaube,
ich frage mich auch,
warum würde ich das wollen?
Also für meinen Community-Hacker-Space,
ich weiß nicht genau,
warum ich da W3C-Mitglied,
ich glaube,
da würde mir die,
die Kommentier-Funktion,
die es ja überall gibt,
äh, glaube ich, ausreichen.
Dafür muss ich jetzt nicht
mehr mit Mitglied sein.
Ja, ja, das musst du,
wenn du das in Fritz-Kohle
und Marte umrechnen
ist für den Hack-Space,
dann ist das,
achst du dich sehr unbeliebt.
Ja, richtig.
Äh, ich habe gerade mal geguckt,
Google-Mitarbeiter,
das ist sogar noch mehr,
äh, wenn ich das richtig sehe,
äh, waren es letztes Jahr
135.000 Mitarbeiter.
Ah, krass.
Das ist, äh, einfach nicht.
Ja, lag ich mal
in der Größenordnung daneben.
Das ist, es ist schon,
es ist schon enorm,
aber die sind,
die wachsen auch extrem schnell.
Also, wenn man die zahlen,
ich habe hier schon
eine Statista-Statistik,
das waren,
2020 waren es 135.000,
2018 waren es noch 98.000,
das heißt,
die haben in zwei Jahren,
äh, 37.000 Leute eingestellt.
Das,
ich weiß gar nicht,
wofür.
Was machen die denn alles?
Das ist halt eine Großstadt,
ne, über 100.000 ist eine Großstadt.
Ja, es ist irgendwie
so halb Karlsruhe gefühlt, ne.
Also, das ist schon,
schon enorm.
Ähm, aber du hast,
du hast gerade schon gesagt,
ja, man könnte irgendwie
eine ganze Sendung füllen
über, über Arbeit und so weiter,
ähm, aber so ein bisschen
würde ich schon gerne noch wissen,
wie du das so empfindest,
bei Mozilla zu arbeiten.
Du bist da schon relativ,
ein Punkt haben wir, glaube ich,
noch zu diesem Meta-Draft-Gedöns
und dann können wir das noch
ansprechen vielleicht.
Und zwar,
wie, wie läuft denn
letztendlich die Einigung ab?
Also, jeder geht zu seinen Input,
aber wer hat denn dann so
am Schluss die, die,
ja, die Deutungshoheit
oder, oder geht's dann Voting
oder wie wird denn dann gesagt,
okay, wir machen's jetzt doch so?
Weil wenn da so viele Leute mitarbeiten,
wer, wer, wer entscheidet denn da?
Im W3C gibt's grundsätzlich
so eine Konsenspolitik,
das heißt, du, ähm,
sprichst relativ lange über
Für und Wider
und versuchst,
eine Einigung zu finden,
ähm, aber wenn tatsächlich,
äh, gesagt wird,
so jetzt Entscheidung auf den Tisch,
dann, äh, heißt es auch tatsächlich
Call for Consensus,
das heißt, einer sagt,
wir machen das jetzt folgendermaßen
und jetzt ist der Zeitpunkt,
und, ähm,
jetzt ist der Zeitpunkt,
äh, wo wir das auf den Tisch legen
und die Entscheidung muss gefällt werden
und ich glaube,
so ein Call for Consensus
hat normalerweise so zwei Wochen Zeit
und bis dahin kann halt jemand sagen,
ne, ich bin dagegen
und dann muss es alles wieder von neu starten.
Das ist so grundsätzlich
das W3C-Entscheidungsmodell.
Spezifisch jetzt
in der Spec
gibt es, glaube ich,
gab es bis jetzt, glaube ich,
noch keine Punkte,
wo wir uns wirklich gestritten haben
und komplett anderer Meinung waren.
Einfach auch, weil, ähm,
weil, ich glaube,
die komplizierten
und die strittigen Sachen,
da haben wir uns halt auch einfach
immer jemanden von außen gut.
Daniel hat gesagt,
hm, ich kann mir vorstellen,
dass das besser ist
und dann habe ich gesagt,
ja, ich glaube aber,
dass das besser ist
und dann haben wir gesagt,
haben wir beide gesagt,
ja, aber so sicher sind wir uns nicht.
Also wir sind, glaube ich,
auch beide einfach nicht so das Ego,
dass wir halt sagen würden,
ich muss das aber so haben,
sondern haben wir gesagt,
dann lass doch mal rausfinden,
wer da Ahnung von hat
oder wer schon mal sowas gemacht hat
und was irgendwie,
ähm,
was irgendwie sinnvoll ist.
Und, ähm,
naja, ein Beispiel,
was wir ja vorhin schon mal hatten,
dass wir anfangs eine API hatten,
die tatsächlich einfach
String rein,
String raus hatten.
Ähm,
da waren das nicht,
ähm,
da waren wir, glaube ich,
alle zähneknirschend.
Also, ich glaube,
ich kann mir jetzt fünf Leute aufzählen,
die halt zähneknirschend da gesessen haben
und gesagt haben,
wir können das nicht gut
und wir können das nicht sicher machen,
also machen wir es nicht.
Aber alle Alternativen sind
total
unzufriedenstellend
von der Perspektive,
was wir erwartet hätten,
was der,
was der Standard kann.
Und da, ähm,
dieses zähneknirschend
hielt auch,
ähm,
zur Freude unserer Zahnärzte
tatsächlich für Wochen an.
Also, ähm,
wo tatsächlich nochmal
rauf eskaliert wurde,
also, ähm,
wo Daniel das dann
in seinem Team besprochen hat
und gesagt wurde,
das ist aber ärgerlich,
das können wir nicht machen,
das ist doch eine doofe API,
das will auch keiner benutzen.
Und wo ich dann noch irgendwie
dreimal, ähm,
internen Follow-Up-Meetings
gehabt habe mit,
mit Leuten,
die am HTML-Standard
schreiben und gesagt haben,
aber muss das denn sein
und können wir nicht irgendwie
und wie wäre das denn?
Und wir hatten viele,
viele Ideen,
aber wir mussten die im Endeffekt
alle verworfen
und sind jetzt da,
wo wir sind.
Ähm,
also,
wie soll ich sagen?
Im Endeffekt haben wir uns
immer irgendwie gut geeinigt
und ich glaube,
äh,
das ist jetzt,
äh,
bis jetzt nie wirklich hart gewesen.
Ach, da kann ich übrigens
nochmal,
nochmal ein Beispiel zu geben,
was wir übrigens gedacht hatten.
Ich hatte ja gesagt,
wir können nicht,
wir können nicht
ein Kontext-Element
uns aus dem Hut zaubern
und sagen,
das wollte der,
ähm,
Entwickler bestimmt
und dann machen wir das
einfach implizit
und, äh,
wenn der das dann später
als was anderes benutzt,
dann ist das vielleicht
auch sein Problem.
Ähm,
das wollen wir ja nicht,
ne,
wir wollen das ja irgendwie
zu unserem Problem machen,
um das ordentlich zu lösen.
Da habe ich relativ lange
auf die Spezifikationen
vom Template-Element
geglotzt
und gesagt,
aber können wir es nicht
parsen,
als wäre es in einem
Template-Element?
Das passt doch,
das ist es doch genau eigentlich.
Ähm,
stellt sich aber raus,
dass das Template-Element
nur HTML kann
und kein SVG
und MathML.
Es kann SVG
innerhalb eines SVG-Elements,
aber es kann nicht
SVG-Elemente ohne
das SVG,
also Elemente,
die zu SVG-Namespace gehören,
ohne drumherum ein SVG.
Das kann das Template-Element
gar nicht.
Und das müssen wir halt
im Zweifelsfall können
in der Sanitizer-API.
Hm.
Ne,
also es kann ja sein,
dass du irgendein Element
ganz tief unten
in einem SVG-Baum hast
und da drinnen
dafür etwas sanitizen willst.
Und das müssen wir halt
unterstützen,
weil das ist halt
Teil von HTML.
Und das Template-Element
kann das gar nicht.
Und dann habe ich gesagt,
wenn die das nicht können,
warum müssen wir das denn können?
Und dann haben wir halt
tatsächlich alle Leute,
die entweder
am Template-Element
gearbeitet haben
oder
halt
HTML-Spec-Leute sind,
die haben halt gesagt,
ja, war ein Fehler.
Aber können wir halt
nicht wegmachen,
weil ist jetzt so.
Ist jetzt so,
haben wir einen Fehler gemacht,
müssen wir jetzt
auf alle Zeit ausbaden.
Wollen wir nicht mehr.
Darfst du nicht.
Und dann wieder
Zähne knirschen,
Zähne knirschen.
Also,
ja,
ist schwierig.
Ist teilweise
wirklich schwierig,
aber bis jetzt
ohne Meckern,
ohne böse E-Mails
und ohne Anschreien.
Also,
alles irgendwie
dann auch okay,
würde ich sagen.
Ja.
Beantwortet das die Frage?
Ja,
auf jeden Fall.
Okay,
gut.
Cool.
Bin sehr lange
ausgeholt,
glaube ich.
Dann haben wir
jetzt das eigentliche Thema
durch.
Jetzt darfst du
noch ein bisschen
nachbohren.
Darf ich mal eine Frage
noch stellen?
Wenn du mich so herrlich
unterbrochen hast,
da kriegen wir wieder
Ärger in den Kommentaren.
Du kriegst wieder Ärger
in den Kommentaren,
dass du mich nicht
unterbrechen sollst.
Genau,
was mich auf jeden Fall
immer interessiert ist,
ich finde Mozilla
eine relativ interessante Firma,
fand ich schon immer,
weil das irgendwie
ein ganz besonderes Konzept ist,
wie es funktioniert
und so ein Non-Profit
und auch die Missionen
hinter Mozilla
finde ich interessant.
Deswegen wollte ich dich
einfach mal fragen,
wie du das so empfindest,
bei Mozilla zu arbeiten.
Da gab es ja auch schon
das eine oder andere
Up and Down
in den letzten Jahren,
was so ein bisschen
durch die Medien gespült wurde.
Wie lange bist du eigentlich
da schon dabei
und was für ein Gefühl
hast du dabei?
Oder hast du irgendwie,
wenn du das vergleichen würdest
mit anderen Arbeitgebern vielleicht,
also würde mich einfach mal
interessieren,
was du da,
was du darüber denkst.
Ja,
also das ist halt auch
eine schwierige Antwort.
Also erstens,
mich hat letzte Woche
jemand angeschrieben,
LinkedIn behauptet,
ich wäre jetzt
zehn Jahre bei Mozilla.
Das bezieht mein Praktikum
und meine lange Pause
nach dem Praktikum
und meine Vollzeiteinstellung.
Irgendwie rechnet das komisch,
aber wenn man möchte,
könnte man sagen,
zehn Jahre,
das klingt ziemlich gruselig.
Von daher gab es
ziemlich viel Auf und Ab natürlich.
Ich habe leider
keinen richtig guten Vergleich,
weil ich hatte
einen Studijob
bei einer
bei einem relativ kleinen,
ich glaube,
drei,
vier Personen
Webentwickler-Bude
während meiner Studienzeit,
bis ich dann,
ich glaube,
nach einem halben Jahr
oder einem Jahr
oder so gewechselt habe
zum Lehrstuhl,
weil ich halt konkret
irgendwie was an Forschung
und Websicherheit
machen wollte.
Und als ich mit der Uni
fertig war,
vor zehn Jahren,
nein,
nicht ganz,
neun oder so,
neuneinhalb,
habe ich direkt bei Mozilla
angefangen.
Von daher ist der Vergleich
schwierig bis einfach
nicht vorhanden.
Ich bin aber extrem gerne
bei Mozilla,
muss ich sagen.
Also es ist natürlich
manches schwierig,
vor allem aufgrund der Tatsache,
wie ich gesagt habe,
wir sind irgendwie
700 Leute
und wenn man es nicht selber
macht,
dann macht es kein anderer.
Ein Beispiel ist zum Beispiel
dieser,
dieser Blockpost,
das Sanitizer-API
von den Google
Developer Advocates,
der ist mehr oder weniger,
ich weiß nicht,
wie viel Arbeit da
reingeflossen ist von Daniel,
aber ich glaube,
nicht so super viel.
Das passiert halt einfach
in großen Firmen.
Das ist natürlich
bei Mozilla anders.
Entweder ich gehe halt
in irgendwelche Podcasts
und begeister so lange Leute
an meinem Freitagabend,
dass das halt auch rausfällt
oder ich muss halt
den Blogpost selber schreiben,
sonst schreibt den keiner.
Das ist natürlich schon
manchmal komisch so,
insbesondere wenn man
in Gesprächen,
manchmal ist es halt auch
witzig auf Konferenzen
und wird dann gesagt,
ja, aber ihr
macht jetzt irgendwie
Werbung auf eurer Startseite
oder so
und dann muss man sich
immer rechtfertigen
oder dann wird halt gesagt,
warum unterstützt ihr das nicht?
Google macht das schon seit Jahren
oder was auch immer.
Also man kriegt ja manchmal
so Feedback
und dann finde ich das komisch,
wenn man halt verglichen wird
mit so einem
Non-Profit,
also die Übersetzung
über das Deutsche,
es ist halt einfach
ein eingetragener Verein
in Amerika
und man wird halt verglichen
mit 130.000 Leuten
Technologie-Imperium.
Das ist halt manchmal schon
sehr, sehr absurd.
Ich mache meine Arbeit
aber nach wie vor
extrem gerne,
weil es halt
gleichzeitig auch
so viel Freiheit bietet.
Also auf meinem,
auf meiner Visitenkarte
steht Security Engineer,
aber wenn ich halt will,
dann bin ich halt zum Beispiel
heute Freitagabend
Developer Advocate
oder
oder sonst was
und das ist halt irgendwie
auch so ein bisschen cool,
auch wenn das so ein bisschen,
ja wie soll ich sagen,
so ein bisschen
hemmsärmlich ist
und so ein bisschen,
ja nicht so corporate
oder so,
wie soll man sagen,
ich weiß,
mir fällt keine gute
Beschreibung ein.
Also manchmal ist es,
kommt man sich sehr klein
und ich will gar nicht
amateurhaft sagen,
aber manchmal wirkt es
irgendwie auf einen selber so
und das ist halt
komisch.
Klingt für mich aber
eigentlich ziemlich cool,
also ehrlich gesagt,
weil es klingt so nach,
sei, was du sein willst,
also mach einfach so
und das finde ich eigentlich,
definitiv.
Das wirkt super.
Definitiv
und da wollte ich jetzt
irgendwie zukommen,
was ich persönlich
für mich sehr,
sehr toll finde
und was zu mir
als Person passt,
ich bin immer irgendwie
so ein bisschen Idealist
und ich finde es
unfassbar gut
für eine Firma zu arbeiten,
wo ich weiß,
am Ende des Jahres
sagt dich der CFO,
okay und jetzt müssen wir
unseren Aktionären
Geld ausschütten
und wenn wir das nicht
geschafft haben,
dann sind wir keine
erfolgreiche Firma gewesen,
was sagt denn gerade
der Aktienindex
oder was auch immer,
sondern es gibt natürlich
irgendwie eine Führungsebene
bei uns in der Firma
und die verdienen
halt auch Geld,
aber die machen ja auch
Arbeit für ihr Geld
und alles andere geht halt
nicht in die Tasche
von dem Besitzer
oder dem Gründer
oder den Aktionären
oder so,
sondern das Geld
wird dann halt
wieder reinvestiert
oder andersrum,
es muss halt nicht
so viel Geld
verdient werden,
also wir müssen
nicht so viel Geld
verdienen,
dass wir
keine Ahnung,
irgendwas entwickeln,
was halt nachher Scheit hat
oder dass wir
irgendjemanden reich
machen müssen,
sondern wir brauchen
halt das Geld
hauptsächlich nur,
um diesen Browser
zu bauen
und das ist halt
irgendwie auch cool,
dass ich halt sagen kann,
ja vielleicht gibt es
jetzt ein Feature,
wo irgendwie
etwas ist,
was jemand
auf der Konferenz
mit ihrem Kopf
und sagt,
ey schaltet da aber
jetzt Werbung,
vielleicht sind es
aber auch nur
empfohlene
Artikel,
auf die du klicken kannst,
weil die vielleicht
nett sind zu lesen
und wenn du die nicht
willst,
dann machst du die
halt aus,
aber vielleicht ist es
auch cooler,
wenn du draufklicken
musst und dann
verdienen wir Geld,
als wenn du durchs
Web surfst und
irgendjemand verdient
Geld, weil ständig
deine Daten abgelutscht
werden und der Browser
alles mitsendet,
also ich will jetzt
auch gar keine
lange Diskussion
starten und
es ist übrigens
eine persönliche
Meinung und so
weiter.
Aber ja,
da hört man halt
relativ viel
und manchmal finde ich
das sehr, sehr
schwierig,
darüber reden zu
müssen und ich
versuche es jetzt
einigermaßen
klar zu machen,
dass es meine
persönliche Meinung
ist und ich
finde es halt
cool,
dass es halt
nicht darum geht,
irgendjemanden
reich zu machen,
sondern dass
alles Geld,
was wir verdienen,
halt an die
Leute, die hier
arbeiten,
ausgezahlt wird
und wenn das
Geld nicht reicht,
dann überlegen
wir uns halt
was, um
irgendwie mehr
Geld zu verdienen,
aber es geht halt
nicht darum,
den Leuten
irgendwie die
Daten hart
abzugreifen,
dafür haben wir
ja und da bin
ich auch relativ,
nee, kann man
schon sagen,
auch wenn es
vielleicht abgedroschen
geht, bin ich
relativ stolz,
dass Mozilla
halt tatsächlich
dieses Manifest
hat, wo halt
drin steht,
uns ist es primär
wichtig und alles,
was wir tun,
leitet sich
daraus ab,
dass das Internet
offen,
interoperabel
ist, ganz
unabhängig davon,
welche Technologie
du einsetzt,
HTML,
JavaScript und
so weiter,
das darf jeder
schreiben,
das kann jeder
schreiben und
du musst nicht
irgendwie Teil
eines Ogo-Systems
sein oder eine
bestimmte Hardware
einsetzen oder in
einem App-Store
sein oder sonst
was, sondern
es ist für alle
möglich und wir
wollen das und
wir arbeiten aktiv
immer weiter darauf
hin, dass es
möglicher und
möglicher wird,
dass das Web
für alle zugänglich
ist und sicher
und datenschützend
und das finde ich
wirklich sehr,
sehr cool und
das ist mir
persönlich
wichtig,
deswegen bin ich
gerne bei
Mozilla,
kann ich wirklich
so sagen.
So, jetzt
kriegt ihr gleich
ganz viele
Bewerbungen
oder ganz viele
Hass-Mails,
fbraun.mozilla.com
Diese Werbegeschichte,
das ist so eine
Sache, wir haben ja
vorhin drüber
gesprochen, was
kostet eine
Podcast-Folge und
ich sehe es halt
auch an mir, ich
habe da so ein
gespaltenes
Verhältnis, weil
ich sage, ich
hatte auch, ich
habe mich auch so
geärgert, was jetzt
auf der Startseite
jetzt Werbung, also
ich kann das
total nachvollziehen
auf der anderen
Seite, ich glaube
es ist, es ist
super schwer, den
Leuten zu
erklären, warum
sie jetzt, warum
das Geld kostet
und, und dass sie
das auch, dass sie
das dann auch
verstehen, weil ich
glaube, sobald es mal
jemand verstanden hat
und sagt, hey, Mensch,
da arbeiten 700
Leute, die arbeiten
da und die machen
dies und die machen
das und die machen
ganz viel auch nicht
nur, nicht nur den
Browser, sondern auch
irgendwie für
Privacy im Allgemeinen
und für Security und
Accessibility und keine
Ahnung, da wird so
viel gemacht, dass das
was kostet, dass die
Leute das nicht alles
in ihrer Freizeit
machen können, das ist
ja eigentlich, das
leuchtet dann jedem
ein, also das hat, das
hat einen großen
Wert, der erschaffen
wird für die, für die
Gesamtgesellschaft
und wenn man das vor
dem Standpunkt sieht, dann
klickt man vielleicht auch
ganz gern mal auf so eine
Werbung drauf, dann macht
man es vielleicht sogar
bewusst, aber das muss
man erst mal, das muss
erst mal verstanden
werden, was da, was da
dahinter steckt
und das finde ich ganz
wichtig.
Ja, das ist natürlich
teilweise, teilweise sehr
schwierig und ich muss
sagen, ich muss gestehen
eigentlich, dass ich extrem
geizig bin im Internet.
Ich spende leider extrem
wenig für Podcasts, die
ich höre und für, für
Produkte, die ich kostenlos
nutze, ähm, ist mir aber
tatsächlich, äh, bewusst und
ich, ich werde besser, aber
ich muss sagen, ähm, ich
kann's halt auch irgendwie
verstehen, aber, ähm, wenn
es einem extrem wichtig ist,
dann kann man das halt auch
alles aufschalten, ne?
also ich sag jetzt nicht hier dieses
doofe, hä, ist Open Source, dann
kompiliere dir halt dein eigenes und
mach halt irgendwie, kommentiere
den Code aus, nein, es gibt
eigentlich für alles einen
Schalter, also das ist alles, äh,
alles in der Option, wir
verstecken da ja auch nichts.
Also was bei mir jetzt sehr gut
funktioniert, wo ich immer wieder
denke, ach ja, das machst du
jetzt, ist, äh, wenn Wikipedia
diese riesen Werbebanner
schaltet, ähm, und sagt, hey, wir,
wir müssen mal irgendwie, wir
müssen mal wieder Geld
einsammeln.
Das ist zwar mega nervig, aber
ich denk dann jedes Mal, ah, hab
ich dieses Jahr schon was
gespendet, ah nee, okay, dann
schmeiß ich jetzt irgendwie da
noch mal was in den Hut, weil
das ist eine wichtige Sache und
ich glaube, ich weiß nicht, ob
das jetzt ein Modell ist für
Mozilla, ich weiß auch nicht, ob
das macht ihr vielleicht auch
schon, keine Ahnung, ähm, aber
das ist was, wo ich dann immer
so denk, oh ja, stimmt, das ist
jetzt irgendwie, das ist was
Wichtiges, ähm, da, da werf ich
jetzt mal ein bisschen Geld
rein, weil, weil ich will, dass
das weiter besteht, weil es mir
persönlich wichtig ist.
Hat bei mir auch schon
funktioniert, ja, muss ich
sagen.
Ich glaube, die Wikipedia, die
macht das relativ gut.
Ich glaube, die kriegt auch
ganz gut, ganz gut Geld.
Als, ähm, intensiver Wikipedia-
Leser bin ich auch, äh, auch
großer Fan.
Also man kann tatsächlich an die
Mozilla Foundation spenden, aber
dieses Geld wird tatsächlich
hauptsächlich für, ähm, wie
soll ich das sagen, für, für
Non-Profit-Projekte eingesetzt,
die wir, die wir ins Leben
rufen, bestimmte Projekte für.
Und ich glaube, Fokus für
dieses Jahr war zum Beispiel, ähm,
und ich befürchte, ich sage es
vielleicht nicht ganz richtig,
Trustworthy AI, dass wir sagen,
Moment mal, alle machen jetzt
AI, was heißt das eigentlich
erstens?
Und zweitens, was bedeutet das
für unsere Daten?
Und drittens, wie kann man dafür
sorgen, dass das transparent ist,
wenn irgendwelche komischen
Systeme Entscheidungen über uns
fällen?
Und, ähm, da hat die
Foundation, die Mozilla Foundation
extrem viel, äh, Arbeit
geleistet, um zu erklären, wie
schnell man aus Versehen und an
welchen Stellen man überall
aus Versehen, ähm, Rassismus und
Vorurteile und all das Schlechte in
dieser Welt in solche Machine
Learning Algorithmen kippt, in
dem man einfach nur den, den
Status Quo messen lässt oder, oder
erraten lässt, was anderes ist es
ja eigentlich nicht.
Da gab's so schöne Sachen schon
auf Twitter, äh, also ursprünglich
mal, was mir jetzt als erstes
einfällt, ist, äh, so ein, so ein
Bot, der aus Tweets gelernt hat, zu
kommunizieren, der dann plötzlich ein
ganz schlimmer Rassist war, ähm, und
dann auch die, diese Geschichte mit
den, äh, mit den Bildern bei
Twitter.
Bildausschnitte, ja.
Bildausschnitte, die eigentlich immer
weiße Menschen, weiße Männer
vorgezogen haben.
Ja, genau, genau, das, das sind so
die Haupt, ähm, die Hauptprojekte, so
von der Mozilla Foundation, die man
eigentlich mit den Spenden bezahlt.
Das heißt tatsächlich, wenn es
wichtig ist, ähm, dem, ich sag mal,
den Produkten Geld zu geben im
weitesten Sinne, sagen wir
tatsächlich gerade, ähm, wir
versuchen Premium-Services anzubieten
und der erste in dieser Reihe ist
Firefox VPN, oder heißt es
Mozilla VPN, ich weiß es leider gar
nicht genau.
Ich seh, ihr seht, ich bin, ich bin
hier, weil ich die Sanitator-APL
richtig, richtig geil finde.
Ich bin hier nicht, weil unsere
Press, äh, Abteilung mich hier für
gebrieft hat.
Ich glaube, es heißt Mozilla VPN.
Das kann man kaufen, äh, das
funktioniert so wie jedes VPN auch
und ihr werdet wissen, der VPN-Markt
ist hart umstritten.
Äh, ich glaube, dass wir halbwegs
vertrauenswürdig sind.
Das sag ich auch, äh, weil es einen
relativ guten, äh, Security-Audit gab
von unserem VPN, da gibt's, äh, auch
ein Public-Report zu.
Ähm, und, äh, selbst wenn man
sagt, ah, VPN, vielleicht brauche
ich das nicht, ist das vielleicht
trotzdem einfach eine geile
Methode zu sein, dann kann ich
denen ja irgendwie Geld zukommen
lassen. Ähm, kann man sich
überlegen.
So, hab ich jetzt grad schnell
gemacht.
Was, äh, VPN abgespendet?
Ich hab jetzt mal gespendet.
Ich wollte grad sagen, wem die
anderen Themen wichtig sind, weil
die, ich, ich find die auch
extrem wichtig und, äh, mir war das
gar nicht bewusst, dass man einfach
so spenden kann und dass es solche
Projekte unterstützt. Äh, der Link
kommt auf jeden Fall in die
Shownotes und ich werd auch nach
der Aufnahme, glaub ich, was
da lassen.
Mhm, genau. Also Mozilla
Foundation, ich, ähm, die haben auch
eine Extra-Seite
foundation.mozilla.org und da geht's
um Advocacy und, äh, ein, ähm, und
auch Fellowship-Programme. Also es
werden tatsächlich auch von dem
Geld Forscher bezahlt, die, ähm,
was ja ganz, ganz, ganz häufig so
ist, wenn man, äh, wenn man in der
wissenschaftlichen Welt unterwegs
ist, in Akademia, wenn man seinen
Doktortitel macht oder seinen
Postdoc, dann muss man ja auf
irgendein, über irgendwelche
Projektmittel bezahlt werden. Das
passiert ja leider nicht umsonst.
Da gibt Mozilla tatsächlich Geld
für Projektmittel, spezifisch für
Trustworthy-AI und, ähm, wie das ist
mit, mit Discrimination und Bias und
so weiter. Und da gibt's dann halt
so ein Fellowship-Programm, genau.
So. Wow. Cool. Viel gelernt.
Ja. Ähm, dann können wir jetzt mal
kurz durchatmen und, äh, wenn wir
jetzt nichts mehr da hinzuzufügen
haben, Fragezeichen, wer was sagen
möchte, muss das jetzt schnell tun.
ansonsten, wenn wir jetzt, würden wir
jetzt zur nächsten Rubrik gehen, die
dann auch ganz schnell vorbei ist
wieder.
Das Geil-Teil.
Geil-Teil.
Ja, das Geil-Teil heute von, zumindest
das von mir, ähm, ich würde, würde
mir rausnehmen, da mal anzufangen, ist
eigentlich was ganz furchtbares.
Und zwar ist das ein, ein Link, äh, der
da heißt, äh, how I experience the web
today. Ähm, und wenn man da drauf geht,
dann sieht man erst mal so was, was so
aussieht wie so eine Google-Suchergebnis-Seite
mit einem Ergebnis. Also, und ansonsten ist die
Seite relativ weiß. Äh, und, äh, man darf auf
keinen Fall den Fehler machen, da drauf zu
klicken auf, äh, auf, auf, auf den Link aus dem
Suchergebnis. Weil dann geht der Wahnsinn los. Ähm, dann
kommt erst ein Cookie-Layer, den man dann, äh,
akzeptiert. Und dann kommt, äh, hier
möchtest du Notification, äh, zulassen im
Browser. Und dann, äh, nochmal Notification. Und
dann soll ich zum Newsletter mich anmelden. Und
dann wird nochmal ein Adblock detektiert. Und
ich soll dann noch was, direkt was kaufen. Und
dann irgendwann muss ich noch Continue
Reading drücken. Und dann darf ich den
Content sehen. Der ist aber so werbeüberlastet,
dass ich eigentlich gar nichts sehen kann. Und
rechts unten geht ja noch so ein Chat auf und
noch ein Video und ich scrolle und dann
geht noch ein Fenster auf. Und es ist
einfach der völlige Wahnsinn. Und, äh, es ist
leider so, dass viele Seiten tatsächlich
genauso sind heutzutage. Ähm, und es ist ein
ganz schönes Beispiel dafür, ähm, wie das
Web irgendwie so in eine komische Richtung
abgedriftet ist. Der Konstantin und ich, wir
haben uns vorhin schon, äh, im Vorfeld
drüber unterhalten und haben gesagt, ja, das
war, das war ja nicht immer so. Ähm, und, äh, ja, es
ist einfach, ähm, einfach mal draufklicken und
keinen Spaß haben an der Stelle, weil es ist, äh, es ist
sehr frustrierend und es, aber dadurch, dass es
halt keine echten Ads sind, sondern halt nur so ein, so ein, so ein, so ein Mockup. Ähm,
ähm, ah ja, genau. Und wenn ich die Seite verlassen will, dann kommt dieser, möchtest du diese
Seite wirklich verlassen? Ja, genau. Es sind auch schöne Details. Also wenn du dann, äh, die
Cookie-Meldung nicht einfach akzeptierst, dann edit Cookie
Preferences. Also auch schön dieses, äh, UI, ähm, Anti-Pattern, dass halt dieser Accept-All-Cookies-Button ganz
großgrün ist und dann dieses Accept-Settings, was ich ja eigentlich will in diesem
Overlay, dass das dann so ein ganz kleiner grauer Link ist, so am Rande, den man eigentlich
nicht klicken würde von sich aus. Sehr schön. Also, äh, man hat große Schmerzen, da rauszukommen
und zum Content zu kommen und dann, wie gesagt, wenn man, wenn man, äh, zehn Zentimeter, äh, zehn
Zentimeter, zehn Pixel scrollt oder so, dann kommt direkt das nächste Pop-Up und es ist echt
der Wahnsinn. Also, äh, wie gesagt, das macht keinen großen Spaß, aber es ist irgendwie ein
bisschen geil, so für, für Masochisten, glaube ich, für so Web-Masochisten ist das was.
Genau, äh, und, äh, hast du auch was mitgebracht, Freddy?
Ja, tatsächlich. Es ist, ähm, ist vielleicht ein bisschen nerdy, aber mir hat es tatsächlich
geholfen. Ähm, und zwar ein Git-Befehl, der heißt Git-Worktree. Äh, für alle, die es nicht
kennen, man hat ein relativ großes Repository ausgecheckt, arbeitet gerade an einem Pull-Request,
der ein bisschen länger ist und dann kommt irgendwas um die Ecke, ob es, äh, was ist, was einem selber
aufgefallen ist oder jemand hat Bescheid gesagt, äh, folgendes. Ähm, und man muss jetzt Pause
machen und in einem anderen Branch weiterarbeiten. Hat aber mega dirty Stash hier und das ist
teilweise schon in der Staging und das noch nicht und teilweise neue Dateien und angelegt
und das ist mega kacke und man will das jetzt eigentlich, will man das jetzt auch nicht mehr
committen und hast den nicht gesehen, sondern das ist halt dieses eine Projekt, da werde
ich auch noch eine Woche dran arbeiten und ich will es fertig machen. Eigentlich will
ich das ganze Projekt nochmal in ein anderes Verzeichnis neu auschecken. Ich will es aber
auch nicht wieder komplett neu alles runterladen und hast den nicht gesehen. Und genau das macht
Git-Worktree. Im Endeffekt gibst du an Git-Worktree-Add, also wie hinzufügen, und dann gibst du
minus B einen neuen Branch an oder vielleicht einen Branch, den du schon hast, einfach den, den Branch
Namen und dann gibst du einen Pfad an zu einem neuen Verzeichnis, das für dich erstellt wird. Nämlich
zum Beispiel, ähm, ähm, deinen Projektname 2 oder deinen Projektname Bindestrich und was auch immer
die andere Aufgabe ist, die du damit verbindest. Und dann legst du dir ein Verzeichnis an, aber du hast
halt nur einmal das Repository ausgecheckt und Git versteht für dich, ähm, und die Daten, die Git
für dich im, im Rücken hält, sind eigentlich nur in einem Git, also Punkt, Git Unterverzeichnis, die
Metadaten, die sind halt einfach nur verlinkt. Das heißt, du hast nicht den ganzen Kram doppelt und
dreifach auf der Platte. Ähm, für mich extrem nützlich und wichtig, weil ich an Gecko arbeite und wie man
sich vielleicht vorstellen kann, das ist eine riesen, äh, riesen Codebase und irgendwann habe ich gemerkt, dass
mit dem Branch ist Checken, das geht mir so auf den Sack und dann wieder aufräumen und manchmal geht
dann doch was flöten und das ist echt ärgerlich und C++ ist sowieso nicht schön. Ähm, und dann hat ein
Kollege gesagt, ja, weißt du was, ich habe einfach das komplette Repository zweimal
ausgecheckt, ähm, die Festplatte reicht dafür und wenn die nicht reicht, dann sollen wir halt eine andere
Festplatte hinstellen. Und dann hat ein anderer Arbeitskollege gesagt, ja, aber kennst du schon, Git WorkTree,
und seitdem, ähm, ähm, ist kein Witz, mache ich ungefähr alle halbe Jahre, mache ich einen Tweet
einfach nur mit den, mit der Git WorkTree, äh, Dokumentationsseite von der, von der Git Webseite und
dann ist es meistens so ein, so ein Emoji mit Sternchen Augen oder Herzchen Augen, weil ich es einfach so
nützlich finde. Und, äh, dann habe ich tatsächlich auch einfach drei Gecko-Verzeichnisse in meinem Home
Directory, nämlich irgendwie Gecko Security Patches und Gecko Sanitizer API und, äh, Gecko habe ich
vergessen. Und, äh, aber halt die ganzen Metatoren auf der Platte, das ist sehr schön.
Cool.
Das ist mein Geil-Teil.
Das ist tatsächlich geil. Das hatten wir auch in unserer Git-Folge, glaube ich, nicht.
Nee, ich kann mich auch nicht erinnern.
Das höre ich jetzt auch zum ersten Mal und ich kenne das Problem, das du hast und damit
löst. Das heißt, ich werde das, äh, direkt mal einsetzen und, äh, dann vielleicht, vielleicht
musst du mich in einem halben Jahr dann mit einem Tweet dann doch nochmal dran erinnern,
dass ich es vielleicht dann doch nochmal, aber ich will es auf jeden Fall direkt mal ausprobieren,
weil ich kenne das Problem zur Genüge und es ist genau dieses, es ist irgendwie, ich
habe da Changes und ein Stash und keine Ahnung und dann hin und her und ich muss jetzt aber
doch nochmal irgendwie was, ah, ja. Also es ist wirklich, äh, es ist sehr, sehr nervig
und, ah, du hast, äh, Folge 25, hat Konstantin gerade noch, war unsere, war unsere Git-Gott-Folge.
Ähm, genau, aber da war, kam das nicht drin vor, also es ist echt eine, eine gute Ergänzung.
Vielen Dank an der Stelle.
Sehr gutes Geil-Teil.
Gerne.
Tatsächlich geil.
Cool, ja.
Ja, damit sind wir dann tatsächlich am Ende, ne?
Genau.
Gibt es, gibt es noch irgendwas, was wir noch vergessen haben, was du noch sagen möchtest, äh,
Freddy?
Vielen Dank, dass ich hier sein durfte.
Vielen Dank, dass du da warst und dass du dir die Zeit genommen hast.
Ja, gerne, es hat Spaß gemacht, auch wenn ich unbefürchte, dass meine Stimme so über
die Stunde hinweg geht.
Dann trink mal viel Tee und, äh, gute Besserung.
Danke, danke.
Auf jeden Fall auch von mir gute Besserung.
Bei uns hat immer der, der Gast das letzte Wort, also darfst noch irgendwas an unsere
ZuhörerInnen richten, was du möchtest.
Ähm, lasst euch impfen, benutzt Firefox, ähm, spendet Geld an gemeinnützige,
Institutionen, wenn ihr am Ende des Jahres Geld übrig habt.
Danke.
Ciao.
Vielen Dank.
Ciao.