Revision 723: Cross-Origin Storage API – Caching über Origins hinweg, mit Thomas Steiner

0:00Und zwar geht es um die Cross-Origin-Storage-API. Getrieben ist das Ganze natürlich von AI, zum Beispiel der Observierung, dass wenn man mit Transformers.js, mit, Web-LLM oder sowas eine AI-Applikation programmiert, dann musst du jedes Mal das AI-Modell runterladen. Und worum wir uns eben kümmern wollen, ist zu sagen, es gibt im Web, wenn man die gleichen Ressourcen verwendet, durchaus sehr viel verschwenderische Downloads, verschwenderische Speicherungen von Daten, die man eigentlich schon lokal hat.

0:30Und wenn man sich darüber ein bisschen Gedanken macht, ist man sehr schnell beim Thema Hash-basierte Speicherung. Also sprich, dass du halt sagst, okay, sobald der Hash eine Ressource der gleiche ist, dann ist es eigentlich egal, wo diese Ressource herkommt. Revision 723. Wir wären heute zu dritt. Da hätten wir aus dem Team einmal den Peter. Hallo Peter. Moin, moin. Ich bin der Shep und wir haben wieder einen Gast. Und zwar ist das der Tom, also der Thomas Steiner von Google. Hallo Tom. Hallo.

1:27Thomas, du warst jetzt echt schon ein paar Mal bei uns zu Gast. Ich glaube, ich weiß nicht, ob wir dich noch vorstellen müssen. Und ich glaube, Leute, die so Web-Plattform-Dinge verfolgen sollten, deinen Namen auch schon so ein paar Mal hier und da gesehen haben und auch auf Google I.O. Talks und so weiter. Du bist der Fall bei Google. Und zuletzt warst du bei uns zu Gast zu dem ganzen Komplex an AI-APIs, Local AI-APIs. Genau, unter anderem auch eben die Prompt-API, die so ein bisschen so ein Aufreger war neulich.

2:04Also wer da nochmal hören will, was dahinter steckt, dem sei die Folge auf jeden Fall empfohlen. Genau, und heute wollen wir sprechen über was Neues, was ihr im Köcher habt. Also ihr, du und noch ein paar andere Leute, und zwar die Cross-Origin-Storage-API. Ja, ganz genau. Ja, also, wenn ihr mich nicht kennt, DeathRail bei Google und ja, schon ziemlich lange bei der Firma und bei der letzten Aufnahme hatten wir über die Prompt API gesprochen.

2:34Das war, glaube ich, so ungefähr ein Jahr her, weil ich hatte die Folge gehört, die kurz vorher dran war und lustigerweise war dann der Kommentar so, ja, diese IO, also 2025, die war so relativ langweilig und das war natürlich so, oh, okay, lass uns drüber sprechen. Okay. Und ja, dieses Jahr war die I.O. zumindest für mich persönlich sehr, sehr aufregend, weil Propped API und da gab es dann diesen großen Artikel von, That Privacy Guy, ich weiß gar nicht, wie der im echten Leben heißt, dieser Guy.

3:06Und ja, also der Auffang war natürlich so, Google-led, uneingeladen, ein 4GB-AI-Model auf meinem Computer und dann gab es natürlich die Geschichte rund um Firefox, die das ganze Thema dann so ergibt, das SIM, dass man Terms and Conditions für eine Web-Aki hat, diskutiert haben und Model into Op, auch sehr, sehr spannendes Thema, was wir intern natürlich uns auch fragen, wie kann das denn funktionieren? Wenn ich den Konkurrenz-Podcast von Syntax FM empfehlen darf, Da war Jake vor kurzem und hat das Thema nochmal kurz erklärt.

3:38Ja, stimmt. Aus seiner Sicht ist vielleicht auch ganz spannend. Ist englisch natürlich, also wer jetzt deutsche Podcasts wird, das ist nicht für euch, aber genau. Ist ein spannendes Thema gewesen, die Prompt API ist inzwischen gelauncht in Chrome 148, war ja schon in Extensions möglich ab 138. Genau, aber jetzt bei dieser Folge geht es oder soll es um etwas Neues, anderes geben, was nicht zwingend nur AI ist, zur Abwechslung mal. Und zwar geht es um die Cross-Origin-Storage-API.

4:12Getrieben ist das Ganze natürlich durchaus von AI, zum Beispiel der Observierung, dass wenn man mit Transformers.js, mit, WebLLM oder sowas eine AI-Applikation programmiert, dann musst du jedes Mal das AI-Modell runterladen, selbst wenn ein anderer Origin schon exakt das gleiche Modell runterladen hat. Aber ich habe gesagt, nicht nur AI, weil dieses Problem hatten wir schon, seit wir Websites mit jQuery gebaut haben. Und es gab eigentlich schon immer so diese Idee, lass uns doch einfach jQuery in den Browser reinbauen.

4:44Das war schon immer keine gute Idee, das direkt in den Browser zu bauen. Es gab ja diese Idee der Standards-Library irgendwann in Chrome. Das war dann so ein Folgevorschlag. Es war jetzt auch, glaube ich, nicht zwingend nur bezogen auf, dass man Speicherplatz und Downloadplatz sich sparen möchte, sondern auch um den Standardisierungsprozess etwas schneller zu betreiben, betreiben zu können, indem man etwas sagt, indem man, so eine Sache wie Virtual Scroller nicht als Browser-API implementiert, sondern quasi so intern so eine Art Polyfill einbaut.

5:25Das würde eben den Prozess etwas beschleunigen. Es gab dann eine Geschichte rund um die Toasts und so weiter, also diese mini-aufpoppenden Notifications, wo dann eben sich herausgestellt hat, das ist vielleicht, wenn man das einfach mal nur so kurz zusammenklappt, keine gute Idee, was jetzt Accessibility auch angeht und so weiter. Genau, also das ist, würde ich sagen. Entfernt vielleicht in die gleiche Richtung einzuordnen, aber es ist schon ein anderes Thema.

5:55Genau. Worum wir uns eben kümmern wollen, ist zu sagen, es gibt im Web, wenn man die gleichen Ressourcen verwendet, durchaus sehr viel verschwenderische Downloads, verschwenderische Speicherung von Daten, die man eigentlich schon lokal hat. Und wenn man sich darüber ein bisschen Gedanken macht, ist man sehr schnell beim Thema Hash-basierte Speicherung, also sprich, dass du halt sagst, okay, sobald der Hash eine Ressource der gleiche ist, ist es eigentlich egal, wo diese Ressource herkommt.

6:23Vielleicht einen Schritt zurück. Wir waren ja schon mal da, als wir alle JQuery verwendet hatten und dass diese ganzen CDNs gab. Das Google Ajax CDN oder Microsoft hat was Ähnliches, wo man eben sagt, okay, wenn wir uns einfach alle auf die gleiche URL einigen und in der URL ist die Version drin, also irgendwie Google Ajax, libraries.com, wie auch immer die URL hieß, slash jqud slash v3 slash 1 slash 4 oder was auch immer. Dann sind wir eigentlich gut, weil, ja, gleiche URL, die Version ist in der URL drin, manche URLs haben ja auch so eine Art Hash, wo man dann sagt, okay, man prübelt einfach den Hash direkt in die URL rein und solange wir uns dann alle einigen auf die gleiche URL, sollten wir dann eigentlich gut sein und das war auch ein Stück weit so, aber, sehr schnell fing dann eben an, die Leute sich Gedanken zu machen und zu sagen, okay, wir haben doch eigentlich hier Bundler-Abstahl, wir haben doch Webpack und wie sie alle heißen und die haben natürlich dann sehr schnell gemerkt, so von der ganzen jQuery verwendest du eigentlich nur, was weiß ich mal, 10%.

7:31Alles andere ist Dead Code und der Bundler ist dann sehr schnell dran und macht eben DCE, Dead Code Elimination und haut eben diese ganzen anderen 90%, die nicht gebraucht werden, aus deiner lokalen jQuery aus. Das ruiniert dir dann natürlich den Cache-Effekt, weil, ja, dann ist natürlich deine jQuery-Kopie lokal, die du brauchst, nicht mehr kompatibel mit der, die dein Nachbar-Origin braucht. Und, ähm. Das Ganze wurde dann noch schlimmer, in Anführungszeichen, als die Leute angefangen haben, nicht nur eine Library über den Wandel zu jagen, sondern eben zu sagen, okay, lass uns doch allen unseren JavaScript Bedarf in einem großen Paket zusammenwandeln.

8:09Und dann hast du irgendwie main.js2578, keine Ahnung, min.js. Und ja, da war dann eben alles drin, komplett zusammengebundelt, irgendwie lowdash und jQuery und was auch immer und natürlich dein eigener Benutzercode. Und ja, dann war natürlich das Thema Caching über gemeinsame URLs sehr schnell kaputt und selbst als man noch vor diesem Status war, man musste natürlich immer sich auf die gleichen URLs einigen. CDNs gibt es nicht besandter mehr, aber es gibt doch einige und die Wahrscheinlichkeit, dass man eben einen Origin hat, der genau die gleiche URL für die jQuery-Ressource verwendet, die man selbst verwendet, war eben relativ klein.

8:51Und es wurde dann noch schlimmer, in Anführungszeichen, indem es besser wurde, nämlich die Browser fingen an, die Caches zu isolieren. Also sprich, wenn ich jetzt XAMPP.com bin und Peter hat peter.de, und wir beide verwenden theoretisch die gleiche jQuery-Version und einigen uns sogar auf das gleiche CDN, dann haben Browser angefangen zu sagen, okay, das ist zwar die gleiche Ressource, aber sie wird von einer anderen Grundorigin ausgeladen, deshalb separieren wir die Caches. Warum wurde das getan?

9:20Weil im Internet leider nichts Schönes haben kann. Und im Internet wird immer, wenn es irgendwie eine Möglichkeit gibt, Missbrauch zu betreiben, Missbrauch betrieben und genauso war es eben auch doch bei diesem Thema. Die Leute fingen an, ganz einmalige Dateien zu erstellen, für jetzt, Shep war auf meiner Seite, Peter war auf meiner Seite, beide haben eine Ressource angefordert und heimlich hat mein Server dann eben für jeden von euch, eine individuell gemintete Version einer Datei gemacht, die zwar die gleiche URL hatte, aber intern einen anderen Wert.

9:52Und wenn ihr uns dann wieder besucht habt auf unserem bösen Origin, dann konnte ich eben einfach sagen, was ist denn hier in eurem Cache drin für, diese Datei und ja, haben dann eben gesehen, ah, okay, das ist die ID 1, 2, 3, dann weiß ich, das war Hans und das war Peter und das war Chef. Und genau, das war dann eben nicht mehr möglich, als die Browser angefangen haben, die Caches zu separieren, und genau all diese ganzen Probleme versucht jetzt Cross-Origin-Storage, anzugehen, zu lösen, besser zu machen. Vielen Dank.

10:24Ja, also ich weiß diese, dass damals auch bei der Diskussion, ob man CDNs nutzen soll, also so zu jQuery-Zeiten, da gab es eben hier Steve Souders war ja so der Performance-Pubst, der hat das halt stark befürwortet. Aber schon da war es so, dass einfach durch die hohe Release-Zahl. Von jQuery und den anderen Libraries es gar nicht so häufig vorkam, dass man exakt dieselbe Version genutzt hat. Und also genau, wenn man das dann mal in Zahlen vor sich gesehen hat, dann hat man irgendwie gemerkt, oh, also für so zumindest Software, die schnelle Release Cycles hat, da hat man irgendwie gar nicht so viel von.

11:11Und ein Thema hatten wir noch gar nicht erwähnt, bösartige Übernahme. Es gab, wie hießen sie, Polyfill.io, glaube ich, von irgendeiner, was mit britischen Zeitschrift, meine ich, die das Guardian oder sowas, die das ursprünglich betrieben hatten. Die Idee war großartig. Du hast gesagt, ich möchte die und die Polyfilts und dann hat der Browser eben dynamisch entschieden, brauche ich die, brauche ich das oder nicht. Dann wurde das CDN übernommen von, ich meine, es war eine chinesische Firma und dann war sofort natürlich irgendwie Stamble drin und Tracking und keine Ahnung was.

11:45Und ursprünglich war da eine URL im schönen Saugerwert, die dir was auch immer zurückgegeben hat, jQuery in der Version 3.4.1 und die neue übernommene Version war dann eben jQuery 3.4.1 und noch ein bisschen Schindluder dabei, und ja, das will man halt natürlich nicht haben, wenn man ein großer Publisher ist und eigentlich davon ausgelden, CDN ist eine vertrauenswürdige Quelle. Ja, ja. Genau, und also. Ihr wollt das Problem lösen. Ich glaube, anders ist tatsächlich dann auch wieder, die, da machen wir quasi so den Rückgriff auf die Prompt-API und Konsorten.

12:28Du hast ja auch gesagt, wenn man jetzt irgendwie sowas wie Transformer.js benutzt und ein Modell lädt, dann ist es natürlich sehr unangenehm, wenn eben jede Präsenz das Modell mit, keine Ahnung wie viel, 100 Megabyte oder Gigabyte, also nicht 100 Gigabyte, aber mit ein paar Gigabyte, runterladen muss. Und bei der nächsten Seite dieses, also ich glaube, das steht einfach so der höheren Adoption dieser Dinge im Weg, so wie vielleicht eben auch von irgendwelchen WebAssembly-Paketen, die ein bisschen größer sind.

13:04Genau, und wir haben es ja gehört, Wenn Browser das shippen, dann finden die Leute das irgendwie auch blöd. Dann hat man dieses Problem zwar nicht, weil es sozusagen ja mit dem Browser kommt, aber hat andere Probleme, wie eben, dass jeder Browser dann anders arbeitet, weil jeder sein eigenes Modell mitbringt und du nicht das bekommst, was du haben möchtest. Genau, und ich glaube, das war der Anlass, und natürlich funktioniert das auch, für andere Typen von Ressourcen, dass die Lösung ist Cross-Origin-Storage.

13:36Wie funktioniert das? Also wie will es dieses Problem lösen, idealerweise endgültig, und gleichzeitig die Probleme, die wir eben genannt haben, umgehen? Ja, also nochmal, das Ganze ist nicht nur AI, also das war mir vor allem ganz, ganz wichtig. Viele innerhalb von Google haben gesagt, lasst uns das Problem noch lösen für AI und nur für AI, weil das ist der größte Hebel, weil was schon erwähnt, da geht es eben um Gigabytes und nicht 200 Kilobytes oder Megabytes.

14:10Aber ja, mir war das eben wichtig zu sagen, nee, das Problem ist weit über AI hinaus und heute sprechen wir meistens nicht mehr über jQuery, heute sprechen wir über React, über Vue. Die ganzen typischen Libraries, Blit, die ganzen Building Blocks, die eben für heutige moderne Websites da sind. Aber es gibt eben auch sehr viele Hidden Champions. Also du hattest WebAssembly erwähnt, es gibt ein sehr populäres Paket, das eben dir erlaubt, Silbentrennung im Web zu betreiben.

14:41Das macht der Browser zwar nativ für viele Sprachen, aber eben für viele Sprachen auch noch nicht oder noch nicht gut genug, sodass viele dann sagen, wir sind ein etablierter Publisher. Bevor wir jetzt dem Browser seine richtig üble Zeilen-Umbrüche nehmen oder Sirben-Umbrüche nehmen, schippen wir einfach ein etabliertes Paket, wo wir wissen, das sieht dann auch ordentlich aus. Und genau, das ist tatsächlich, wie gesagt, ein Hidden Champion.

15:05Wir verwenden sehr viele Publisher, sehr viele Seiten, die einfach Wert legen auf saubere Sirben-Trennung und hat man eben dann das Problem oder das Thema mit WebAssembly, Es gibt Flutter, es gibt Kotlin-Multiplattformen, die dann eben sowas wie Diskia, Grafikbibliothek nach WebAssembly kompilieren. Es gibt PostgreSQL, SQLite als Vasem-Pakete, die dann eben Datenbanken im Web ermöglichen, und FFMPEG, auch großes WebAssembly-Thema, also alle, die irgendwie wahrscheinlich diese Software, die wir jetzt hier verwenden, SendCaster, aber wenn das irgendwo intern FFMPEG-Versen, und genau, Genau, also das Thema ist eben weit über AI hinaus.

15:48WebAssembly, Webfonts hatten wir auch noch nicht erwähnt. Großes Thema, Webfonts. Viele wollen schöne Emojis verwenden, die eben vorhersehbar gut aussehen auf allen Plattformen. Man kennt das ja vielleicht von Windows, wo die Fahnen-Emojis dann teilweise als Buchstaben dargestellt werden, was viele nicht so wirklich toll finden. Und wenn man da eben ein vorhersehbares Rendering haben möchte, dann bist du halt sehr schnell bei sowas wie NotoColor-Emoji.

16:14Und ja, das ist eben eine sehr, sehr große Plattform, die du dann runterladen musst, die wahrscheinlich schon irgendwo in deinem Cache liegt, aber halt nicht verwendet werden kann. Ja. Aber haben all diese genannten Dinger nicht immer noch dieses, wir haben viel zu viele verschiedene jQuery-Versionen-Problemen? Bei so AI-Modellen scheint mir ja so, da gibt es auch reichlich und reichlich Versionen, Aber da scheint mir ja doch insgesamt die Kadenz etwas geringer zu sein als jetzt bei, keine Ahnung, ich bin eine populäre mit WebAssembly implementierte Kiste.

16:48Also wieso ist das jetzt kein Problem mehr, was vorher das Problem war mit jQuery? Das Problem können wir anfangen, ein bisschen zu adressieren. Wenn wir entsprechend gleich mit den Leuten arbeiten und eben das Thema auf den Tisch bringen, dann kann man eben anfangen zu sagen, okay, vielleicht muss das nicht sein, dass man jedes Mal jeden Tag sofort neu released, wenn man weiß, man macht sich dadurch den Cache kaputt. Also, es gibt für Pre-Bit.js ein öffentliches Issue, das können wir vielleicht in den Shownotes verlinken, wo die eben ganz genau das gesendet haben.

17:23Also, Pre-Bit.js, gerade im Publishing-Bereich, sehr populäre Bibliothek, um eben, ich glaube, Header-Bidding zu betreiben, also Ads anzuzeigen und fast jede Seite verwendet diese Bibliothek. Und wenn die eben wissen, das könnte eine Bibliothek sein, die zukünftig von, Cross-Origin-Storage-Caching profitiert, dann haben die eben direkt ins Issue geschrieben, okay, dann muss es vielleicht nicht sein, dass wir sofort releasen, dann können wir vielleicht auch ein bisschen unseren Pace verlangsamen.

17:51Es gibt die Idee, dass man das dann ein bisschen modularisiert, also sprich, dass es eine stabile Core-Version gibt, die dann quasi, was auch immer, ein paar Monate stabil bleibt und dann eben Module, die vielleicht etwas flexibler sind und dann auch öfters aktualisiert werden können, die dann natürlich aber kleiner sind. Also sprich, das Thema ist natürlich nach wie vor da. Es gibt, wenn du auf naxt.fyi gehst, Daniel Rowe hat so eine Seite erstellt, wo man eben sehen kann, wie die Seiten, die auf naxt basieren, ihre Versionen aktualisieren.

18:22Und da siehst du, die sind eigentlich fast alle auf dem neuesten Stand. Also es gibt so eine Hockeystick-Verteilung und dann eben die neueste Version, die populärste ist. Und dann hast du so ein bisschen, ja, gibt es noch ein paar Media-Versionen, aber die meisten Versionen sind ja doch, oder die meisten Seiten sind ja doch auf der neuesten Version ziemlich schnell. Genau, und so, wenn man eben mit den Leuten direkt arbeitet... Meinen wir, es gibt durchaus Chancen, dass die Cache-Hitrate sich verbessert.

18:50JQuery ist natürlich sehr populär, aber ja, fehlt es natürlich Legacy, das niemals aktualisiert wird und wahrscheinlich auch in manchen Fällen nie aktualisiert wurde. Während viele heutige Applikationen, ja, die bauen natürlich auf großen Bausteinen auf und die gehen dann halt quasi den Hype-Train mit und nehmen dann jede React-Version mehr oder weniger mit oder jede Vue.js-Version mit. Also, wir denken, es könnte durchaus Chancen geben, dass wir äußere Cush-Hydraten in der Zukunft haben werden als in der Vergangenheit, wo eben das Thema Cushing mehr so ein Nebeneffekt war, aber eben nicht von vornherein eingepreist war.

19:27Diesmal arbeiten wir von vornherein eben auch gleich mit Nuxt, Next und so weiter, also nur großen, Meta-Frameworks oder Server-Frameworks zusammen, sodass die eben auch von vornherein, wenn sie bundlen, schon mal gucken können, wo ergibt das denn Sinn, dass man vielleicht stabile Bundles erzeugt, die dann auch eine relativ garantierte Cache-Hitrate haben. Und ja, jetzt wollte ich gerade erzählen, wie das Ganze funktioniert. Kleiner Seitenabweg hier, aber bei mir ist es durchaus nötig.

19:56Genau, wie funktioniert das Ganze? Also die Grundidee, das Ganze ist Hash-basiert. Also sprich, wenn ich eine Ressource habe, dann berechne ich den Hash von dieser Ressource und kann dann sagen, ich bin die Seite, keine Ahnung, exsupple.com und ich benötige eine Webfont und diese Webfont hat den Hash abc123. Das prügele ich in meinen CSS rein, also das ist ja so eine Front-Face-Declaration und diese Front-Face-Declaration hat dann eine URL, diese URL hat eine Source, nee, andersrum, diese Front-Face-Declaration hat eine Source und diese Source hat eine URL und in diese URL-Funktion schreibt man dann ja normalerweise die tatsächliche URL rein, wo die Web-Font herkommt und, mit Cross-Origin-Storage für Web-Fonts gibt es dann eben die Möglichkeit, dass man dann dort noch sagt, okay, und, ich verwende einen neuen Request-URL-Modifier, den wir Cross-Origin-Storage nennen, und ja, da kannst du dann eben sagen, wenn diese URL, noch nicht in die Ressource mit dieser URL und diesem Cache, der über die Integrity übergeben wird, wenn die noch nicht im Cache drin ist, also Cross-Origin-Storage, Cache,

21:07dann zieh sie von der URL, die du hast, steck die Ressource in, den Cross-Cache rein und ab da kann dann eben von jeder anderen Website, sobald die Integrity übereinstimmt, also der Hashtag übergeben wurde, übereinstimmt, kann dann auch jede andere Website diese Web-Fall verwenden. Das ist die, eine der deklarativen Formen. Grundlegender ist wahrscheinlich die imperative Form, wo man eben sagt, wir gestalten eine neue Browser-API, Navigator.CrossOriginStorage, das gibt ja schon Navigator.Storage, das wäre Navigator.CrossOriginStorage und dann hast du in.

21:47Navigator.Storage hast du GetDirectory als Grundfunktion, die dir dann eben so ein Root-Verzeichnis gibt und analog dazu haben wir dann eben RequestFileHand. Und diese Request-File-Handle-Funktion, der übergibst du den Hash von der Ressource, die du haben möchtest. Und ja, dann gibt dir die ein sogenanntes File-System-File-Handle zurück. Das im Konzept, das kommt von der File-System-Access-API oder OPFS-API inzwischen dann als standardisierte Version. Origin-Private-File-System.

22:20Und ja, das ist eben so ein klassisches File-Handle. Über dieses File-Handle kannst du dann eine File bekommen, also die eigentliche Datei. Und ja, ab diesem Moment hast du dann das File, den Block und kannst dann mit der Ressource erarbeiten. Das ist also die imperative Form. Die Idee ist analog eben gestaltet zu der OPFS API, wo du hast diese Get-File-Handle-Funktion. Wir haben da eben Request-File-Handle mit parallel auch gestaltet der Create-True-Option, wo du dann sagen kannst, okay, wenn das noch nicht existiert, dann erstelle es, also sprich, das ist dann der schreibende Zugriff auf Codes, und ja, wenn du dann eben create true übergibst, dann kannst du diese Funktion am Ende über einen writable streamen, den Blob, den du schon hast, in der Codes Cache reinschreiben, also rein streamen oder rein pipen, wie auch immer, das ist das alles eben sehr elegant möglich über die bisher existierenden APIs, die wir einfach nur mitverwenden, Also neue Sachen, die wir erfunden haben, sind eigentlich sehr, sehr wenige.

23:26Es baut auf existierenden Grundbausteinen auf. Diese Revision von Working Draft wird euch präsentiert von Node.conf EU, einer knuffigen Konferenz rund um Node.js. Bologna, liebe Hörerinnen und Hörer, wie wär's, ne? Genau dort steigt nämlich Ende September die europäische Edition der Node.conf. Dort könnt ihr euch an zwei Tagen nicht nur Talks reinziehen, sondern auch Zeit mit der Node.community verbringen. Die Konferenz ist nämlich ein unabhängiges Community-Event. Ihr macht also nicht irgendwelchen Arschgeigen die Taschen voll, sondern helft tatsächlich der Community dabei, solche Events auszurichten.

23:59Das Ganze steigt dann auch nicht in einem gammligen Holiday Inn in Graustadt an der Schnarch, sondern in Italien. Es ist sogar ein episches Dinner im Ticketpreis enthalten. JavaScript vs. Tortellini ist also keine Entweder-Oder-Frage. Wenn ihr also schon immer mal einen Italien-Trip von der Steuer absetzen oder über das Fortbildungsbudget eures Arbeitgebers abrechnen wolltet, das ist eure Chance. Tickets und Infos findet ihr auf noteconf.eu. Wir wünschen euch viel Spaß in Bologna.

24:29Und dann gibt es noch andere deklarative Möglichkeiten in Cross reinzugreifen, nämlich über direkte HTML-Integrationen, dass du eben sagen kannst, über Link oder über Script-Tags, dass du denen eben die Integrity übergibst und dann eben auch Cross-Origin-Storage als Attribut. Und genau wie bei der Webfront-Geschichte, wenn der Hash passt, dann kannst du eben direkt über dem Cosgash die Ressource beziehen und wenn nicht, dann wird die Ressource direkt bezogen von Script.

25:02Das ist relativ elegant, weil wenn ein Browser das Ganze noch nicht unterstützt, dann wird das einfach ignoriert, also dann schaut der Browser zwar, okay, ich sehe da ein Cross-Ordent-Storage-Attribut, aber ich weiß nicht, was das ist, ich ignoriere das einfach. Und die letzte Variante, die wir dann noch haben, das wäre die JavaScript-Integration und da ist die Idee, dass man eben über JavaScript-Imports auch direkt über JavaScript in Kost reinkommt.

25:33Also es gibt ja dann Import und dann irgendwie hast du den, die URL letztendlich. Den Ort, wo die Bessource herkommen soll, also keine Ahnung, Import, was auch immer du möchtest, from und dann gibst du eben an, wo das herkommen soll und dann hast du den Import, wie heißt das nochmal, hat einen richtigen Namen, sollte ich wissen, weiß ich gerade nicht, also with und dann sagst du. Import-Attributes. Danke, Import-Attributes, danke. With type JSON zum Beispiel oder with type was auch immer.

26:05Und da ist dann die Idee, dass wir uns direkt reinhacken in dieses System und sagen, auch hier übergeben wir dann die Integrity, das existiert auch schon, und die Cross-Origin-Storage-Storage. Das ist ein Cross-Origin-Storage-Attribut und können uns auf diese Art und Weise dann eben auch direkt in Cross mit reinhacken. Das ist leider nicht progressively enhanceable, also da muss Browsersport da sein, sonst ist es eben ein Syntax-Fehler, aber ja, da gibt es wahrscheinlich auch Wege drumherum.

26:39Wir hatten das ja schon mal über IS-Module-Sims, die dann eben auch so neue Funktionen in JavaScript verfügbar gemacht haben, indem sie so ein spezielles, ja, Script-Type und dann eben was, was noch nicht unterstützt war, was dann der Threadspiler entsprechend umgeschrieben hat. Ja, das haben wir noch gar nicht erwähnt. Es gibt eine Extension, also eine Browser-Extension, die die ATI heute schon unterstützt und genau, da kann man eben über solche Umwege dann quasi die moderne Syntax schon heute verwenden.

27:12Genau, da gibt es Browser-Plugins für alle Browser, glaube ich. Bisher haben wir Chrome und Firefox und Safari ist gerade im App Store Review-Prozess. Da weiß man natürlich nie, was da passiert. Firehawks war sehr, sehr schnell, sehr fix. Ja, bei Safari war ich noch, was da passiert. Aber vielleicht, bis die Folge rauskommt, ist das schon publik. Es gibt eine Ressource, die nennt sich Awesome Cross-Origin-Stored, also so eine klassische Awesome-Liste.

27:42Ähm, das sind die ganzen Ressourcen, ähm, gelinkt und sobald die, äh, Safari-Version rauskommt, werde ich dann diese Liste auch aktualisieren. Auf dieser Awesome-Liste haben wir auch ein paar coole Demos, ähm, wo man eben auch heute schon sehen kann, was da alles möglich wird, ähm, zum Beispiel, ähm, Mr. Doop, kennen viele vielleicht unter seinem, äh, Codenamen, Ricardo, ich glaube, Cabello heißt der, ähm, Mr. Doop ist wahrscheinlich der gewössige Name, genau, äh, Mr. 3JS, ähm, der hat, äh, Descent und, äh, Quake portiert, sodass sie auf 3.js als Bibliothek, quasi als Gaming-Bibliothek laufen, Game Engine laufen.

28:19Und über Cross-Origin-Storage ist es dann eben möglich, dass beide Spiele sich die 3.js-Game Engine sozusagen teilen und. Dann eben einmal nur runterladen, über Cross-Verfügung machen und kannst du eben direkt damit arbeiten. Vielleicht stoppt Ihnen das ja so viel Releases-Hausdauen, weil da weiß ich auf jeden Fall, also 3.js released ja irgendwie auch 3 war am Tag eine neue Version, ich weiß gar nicht, bei welcher Versionsnummer die mittlerweile angekommen sind.

28:46Echt irre. Ja, also zumindest früher war das so. Da bin ich auch drüber gestolpert. Die haben ja tatsächlich kein klassisches Sample, sondern die haben einfach nur Versionsnummern, also 162 oder sowas war, glaube ich, die aktuelle, als ich ja dem R3... Ich glaube, ich war mal bei 60, hatte ich da reingeguckt und als ich fertig gelesen hatte, die Doku war die Versionsnummer schon 61 ungefähr. Ja. Das ist ja fast Web-Browser-esk. Ja, genau. Wenn die Release-Cycles dann jetzt.

29:14Alle zwei Wochen, ist es alle zwei Wochen? Bei Chrome, ja. Und Firefox hat auch gerade geschickt. Sie wollen jetzt auch auf zwei Wochen umstellen. Ja, bald einmal die Woche. Ich würde echt sagen, das ist ein Erfolgsrezept, würde ich sagen. Ja, genau. Vielleicht müsste man noch ergänzen, wenn man sich entscheidet, also man fragt ja an, den Cross-Origin-Storage, hey, hast du, diese Datei oder die Inhalte, die unter diesem Hash sich identifizieren, hast du die?

29:50Wenn ja, gib sie mir. Ansonsten kann man eben, also im Zweifelsfall kann man einfach den Fallback machen auf ganz normal, weiß ich nicht, Fetch und sich das holen. Und das war's. Der Browser cached ja diese Sachen dann auch für das eigene bis er irgendwann mal entscheidet, dass er das evikten möchte oder so. Und man kann hingehen und dann sagen, ich möchte das jetzt auch wirklich tatsächlich, in dem Cross-Origin-Storage abgelegt haben. Muss man nicht machen, aber kann man machen. Und das ist dann standardmäßig immer gescoped, glaube ich, auf den Same-Site-Origin, richtig?

30:29Also das heißt, wer anderes würde nicht davon profitieren. Magst du mal kurz sagen, wie da, der Vorteil in diesem Szenario ist, wenn man eben die Origins nicht, erweitert, sondern sagt, ich nehme das Default, was eben nur meine eigene Seite ist, werden die Daten dann irgendwie länger im Cross-Origin-Storage gehalten, als wenn der Browser die einfach cachen würde? Magst du da kurz noch was zu sagen? Also wenn du eine neue Ressource erstellst, also sprich schreibend auf den Cache zugreifst, dann rufst du auf Navigator, Cross-Origin-Storage, Request-File-Handle, übergibst du ihm den Hash von deinem Blob, den du speichern möchtest und im zweiten Parameter, also der Options-Spec, übergibst du ihm dann Create-True und dann übergibst du ihm die Origins, für die das freigeschaltet werden soll.

31:22Wenn du nichts übergibst, also Origins komplett weglässt, dann ist das Same Site. Same Site ist ein bisschen kompliziertes. Aber letztendlich, man kann es sich vereinfacht vorstellen als alle Subdomains. Also wenn du jetzt der example.com bist, dann kannst du eben quasi alle Subdomains darüber freischalten. Das deckt eigentlich schon viele so klassische, was auch immer, wir sind in der Office Suite und wir haben jetzt halt officesuite.com und dann hast du kalk.officesuite.com, write.officesuite.com und slides.officesuite.com und was auch immer.

31:54Und das deckt eben schon viele Fälle ab, oder so, keine Ahnung, alle diese verschiedenen Office-Programme verwenden ein und dasselbe proprietäre AI-Modell für Rechtschaltkorrektur zum Beispiel oder keine Ahnung. Wenn du dann eben direkt das so übergibst, indem du Origins komplett weglässt, dann wird das freigeschaltet für alle diese Subdomains. Same site. Also ist, wie gesagt, etwas kompliziert. Es sind nicht nur alle Subdomains und da kommt dann immer Extended, Public, Suffix, West, yada, yada dazu, aber vereinfacht kann man...

32:27Ja, das war, glaube ich, so eine Liste, die die Browser da pflegen. Also es gibt Es gab ja auch die Möglichkeit früher irgendwie auf Präsenzen so seine eigene Subpräsenz zu erstellen und die hatte dann auch ein Subdomain und da will man das dann ja nicht sharen drüber. Da hatten wir mal mit dem Fredrik Braun von Mozilla irgendwann das Thema, als wir über Core gesprochen haben. Genau. GitHub-Pages, die leben ja alle auf github.io und dann hast du eben shep.github.io und tomahab.github.io und so weiter.

32:57Die sind natürlich alle auf github.io, aber letztendlich sind das natürlich sehr verschiedene Ressourcen, die du dann natürlich nicht teilen möchtest. Ja. Dann die zweite Variante ist, du gibst eine Liste von Origins an, also dann sagst du eben, ich bin example.com und ich habe auch nach marketing-site.io und was auch immer cdn.jadajada.dev. Und dann kannst du eben quasi so eine Liste an Origins übergeben und die finale und wahrscheinlich die mächtigste Variante ist dann, dass du einfach sagst Origins und dann sagst du Stern, also sprich für alle.

33:29Und das ergibt natürlich Sinn für sehr viele Ressourcen, die eben sehr, sehr populär sind. Jackfury, React, was auch immer, vorher besprochene WebAssembly, Silventrennungsengine und was auch immer. Und da ist es natürlich dann einfach zu sagen, okay, Moment, wir hatten das ja schon mal, hatte ich ganz am Anfang erwähnt, mit im Internet kann man keine schönen Dinge haben. Was, wenn ich jetzt sage, ich prügele dann einfach eine eindeutige Ressource rein für jeden Benutzer?

33:58Schritt zurück. Die eindeutige Ressource hat dann natürlich auch einen eindeutigen Hash. Also das würde schon nicht mehr funktionieren. Und dann ist natürlich noch spannend das Thema Cross-Site-Leaks. Die Hashes, die sind natürlich kein Geheimnis. Also, wenn ich jetzt weiß, es gibt, keine Ahnung, meinebank.de und meinebank.de, die zeigt ein anderes Logo an, wenn ich eingeloggt bin, als wenn ich ein nicht eingeloggter Kunde bin. Also, sagen wir, die zeigt dann an, keine Ahnung, meinebank.de, loggedinuser.png, ja.

34:30Ja, wenn ich das rausfinde, dann kann ich natürlich sagen, okay, wenn ich weiß, dass diese Ressource im Kurs liegt, dann kann ich davon ausgehen, der Kunde, der Benutzer ist ein Kunde von meinebank.de. Und wäre natürlich blöd, von meinebank.de diese Versource im Kost reinzulegen, aber letztendlich hindert sich niemand daran. Hashes sind kein Geheimnis. Jeder könnte, sobald man das rausfindet, dass das der Fall ist, den Hash von meinebank, ist ein gelobter User, GNG, wie auch immer ich die Detail genannt hatte, den Hash ausrechnen und dann einfach direkt Proving betreiben.

35:06Also ich bin jetzt irgendwie Evil Attacker und möchte rausfinden, gibt es jemand, der jetzt vielleicht Kunde dieser Bank ist, dann schaue ich einfach, hat er die Ressourcen mit dem Hash von diesem Logo im Kausgleich. Und wenn die Bank jetzt quasi noch ungeschickter war und das dann geshared hat mit Star, also sprich für alle, dann wäre dieser Zugriff tatsächlich theoretisch möglich, dass das aber nicht der Fall ist, also dass das nicht geht.

35:35Da kommt dann ein weiteres Konzept hinzu und das nennt sich die Public Hashlist, PHL. Die Idee ist letztendlich, dass die Browsermann-Loren sich zusammentun und sagen, lass uns doch einfach mal schauen global, was wissen wir, was sind die populärsten Ressourcen und sobald ich eben weiß, eine Ressource ist sehr, sehr populär, dann wird es eben nicht mehr zum Orakel, also sprich, wenn ich dann weiß, der Benutzer war auf einer Seite, die React verwendet hat.

36:01Gut, weiß dann nicht viel über die Person, das ist dann kein identifizierendes Merkmal mehr. Wenn man nicht weiß, welche Seite React benutzt hat. Genau, dann hast du so eine sogenannte K-Anonymity, also sprich, k, und k ist dann natürlich sehr, sehr groß, k Seiten verwenden diese Ressource, und weil das k eben sehr, sehr groß ist, ist dann am Ende nichts mehr Nützliches über diese, ja, über diesen Leak, in Anführungszeichen, möglich. Genau, und auf dieser Public Hashlist ist dann eben die Idee, dass sich die Vendoren zusammentun und dann eben verschiedene Quellen anschauen, also es gibt ja verschiedene ...

36:40Mehr oder weniger offene CDNs, es gibt die guten und alten Google Ajax und das Microsoft Ajax CDN, wo man die ganzen alten jQuery-Versionen drauf findet, es gibt NPM, HTTP Archive wahrscheinlich, genau, leichter zu bekommen, wo man die Downloadzahlen hat, HTTP Archive. Chrome selbst verwendet eine sogenannte Most Pervasive Resource Liste, die eben letztendlich auch über das HTTP Archive gespeist wird und genau, da sind wir gerade dabei, so ein bisschen zu schauen, Wäre das denn möglich, dass man die meisten Ressourcen, die eben im Web so anzutreffen sind und die sehr, sehr populär sind, dass man die auch diese Public Hashlist, PHL, übernimmt?

37:19Und dann hast du natürlich noch das Problem mit den AI-Modellen. Also AI-Modelle sind natürlich populär, aber längst nicht so populär wie jQuery. Und ja, da ist dann die Idee, dass man sagt, okay, Hugging Face, was ja das bisher zentrale AI-Modell-Hub ist, die haben auch so eine Art Ranking, wo sie eben sagen, was sind die populärsten AI-Modelle. Und da schauen wir uns einfach an, die oberen, was auch immer, 10.000, 100.000, 1.000, muss man jetzt noch genau schauen, was der Schwellwert dann ist.

37:51Und genau diese 10.000, wie auch immer, AI-Modelle, deren Hashes, übernehmen wir dann eben auch manuell sozusagen auf die Public-Hash-List. Das heißt, das ist dann quasi eine zweite, also das ist dann sozusagen wie so ein Türsteher. Das heißt also, auch wenn die Bank alles falsch configuriert hat, also diese Ressource dann angemeldet hat im Cross-Origin-Storage und auch dann noch alle Origins zulässt obendrein. Und diese Ressource dann aber nicht auf dieser Liste der weitverbreitenden, populären und, keine Ahnung, vielleicht auch sinnvollen Ressourcen für dieses Szenario steht, dann wird es halt trotzdem nichts.

38:35Also man würde dann dennoch quasi einen Fehler zurückbekommen und würde gar nicht wissen, dass diese Ressource schon irgendwo im Cache sozusagen oder im Storage. Das ist quasi so ein Sicherheitsmechanismus, der eben dann versichert, dass du A, entweder sehr, sehr populäre Ressourcen oder eben erlaulistet Ressourcen, also AI-Modelle zum Beispiel, wo wir eben sagen, die sind nicht populär genug heute, aber wir wissen, da ist durchaus Bedarf da, dass du eben dann diese Ressourcen bekommst.

39:06Ich habe noch kurz eine Frage zu dieser Liste. Wo genau lebt die? Ist die in den Browser eingebacken? Die würde quasi VG Public Suffix List regelmäßig vom Browser dann runtergeladen werden und der Browser würde intern der Kopie davon aufnehmen. Okay, also ich frage mich gerade so, es werden ja Dinge auch wieder weniger populär. Die fliegen die dann von der Liste runter und wenn ja, kann ich dann Code bauen, der in zehn Jahren nicht mehr funktioniert, weil die Liste nicht mehr die ist, die ich erwarte.

39:41Also die Grundidee ist, dass das Ganze komplett automatisiert und wie gesagt neutral funktioniert, also wenn dann eine Ressource nicht mehr populär ist, also irgendwie verschwindet von den, was auch immer, most popular lists, dass sich dann diese Liste quasi ständig aktuell hält. Cross-Origin-Storage ist von vornherein Progressive Enhancement. Also du machst dadurch nichts kaputt. Du machst das in Zweifelsfall besser, indem du von Cost-Crash profitierst.

40:07Aber du musst immer davon ausgehen, die Ressource ist noch nicht vorhanden. Oder, und da komme ich jetzt gleich noch dazu, oder der Browser lügt. Also jedenfalls das Ganze ist ... Das ist klar, dass das so gedacht ist. Aber ich kämpfe gerade damit, in einer Windows XP Virtual Machine Internet Explorer 6 zum Laufen zu bringen, frag nicht. Du hast Hobbys. Und das Ding ist jetzt natürlich dann erstmal maximal isoliert, weil ist halt Windows XP, da wird ja sofort jeder einmarschieren.

40:34So ist ja irgendwie klar, kriegt also kein Internet, hat keine Updates und da ist ja dann, hab ich ja damit zu kämpfen, dass ich halt eben diese alte Technologie habe und ich würde ja gerne dann auch die alten Webseiten aus der Zeit mit dieser alten Technologie zumindest darstellen können. Natürlich alles irgendwie sicher eingepackt und sowas. Und deswegen meine Frage nach, kann ich Code schreiben, der mir in Zukunft auf die Füße fällt, wenn dann der Zukunftspeter mit einer antiken Chrome-Version in 20 Jahren den gleichen Stunt nochmal probiert?

41:02Kann ich also irgendwelchen JavaScript-Code geschrieben haben, der sich daran aufhängt, dass die Liste in 20 Jahren nicht mehr meinen Erwartungen von heute entspricht? Das könntest du heute schon, indem du alle deine Ressourcen über einen Service Worker beziehst, der erwartet, dass diese Ressource schon im Cache liegt. Machst du natürlich nicht, weil du weißt, das wird nicht der Fall sein. Der Service Worker Cache kann jederzeit erdiktet werden, genauso kann der Cost Cache jederzeit erdiktet werden.

41:25Also jede Zeit, da kommen wir noch dazu. Also sprich, du musst immer davon ausgehen, eine Ressource ist nicht vorhanden im Cost Cache. Genauso wie du heute auch davon ausgehst, in der Cache API, da kann irgendwas passieren, der Benutzer kann den Cache zurücksetzen. was auch immer. Theoretisch wäre es möglich, den Code so zu schreiben, aber das macht keiner. Und genauso wird das mit Cos genauso wenig. Bist du sicher, dass das auch nicht jemand machen würde für irgendwie, keine Ahnung, das ist die Version von React, mit der ich dieses Ding geweipcoded habe?

41:56Es ist meine Absicht, das niemals wieder anzufassen. Und ich packe da halt eben auch nur so das absolute Mindestmaß an Vorsicht rein. Ja, aber da kann ich einspielen. Selbst dann muss diese App initial deine damals festgepinnte React-Version runterladen. Und das musst du ja irgendwie sicherstellen. Und über diese eine Quelle, das ist dann eben dein Single Point of Failure, selbst wenn du davon ausgehst, in der Zukunft, du startest das Ding in 30 Jahren, die Public Hash List existiert nicht mehr, das heißt, der Browser wird versuchen, die Route zu laden, es gibt sie nicht mehr, der Browser sagt dann, okay, meine Public Hash List ist leer, dann wird immer noch dein Fallback funktionieren, wo du dann eben zurückfällst und sagst, okay, das ist eben die Ressource, das ist der Hash davon und wenn dann deine URL nicht mehr funktioniert in 30 Jahren, dann ist das eben so.

42:46Das ist aber genau heute auch schon der Fall, wo du halt URLs hast, die gestorben sind. Okay, aber das ist jetzt wichtiger Kontext, weil ich müsste mich wirklich anstrengen, um das zu schreiben und durch schiere Unachtsamkeit würde ich nicht in die Situation kommen. Das ist gut genug für mich. Genau, und wie gesagt, das wäre heute schon über eine Service Worker Seite möglich, aber du musst natürlich irgendwie initial die Daten in deine Cache reinbekommen.

43:09Das hast du im Service Worker nicht, weil Service Worker ist ja Origin Isolated. Ähm, ja, aber ja, das müsstest du dann halt über Kost, könntest du es theoretisch irgendwie hinbekommen, indem du halt davon ausgehisst, äh, ich verlasse mich halt drauf, dass dieses Sicherheitsnetz von irgendwer hat das schon in Kostcash gepackt, aber das ist völlig unbewillenssicher, also niemand würde seine Seite so programmieren, es sei denn, man macht eben einen Test quasi so, wie wie Corporate ist, ist denn tatsächlich äh, was auch immer, eine Ressource, die ich erwarte, das sind Corporate Links.

43:40Aha, okay, wenn ich in den nächsten paar Jahren so ein Ding mal finde in freier Wildbahn, gibst du mir ein Bier aus. Läuft? Auf jeden Fall, das war es. Okay. Genau, du hattest es eben, wolltest du noch erzählen, dass es eben nicht nur sein kann, dass der Browser sagt so, hey, es gibt diese Ressource nicht im Cross-Origin-Storage derzeit oder sie ist vielleicht da, aber er lehnt dennoch ab, weil sie eben nicht auf der eben erwähnten Liste steht.

44:10Und dann meinst du, gibt es aber eben auch die, noch den Fall, dass der Browser auch theoretisch lügen kann, also beides sehr wohl zutrifft, aber der Browser dennoch sich entscheidet, irgendwie zu sagen, zu behaupten, nee, richtig? Genau. Also ich hatte ja schon erwähnt, wenn du weißt, eine Seite ist mit React gebaut, dann findest du nicht wirklich viel über den Nutzer raus, weil eben k-anonymity, das ist ein super schwieriges Wort. Dann kannst du dir aber natürlich irgendwie was zusammenfassen, wo du dann eben sagst, vielleicht React alleine nicht, aber React mit Vue, mit keine Ahnung was, mit noch diesem AI-Modell.

44:49In der Kombination gibt es nur auf der Seite, so rasterfahndungsmäßig. Richtig. Und da kannst du natürlich irgendwann dazukommen und sagen, okay, jetzt habe ich was, was vielleicht eindeutig genug sein könnte. Aber, und dann kommt eben dieses Prinzip dazu, der Browser lügt einfach hin und wieder mal und sagt, bei einer Datei, bei einer Ressource, wo es jetzt nicht wehtut, also irgendwie, wo du, sagen wir, ein paar hundert Kilobyte im Maximalfall runterladen musst, wo du sie eigentlich schon im Cache hättest.

45:18Da flippt der Browser dann irgendwie randomly ein Byte und sagt, EnBit und sagt, okay, diese Ressource ist nicht in CrossCache, obwohl sie eigentlich fahren muss. Und dadurch wird eben auch dieser Angriff ziemlich unmöglich gemacht, weil du halt nie weißt, ja, hat der Browser jetzt gelogen, eigentlich. Das Konzept nennt sich Grease, kommt, glaube ich, irgendwie so aus der SSL Terminologie. Wenn du diese User Agents, weißt du ja, Advanced User Agents API oder wie auch immer, wenn du die anschaust, das machen wir auch schon dort, wo da eben, ich glaube, drei User-Agent-String hast und die heißen dann irgendwie Not-A-Browser-Agent und dann irgendwie eine Zufallszahl und so weiter.

45:58Also, da wird das auch schon so ein bisschen betrieben und genau, so, das ist eben die Idee, dass der Browser hin und wieder einfach mal unvorhersehbar lügt und sagt, diese Ressource ist nicht in meinem Cause-Cache. Ich weiß, sie tut uns nicht weh. Also, der Browser würde nicht lügen, wenn du sagst, hey, ist Jammer 4 im Cache. Das wäre natürlich blöd. Aber bei so kleinen Ressourcen, wo es halt nicht wehtut, ja, kann der Browser durchaus mal lügen. Mhm.

46:26Ich glaube, damit haben wir erst mal das Funktionsprinzip dieser API beschrieben. Vielleicht kann man noch kurz sagen, wir haben jetzt, gerade noch mal über die imperative Form, also das quasi mit JavaScript zu schreiben gesprochen, bei der deklarativen, also die so sich in CSS und HTML einhängt. Wie ist es da? Werden diese Ressourcen dann auch angelegt automatisch, wenn man quasi dieses Cross-Origin-Storage-Attribut oder die CSS-Funktion oder wie auch immer ihr das dann da löst, aber ich würde jetzt mal tippen CSS-Funktion wahrscheinlich.

47:07Wenn ihr das da macht oder sind die sozusagen nur passiv, konsumieren die nur und können gar nicht den Cross-Origin-Storage auch befüllen. Ich dachte auch, also die würden auch gefüllen. Die Idee ist einfach, das quasi als Progressive-Enterment zu machen. Die Source oder Ahrefs oder was auch immer du mal hast, die ist natürlich nach wie vor da. Und das ist auch die Quelle, wo die Daten dann herkommen. Der Browser würde aber zuerst gucken, habe ich dann die Ressource mit dem Hash schon in meinem Cross-Cache drin?

47:37Wenn ja, dann wird überhaupt kein Network-Progress gemacht. Wenn nein, dann wird der Network-Progress gemacht. Und eben, wenn das Opt-in entsprechend ist, also sprich dein Cross-Origin-Storage, auf, ja, ein Sternchen, eine Liste von Origins oder eine Liste von, äh, Quatsch, oder nicht gesetzt ist im Sinne von Same-Site, dann würde die Ressource, in den Cross-Cash reingelegt werden, wenn, und das ist auch wichtig, wenn der Hash dann stimmt. Also, kannst du dir sagen, ich vertue mich, ich mache jetzt irgendeinen Tippfehler.

48:10In der Hash-Ressource oder es kann natürlich auch einen Angriff sein, wo du eben sagst, okay, das ist jetzt zwar ein legitimer jQuery-Hash, aber letztendlich liefere ich irgendwie kaputtes jQuery. Da würde der Browser das aber sofort abfangen, weil das funktioniert dann eben direkt über SRI, also was so ist, wie heißt das, Sub-Resource-Integrity. Sub-Resource-Integrity, ja. Genau, da würde der Browser dann sofort merken, hey, Moment, die Hashes stimmen nicht und das würde dann sofort auch verleigert werden und der Browser würde dann A, das gibt überhaupt nicht, und B, würde er es auch nicht in den Cross-Cash reinlegen.

48:47Aber die Idee ist tatsächlich, dass wenn diese Cross-Attribute gesetzt sind, Und dass eben direkt sich das dann mit Cross auch integriert. Genau, also ich habe mir da so ein bisschen Gedanken auch zu gemacht. Also ein Gedanke, den ich hatte, ist, ihr habt diese API so gewählt oder auserkoren, weil sie auch nah an der File Storage API ist, so von ihrer Art und Weise. Sondern man muss nicht so viel Neues lernen, man kann viele Dinge wiederverwenden.

49:20Was würde dagegen sprechen, das Ganze oder die Browser, die bestehende Cache-Mechanik in den Browsern, eben so auf diesen Stand zu heben, zu sagen, also zum einen, vielleicht ziehen wir die Caches eben nicht nach Origin, sondern machen vielleicht irgendwie doch Same-Site, also öffnen uns wieder ein bisschen. Und zum anderen eben vielleicht auch diese Origins-Geschichte irgendwie über Header oder so dann, vielleicht regelbar zu machen, weil im Grunde gibt es ja diese Infrastruktur schon und man müsste, man könnte quasi sozusagen eigentlich minimalinvasiv könnte man.

50:08Diese Features unterbringen und dann eben quasi entweder über, auch da eine API oder eben über HTTP-Header oder wie auch immer man das halt so heutzutage tut, sozusagen draufsatteln. Habt ihr darüber gesprochen oder ist das jetzt sowas, was gedanklich noch nicht so richtig so... Da haben wir auf jeden Fall drüber gesprochen. Also verschiedene Probleme. Also A, viele dieser Cache-Mechanismen basieren eben irgendwann auf dem Konzept URL und COS macht das eben nicht.

50:40Das heißt, du kannst jetzt irgendwie eine Ressource laden von tomsketchyserver.com, und solange der Hash stimmt, kannst du dann eben sicher sagen, das ist jetzt genau das reiche, wie wenn ich das über das offizielle CDN runtergeladen habe. Dieses Konzept haben eben die traditionellen Caches nicht. Die sind alle basierend auf regulären URLs. Es gibt natürlich auch das Problem, ja, Back-Compatibility, das Ganze muss natürlich auch so funktionieren, dass es auch mit Browsern, die jetzt sich entscheiden, diese AGI nicht zu implementieren, dass es eben nach wie vor funktioniert, oder halt Browser, die alt sind.

51:16Das Ganze funktioniert eben sehr, sehr elegant über Progressive Enhancement, wo du sagst, okay, als Seite guck ich halt, kann ich Kost verwenden, wenn nicht, dann hab ich alle bisherigen Mechanismen auf. Header, wie gesagt, das hängt natürlich dann mit URLs zusammen, und ja, letztendlich, ist es natürlich auch einfach nur eine neue API, wo man dann eben sagt, man macht eine ganz bewusste Entscheidung als Developer und sagt, okay, das ist eine Ressource, wo ich jetzt auch erwarte, dass ich die Herrschers entsprechend, ja, habe, also sprich, das ist dann auch so ein gewisses Opt-in sozusagen in einen neuen Speichermechanismus.

51:52Wenn du dir intern anguckst, wie jetzt zum Beispiel auch die Extension implementiert ist, die Extension verwendet die reguläre Cache-API über eine Offscreen-Page in der Extension. Und dadurch hast du dann eben den gleichen Cache-Intern-Mechanismus und ich vermute auch, die native Implementierung wird dann auch sich in die native Cache-API, die schon existiert, mit reinhacken sozusagen von der Implementierung, ohne dann halt diese ganze Origin-Geschichte zu haben.

52:19Also sprich, so intern, ab viel neue Code, wahrscheinlich wird es gar nicht so viel brauchen, weil man kann sich eben sehr viel, wie du schon gesagt hast, auf existierende Konzepte stützen und, genau, aber so von der Developer Surface ist das schon eine ganz bewusste Entscheidung, dass das eine neue Ecke ist, aber eben, und da sind wir dann wieder bei den deklarativen Varianten. Für den Entwickler soll das eine super einfache Lernkurve sein. Also sprich, wenn du SRI schon mal gemacht hast, dann noch Cross-Origin-Storage dazunehmen, das ist trivial.

52:51Und diese interaktive API, da könnte man dann natürlich argumentieren, warum brauchen wir die überhaupt? Und da ist die Antwort dann letztendlich tatsächlich AI, weil in AI ist natürlich immer die Geschichte, welches Modell hast du? Und angenommen, du machst jetzt irgendwie so eine Transcription-App, Also sprich, Speech-to-Text. Und deine App funktioniert großartig mit dem Whisper-Tiny-Model. Wenn du jetzt aber kommst und über Kost feststellst, oh, der Benutzer hat aber schon das Whisper, wie auch immer es heißt, Whisper-Medium, Whisper-Giant.

53:23Dann sagst du dir natürlich auch nicht Nein und lädst dann Whisper-Tiny runter, sondern du könntest dann sagen, okay, ich weiß, ich funktioniere relativ gut mit Whisper-Tiny, Whisper-Medium, Whisper-So und So. Und könntest dann einfach kurz mal probieren, welche Varianten sind dann schon verfügbar. Das Gleiche mit Coding-Modellen, also wenn du sowas hast wie einen Harness, wie jetzt Pi zum Beispiel, da kannst du auch verschiedene AI-Modelle dahinter kennen.

53:47Du kannst dann mit Cloud arbeiten, du kannst mit was auch immer arbeiten, Open-A-Rei-LGIs arbeiten. Der Harness gehört der Gleiche. Also sprich, diese ganze Idee, wo du dann eben sagst, ja, letztendlich das Modell, nicht alle sind kompatibel, aber ein Subset davon sind kompatibel. Das könnte dann funktionieren. Deshalb haben wir ja auch diese integrative API, wo du dann einfach mal probieren kannst, was ist denn vorhanden. Fingerprinting ist dann wieder wichtig, also da gibt es auch dann so eine Art Limit, also sprich, du darfst jetzt nicht irgendwie 10.000 verschiedene Hashes durchprobieren, da wird der Browser dann irgendwann mal sagen, Moment, das sieht jetzt aber ziemlich nach einem Fingerprinting-Attempt aus, da sagt der Browser dann irgendwann mal, okay, stopp.

54:31Weil wir mit Hashes arbeiten, ist das aber auch sehr faktisch, weil diese Hashes, Da ist natürlich irgendein Inhalt dahinter. Das heißt, der Browser kann dann auch, tatsächlich im Browser AI rausfinden, okay, die Hashes sehen jetzt zwar irgendwie random aus, aber natürlich weiß ich als Browser, okay, das sind jetzt alles Hashes aus der, sagen wir, bis bei AI-Moder-Familie. Das ergibt Sinn, dass die zusammen abgefragt werden. Also sprich, da kann man auch so gucken, gibt es irgendwie, braucht man nicht bei AI dafür, da kannst du einfach schauen, ja, sind die typischerweise in einem Cluster?

55:05Sie sind irgendwie verwandt und da kann man eben über den Browser auch sagen, da brauchst du jetzt nicht hart kodiert sagen, 10 Prokes und das war's, sondern du kannst halt eben auch sagen, weil das eben ein spezieller API ist und eben nicht integriert in existierende APIs, ja, das sind jetzt auch Patterns, die man dann dynamisch feststellen kann. Mhm. Und wie ist das? Macht man dann einen Request-File-Handle für jeden Hash oder kann man dann in die, also quasi als Parameter auch ein Array oder eine, beliebige Menge Hashes eingeben? Das hatten wir tatsächlich zuerst so.

55:39Wir haben dann aber über die Extension festgestellt, alle, die das implementiert haben, und da haben wir noch gar nicht drüber gesprochen, also bisher basierend auf diese Extension haben das schon implementiert, Transformers.js. LLM, WLama aus der AI-Familie, und dann haben wir Flutter, wir haben M-Scripten, und alle diese Implementierungen haben eigentlich nur die Singularform verbindet. Und typischerweise in Chrome hast du ja diesen Mechanismus der Dev-Trials, der Origin-Trials und so weiter, bis dann die API shipped.

56:15Über diese Extension haben wir quasi schon in Anführungszeichen ein Origin-Trial vor dem Origin-Trial und haben eben festgestellt, alle Implementierungen verwenden nur die Singular-Form und ja, die Singular-Form macht dann eben sehr viel das einfacher, weil, wenn jetzt zehn Hashes anfragst, also erstmal ist die Frage, wie viele sollen da erlaubt sein, Weil da musst du dann irgendwie sagen, okay, maximal 20 oder so, wenn du nicht diesen Thinkerprint-Vektor haben möchtest.

56:43Und was passiert, wenn dann nur Partial-Matches sind? Da musst du irgendwie sagen, okay, äh... Was auf einmal ABC 1, 2, 3 habe ich, ABC 3, 4, 5 habe ich nicht. Das macht dann eben die gesamte API ziemlich unerwartet. Ich habe gedacht, vielleicht, wenn man so bei deinem Whisper-Beispiel eben sagt, im Grunde ist die API-Oberfläche immer gleich, die sind nur unterschiedlich groß und dann kann ich irgendwie, alle drei Hashes übergeben und kriege dann quasi den ersten Match zurück aus der Liste und kann damit arbeiten, so dachte ich.

57:19Aber letztendlich, da hast du dann bessere Primitieren, also Promise Race oder Promise All Settled oder was auch immer der Sinn ergibt für die jeweilige App. Und ja, auf diese Art und Weise lässt sich das dann eben sehr viel einfacher gestalten. Und wie gesagt, das Ganze wurde auch von vornherein modelliert, basierend auf der OPFS API und die hat eben auch nur eine Single-Auffrage. Ja, genau. Und da gab es dann eben vor, das war im Juni, glaube ich, Spec-Änderung oder Explainer-Änderung, wo wir dann gesagt haben, okay, wir schmeißen die Pluralform aus und übernehmen jetzt nur noch die Singularform.

57:54Vorteil, wie gesagt, über die Extension dann ist, wir machen damit niemand kaputt. Über die Extension habe ich dann quasi Code drin, der sagt, okay, du verwendest das die Deplicated Pluralform. Ähm, ich draht dir das intern um und mach dann eben verschiedene Singular-Calls draus, ähm, und dann, ja, kannst du eben sagen, okay, alle, die das bisher verwendet haben, ähm, sollen ihren Code entsprechend anpassen, ähm, hatte vor kurzem auch ein PR offen bei Transformers, wo ich das eben, äh, direkt quasi implementiert hab noch, und, äh, gefixt habe, und, genau, auf diese Art und Weise haben wir dann eben so ein Origin-Trial vor dem Origin-Trial, und, äh, in Q3 soll es dann losgehen, dass es, äh, den ersten echten testbaren Code irgendwann mal in Cron selber dann geben wird.

58:36Also natürlich ganz klassisch, so Cron Canary hinter einer Flag und so weiter. Und irgendwann, wenn es dann ein bisschen stabiler wird, da wird es dann den klassischen Original Trial und so weiter geben und ja, F-Trial vorher noch. Genau. Aber bisher über die Extension kannst du eben alles schon testen, wie es funktionieren wird, inklusive der deklarativen Varianten. Ist dann eigentlich ziemlich cool. Macht man Spaß, daran zu arbeiten. Mhm. Dann habe ich noch eine Frage und zwar, du hast ja, wenn man Origins-Sternchen setzt, dann ist man ja so, dann hat man ja die Spendierhosen an und sagt so, die ganze Welt kann diese Library oder genau die ganze Welt, wenn sie denn mit dem Browser mal auf unserer Seite war, kann dann auf einer anderen Seite diese Library benutzen.

59:28Ähm, wer würde das machen, also, äh, würden das, würden da normale EntwicklerInnen dran denken, also, dass sie sagen, immer wenn, äh, wenn ich React einbinde, dann äh, setze ich das, eben packe ich das da mit rein, also, wer sind dann die, die gebenden, die natürlich ja auch von den Browsern besucht werden müssen, also, damit das im Cross-Origin Storage landet, also, wer das dann, Google, weil die so viel Präsenzen haben und so die Großen, wo fast alle Leute eben immer vorbeisurfen. Weißt du da was?

1:00:06Die Idee wäre, du machst das, wenn du eine realistische Erwartung hast, dass deine Ressource von jemand anderem schon verwendet werden würde, also du auch profitieren könntest. Also das ist so ein bisschen wie wenn du in die Bar gehst, jeder zahlt mal eine Runde, du weißt, okay, diesmal trifft es mich, ich mache die Ressource in den Kostkash rein, aber nächstes Mal muss ich dann die Runde nicht bezahlen, weil jemand anders bezahlt. In vielen Fällen wird dir aber diese Entscheidung direkt abgenommen, weil, wie ich schon erinnert hatte ganz am Anfang, wir arbeiten auch direkt mit Nuxt und Next und so weiter zusammen, dass das eben quasi dann direkt auf deine Meta-Framework schon passiert und dann Nuxt schaut, okay, wir machen irgendwie View und View keine Ahnung was in unser Bundle rein.

1:00:52Wir kümmern uns um das gesamte Wandling und das kannst du heute auch schon testen. Es gibt ein Beat Plug-in Cross-Origin Storage, das hat der Daniel Rowe entwickelt, wo du eben heute schon über deine Nuxt-App testen kannst, wie wird das funktionieren. Und wie gesagt, alles pro bestehende Anzement, da geht nichts kaputt, wenn jetzt der Benutzer COS nicht aktiviert hat, weil die Extension nicht aktiviert ist, oder einfach in Zukunft, wenn das im Browser nativ landet, vielleicht der Browser das noch nicht unterstützt, geht nichts kaputt, du machst das im Zweifelsfall einfach besser, aber du machst das nie schlechter.

1:01:27Und die Ressourcen, die dann eben benötigt werden, die werden runtergeladen so oder so. Also sprich, in vielen Fällen wird dir das Framework, das du verwendest, die Entscheidung schon abnehmen. Das ist dann halt einfach Teil davon, wenn du eine neue Next-App erstellst oder was auch immer. Genau, und wenn du das alles von Hand kloppelst, bin ich auch großer Fan von, Mache ich auch alles am liebsten selber. Dann ist das halt jedes Mal so ein Judgment-Call, wo du sagst, okay, ist das realistisch, dass jemand diese Ressource verwendet? Dann gucke ich im Costcash.

1:01:58Du würdest natürlich dem Costcash nicht zwämmen mit was auch immer deinem eigenen Logo oder, es gibt natürlich so proprietäre Ressourcen, also Fonts ist immer ein klassisches Beispiel, wo du sagst, ich bin Publisher, wir haben unsere Corporate-Font und die wird verwendet auf unseren drei Websites, die wir haben und vielleicht noch der Marketing-Site. Da profitierst du dann natürlich von Kurs, aber da wirst du dann auch sagen, okay, realistisch gesehen weiß ich eben genau, auf welchen Origins das auftritt und ich lese die direkt entsprechend auch.

1:02:28Das Ganze ist kein Geheim, das ist so ein Hash. Wer die Ressource kennt, der kann den Hash berechnen. Also das ist nicht irgendwie so ein Sicherheitsmechanismus. Die Visibility von einer Ressource kann auch upgegradet werden, also wenn ich jetzt weiß irgendwie Sheps Newsmag verwendet eben die Shep Tooltripe Font, dann kann ich eben diese Ressource auch runterladen und auf Tom's Sketchy Server legen ob das jetzt legal ist oder nicht dahingestellt und dann könnte ich eben diese Ressource, die ich von dir bekommen habe, auch in meinen CrossCache legen und dann sagen, das geht jetzt auf Tom's Sketchy Server .com.

1:03:04Also das Ganze ist kein Sicherheitsmechanismus, ähm, intern wird dann eben einfach nur, ähm, der Browser sagen, okay, ähm, der Hash abc1.i, was jetzt Scherz Code Webfront wäre, ähm, Wird jetzt ursprünglich verwendet von Chefs Origin und von Chefs Marketing Site und eben auch von Tom's Sketchy Server. Wenn ich diese Ressource jetzt aber quasi deren Visibility erweitere, also sprich, die halt neu jetzt auf Tom's Sketchy Server auch verfügbar machen möchte, dann muss ich die Ressource trotzdem nochmal selber schreiben.

1:03:38Also ich muss die Ressource herunterladen und dann in den CrossCache nochmal aktiv schreiben. Der Grund ist, dass eben dann auch auf dieser Fingerprinting-Attack-Vector oder Cross-Site-Leak-Vector wegfällt, weil dann kann ich eben nicht mehr wissen, war der Benutzer jetzt auf einer von Sharp-Seiten oder war der Benutzer auf meiner eigenen Seite und dadurch fällt das eben dann weg. Und diese Zugangsliste, also sozusagen diese gemeinsam von Vendoren gepflegte Liste, die kommt aber nur zum Einsatz bei quasi Wildcard-Origin-Angaben, oder ist das so?

1:04:14Weil sonst könnte ich ja teilweise eben genauso meine kleine Mini-Ressource, die aber nur ich, aber auf mehreren Origins benötige, könnte ich ja dann gar nicht zum Fliegen bringen. Wenn der sozusagen immer einschreiten würde, weil dann diese Ressource ja gar nicht so populär ist, dass sie es auf diese Liste schafft. Aber das Ganze kann natürlich dann noch passieren. Also du kannst jetzt anfangen als unpopuläres Framework und wenn du dann irgendwann mal einfach organisch über NPM oder über CDNs oder was auch immer es auf die populäre Liste geschafft hast, dann wird das quasi einfach direkt abgegradet.

1:04:56Dann kann uns irgendjemand anderes sagen, ich lege die Ressource in den Costcash mit Sternchen, weil inzwischen ist sie populär geworden. Dann würdest du selbst aber auch profitieren davon, weil du hast halt ursprünglich die Ressource mit deiner eigenen Liste von Ressourcen. Also selbst wenn meine Origins sozusagen eingeschränkter sind oder waren beim Reinschreiben, genau, ist es dann beim Konsumieren egal. Also dann bekomme ich die, wenn sie eben auch...

1:05:26Und wir haben auch über die Public Hashlist so eine manuelle Funktion vorgesehen, also dass man eben auch sagt, es gibt jetzt eine manuelle Variante, wo man eben sagt, ich weiß, ich werde nie populär sein, aber aus irgendeinem Grund werde ich halt, also nie populär im Sinne von, ich werde es nie auf eine dieser Listen schaffen, aber ich bin trotzdem irgendwie populär, ich habe eine Motivation, warum. Dann kannst du jetzt eben auch sagen, okay, also sagen dir was auch immer, es gibt Covid-27, ja, also, wo alle eine Corona-Erkunde laden müssen und das wäre dann zum Beispiel so ein konstituierter Fall, wo man sagt, okay, da wollen wir jetzt nicht warten, bis irgendwie das organisch auf irgendwelche Listen es geschafft hat.

1:06:06Es gibt dann so eine neutrale Governance innerhalb der Watt Working Group, wo man halt sagt, okay, das ergibt Sinn, lass uns diese Liste quasi manuell auf die Public Hash List üben. Ich sollte vielleicht noch erwähnen, die Public Hashlist, das Ganze ist bisher noch eine Idee, das wurde noch nicht mit den anderen Bendoen quasi groß geteilt, es wurde so informell, im Juni geteilt auf der, es gab bei Egalia das Web Engines Hackfest, da wurde diese Idee so ein bisschen geflootet, aber es gab jetzt noch keinen formalen, Vorschlag, also was wir so bisher diskutiert haben, das ist hauptsächlich ein bisschen intern, was wir uns überlegt hatten, was rumziehen könnte und, wo so ein bisschen von anderen Mentoren, vorsichtige Zustimmung gehört hatten.

1:06:56Aber es ist noch nicht offiziell irgendwas entschieden hier. Vermutlich dann im Oktober, glaube ich, genau im Oktober ist der TPEC in Dublin. Da wird es dann vermutlich einen etwas größeren Themenkomplex geben, wo das ganze Thema dann Cross-Origin-Storage diskutiert wird. Okay, das heißt also Augen aufhalten, so um Oktober rum, ob da, was da passiert, da kann es dann auch sein, dass wenn man dann die Position der anderen Vendoren endlich mal hat, dass das dann noch, das Ganze umdesignt wird.

1:07:35Genau, also eine Mozilla-Position gibt es schon als Stub, also direkt nach dem Web-Engine-Hackfest hat das Kagami angelegt von Mozilla, können wir vielleicht in die Show-Notes auch übernehmen. Ich glaube, die beste Liste ist die Awesome Gross Origin Storage, weil da werde ich halt alles dann direkt aktualisieren, sobald sich da was tut. Wir werden jetzt auf bald eine WebKit-Position anfragen und dann kann man sich einfach auf diese GitHub-Misches subscriben und wenn dann irgendwas passiert, bekommt man Bescheid, was da los ist.

1:08:05Und dann natürlich der ganze klassische wir wollen eine neue Browser-API-Ship-Prozess, also sprich das Tag-Review und ja, dann den ganzen Origin-Trials und so weiter, was da kommen wird. Also, da ist noch ein bisschen, ja, Zukunftsmusik, die dann zu komponieren ist, aber, genau, auch heute, wie gesagt, schon kann man das alles testen, über die Browser-Extension und die Idee ist halt dann auch, diese Browser-Extension, sollte es irgendwelche API-Changes geben, wird dann halt angepasst, sodass jeder Code, der heute geschrieben ist, dann am Ende auch mit der finalen API funktionieren wird.

1:08:40Und die Extension, die ist so geschrieben, dass sie detected, gibt es Cross-Ordance, gibt es Cross-Origin-Storage und Browser nativ? Wenn ja, dann mache ich einfach gar nichts. Und wenn nein, dann arbeite ich eben und injecte meinen Polyfill. Ja. Alles klar. Peter, hast du noch Gedanken? Ich habe Gedanken, aber ich glaube, keine, die zu diesem Thema so richtig passen. Ich fühle mich auf jeden Fall jetzt ziemlich gut informiert. Und ich werde testen. Ja, ich habe auf jeden Fall alles hier, alle möglichen Themen und Tabs, über die wir gesprochen haben, die habe ich hier alle offen. Und die waren definitiv in die Shownotes.

1:09:27Genau, also ... Lieber der Aufruf an die Hörerinnen und Hörer. Wenn das ein Thema ist, das ihr euch interessiert, dann bringt euch gerne jetzt schon ein. Also früher ist ja immer besser als später. Genau, und was euch an Gedanken kommt und probiert es aus. Und dann schauen wir mal, wie es weitergeht bei dem Ding. Genau, also auf jeden Fall testen, ausprobieren. Das Ganze ist nicht auf AI, nur spezifiziert. Also wenn ihr eine Flutter-App programmiert, dann geht das von selber.

1:10:04Flutter, das SDK, wird dann euch eben automatisch einopten in das ganze Thema. Wenn ihr über WebAssembly mit ihrem Script um was bastelt, da ist das noch ein Experiment der Flag. Also da muss man eine Art in den Docs schauen, Cross-Origin-Storage aktivieren und so weiter als Compile-Flag. Aber auch dann macht der interne, die interne Toolchain alles für euch. Das ganze JavaScript, BlueCode und Wumpf. Also, wenn jetzt eine populäre oder vielleicht auch eine nicht populäre WebAssembly Lib bastelt, gerne ausprobieren und dann auch die ganzen deklarativen Varianten mal testen.

1:10:41Ist, glaube ich, ein ziemlich großer Hebel auch da insgesamt, wenn man jetzt so globalen Internet-Traffic sich anguckt, ja, wie viele unnötige Ressourcen eigentlich verschoben werden, die wir schon alle irgendwo haben im Rahmen von Privacy. Kann man, glaube ich, schon dann irgendwann, hoffentlich, wenn die API ausrollt, so ein bisschen vielleicht einen kleinen Einbruch im globalen Internet-Traffic sehen. Hugging-Face, die freuen sich da natürlich auch, wenn die Leute nicht jedes Mal Gemma 4 runterladen von ihrem Hub, sondern halt das ganze über Kost geliefert wird.

1:11:19Ja, das macht Sinn. Ich meine, es ist ja auch ein Hemmnis, die großen Downloads für die Adoptionsrate bestimmter Dinge, die das dann möchte, vermeidet man das vielleicht eher, sowas einzubinden. Ja, cool. Danke, dass du dir die Zeit genommen hast und zu Gast warst bei uns. Das ist immer sehr interessant. Ja, sehr gerne. Vielen Dank für die Fragen. Wie gesagt, wenn jemand Feedback hat, Gerne über die bekannten Kanäle, ist ja wahrscheinlich dann alles Teil der Show Notes.

1:11:54Macht Issues auf, probiert das aus, testet mal die Extensions. Und findet Security Holes, ich glaube, das ist ja glaube ich so das größte Ding. Also da werden natürlich einige andere auch gucken, aber ich glaube, das ist ja so, dass ja der Grundforms eben die anderen Sachen nicht mehr gab vorher und das soll ja hier dann nicht mehr passieren. Ja, super. Dann vielen Dank. Danke auch fürs Zuhören bis hierhin. Wenn ihr die Folge gut fandet, dann wisst ihr, wie ihr das kunden könnt.

1:12:29Genau, unsere Kontaktkanäle sind alle auf unserer Webseite. Natürlich werden wir auch Toms Kontaktkanäle verlinken, wie Tom schon selber gesagt hat. Dann hören wir uns nächste Woche wieder. Ich weiß das Thema gerade nicht, aber es wird bestimmt super. Genau. Wann ist es das jemals nicht gewesen? Wann ist es das jemals nicht gewesen? Moment, ich kann es aber auch gerne nochmal hier. Warte, hier, da. Was ist nicht so dran? Ah, ja, das wird so ein bisschen, vielleicht wird das so ein bisschen juicy.

1:13:03Es geht um die Akquisition von Void Zero durch, Cloudflare. Genau, also eher ein, kein so technisches Thema, sondern eher ein, wie ist das so und wie wird es in Zukunft sein, Thema. Ja komm, aber wenigstens geht es da um Sachen, die tatsächlich passiert sind und wirklich existieren und nicht um APIs, die vielleicht eines Tages mal angefangen werden können, zu implementieren. Ah, okay, also was Handfestes. So, Dinge, die wirklich existieren und die irgendwen interessieren.

1:13:35Naja, aber wir heißen ja auch Working Draft und das ist ja, genau, da ist das Programm. Und ich finde das immer gut. Mir macht das Spaß. Dankeschön, Tom und ja, bis bald Bis bald, tschüssi, ciao.