WEBVTT

00:00:00.017 --> 00:00:05.117
Und zwar geht es um die Cross-Origin-Storage-API. Getrieben ist das Ganze natürlich

00:00:05.117 --> 00:00:10.917
von AI, zum Beispiel der Observierung, dass wenn man mit Transformers.js, mit,

00:00:11.557 --> 00:00:16.157
Web-LLM oder sowas eine AI-Applikation programmiert, dann musst du jedes Mal

00:00:16.157 --> 00:00:17.397
das AI-Modell runterladen.

00:00:17.417 --> 00:00:22.067
Und worum wir uns eben kümmern wollen, ist zu sagen, es gibt im Web,

00:00:22.067 --> 00:00:25.567
wenn man die gleichen Ressourcen verwendet, durchaus sehr viel verschwenderische

00:00:25.567 --> 00:00:29.796
Downloads, verschwenderische Speicherungen von Daten, die man eigentlich schon lokal hat.

00:00:30.667 --> 00:00:34.117
Und wenn man sich darüber ein bisschen Gedanken macht, ist man sehr schnell

00:00:34.117 --> 00:00:39.227
beim Thema Hash-basierte Speicherung. Also sprich, dass du halt sagst,

00:00:39.227 --> 00:00:43.217
okay, sobald der Hash eine Ressource der gleiche ist, dann ist es eigentlich

00:00:43.217 --> 00:00:44.668
egal, wo diese Ressource herkommt.

00:01:10.534 --> 00:01:17.282
Revision 723. Wir wären heute zu dritt. Da hätten wir aus dem Team einmal den

00:01:17.282 --> 00:01:19.573
Peter. Hallo Peter. Moin, moin.

00:01:20.281 --> 00:01:23.512
Ich bin der Shep und wir haben wieder einen Gast. Und zwar ist das der Tom,

00:01:23.512 --> 00:01:26.788
also der Thomas Steiner von Google. Hallo Tom. Hallo.

00:01:27.682 --> 00:01:31.162
Thomas, du warst jetzt echt schon ein paar Mal bei uns zu Gast.

00:01:31.162 --> 00:01:33.562
Ich glaube, ich weiß nicht, ob wir dich noch vorstellen müssen.

00:01:33.562 --> 00:01:38.262
Und ich glaube, Leute, die so Web-Plattform-Dinge verfolgen sollten,

00:01:38.862 --> 00:01:42.182
deinen Namen auch schon so ein paar Mal hier und da gesehen haben und auch auf

00:01:42.182 --> 00:01:43.721
Google I.O. Talks und so weiter.

00:01:44.807 --> 00:01:46.130
Du bist der Fall bei Google.

00:01:47.680 --> 00:01:55.296
Und zuletzt warst du bei uns zu Gast zu dem ganzen Komplex an AI-APIs, Local AI-APIs.

00:01:56.713 --> 00:02:03.452
Genau, unter anderem auch eben die Prompt-API, die so ein bisschen so ein Aufreger war neulich.

00:02:04.362 --> 00:02:09.384
Also wer da nochmal hören will, was dahinter steckt, dem sei die Folge auf jeden Fall empfohlen.

00:02:09.959 --> 00:02:14.842
Genau, und heute wollen wir sprechen über was Neues, was ihr im Köcher habt.

00:02:15.302 --> 00:02:21.453
Also ihr, du und noch ein paar andere Leute, und zwar die Cross-Origin-Storage-API.

00:02:23.259 --> 00:02:28.273
Ja, ganz genau. Ja, also, wenn ihr mich nicht kennt, DeathRail bei Google und

00:02:28.273 --> 00:02:33.363
ja, schon ziemlich lange bei der Firma und bei der letzten Aufnahme hatten wir

00:02:33.363 --> 00:02:34.563
über die Prompt API gesprochen.

00:02:34.563 --> 00:02:38.203
Das war, glaube ich, so ungefähr ein Jahr her, weil ich hatte die Folge gehört,

00:02:38.203 --> 00:02:42.483
die kurz vorher dran war und lustigerweise war dann der Kommentar so, ja,

00:02:43.163 --> 00:02:48.993
diese IO, also 2025, die war so relativ langweilig und das war natürlich so,

00:02:48.993 --> 00:02:51.332
oh, okay, lass uns drüber sprechen.

00:02:51.988 --> 00:02:56.053
Okay. Und ja, dieses Jahr war die I.O. zumindest für mich persönlich sehr,

00:02:56.053 --> 00:03:00.903
sehr aufregend, weil Propped API und da gab es dann diesen großen Artikel von,

00:03:01.483 --> 00:03:05.403
That Privacy Guy, ich weiß gar nicht, wie der im echten Leben heißt, dieser Guy.

00:03:06.023 --> 00:03:09.953
Und ja, also der Auffang war natürlich so, Google-led, uneingeladen,

00:03:09.953 --> 00:03:16.763
ein 4GB-AI-Model auf meinem Computer und dann gab es natürlich die Geschichte rund um Firefox,

00:03:17.583 --> 00:03:21.123
die das ganze Thema dann so ergibt, das SIM, dass man Terms and Conditions für

00:03:21.123 --> 00:03:26.233
eine Web-Aki hat, diskutiert haben und Model into Op, auch sehr,

00:03:26.233 --> 00:03:29.263
sehr spannendes Thema, was wir intern natürlich uns auch fragen,

00:03:29.263 --> 00:03:30.642
wie kann das denn funktionieren?

00:03:31.463 --> 00:03:35.513
Wenn ich den Konkurrenz-Podcast von Syntax FM empfehlen darf,

00:03:35.513 --> 00:03:38.270
Da war Jake vor kurzem und hat das Thema nochmal kurz erklärt.

00:03:38.641 --> 00:03:41.491
Ja, stimmt. Aus seiner Sicht ist vielleicht auch ganz spannend.

00:03:41.811 --> 00:03:45.273
Ist englisch natürlich, also wer jetzt deutsche Podcasts wird,

00:03:45.273 --> 00:03:47.360
das ist nicht für euch, aber genau.

00:03:47.546 --> 00:03:52.803
Ist ein spannendes Thema gewesen, die Prompt API ist inzwischen gelauncht in

00:03:52.803 --> 00:03:57.716
Chrome 148, war ja schon in Extensions möglich ab 138.

00:03:58.587 --> 00:04:03.208
Genau, aber jetzt bei dieser Folge geht es oder soll es um etwas Neues,

00:04:03.208 --> 00:04:07.368
anderes geben, was nicht zwingend nur AI ist, zur Abwechslung mal.

00:04:07.388 --> 00:04:11.369
Und zwar geht es um die Cross-Origin-Storage-API.

00:04:12.001 --> 00:04:18.488
Getrieben ist das Ganze natürlich durchaus von AI, zum Beispiel der Observierung,

00:04:18.488 --> 00:04:20.568
dass wenn man mit Transformers.js, mit,

00:04:21.208 --> 00:04:25.808
WebLLM oder sowas eine AI-Applikation programmiert, dann musst du jedes Mal

00:04:25.808 --> 00:04:27.068
das AI-Modell runterladen,

00:04:27.808 --> 00:04:32.499
selbst wenn ein anderer Origin schon exakt das gleiche Modell runterladen hat.

00:04:33.097 --> 00:04:37.248
Aber ich habe gesagt, nicht nur AI, weil dieses Problem hatten wir schon,

00:04:37.248 --> 00:04:40.928
seit wir Websites mit jQuery gebaut haben. Und es gab eigentlich schon immer

00:04:40.928 --> 00:04:44.219
so diese Idee, lass uns doch einfach jQuery in den Browser reinbauen.

00:04:44.794 --> 00:04:47.388
Das war schon immer keine gute Idee, das direkt in den Browser zu bauen.

00:04:48.259 --> 00:04:52.532
Es gab ja diese Idee der Standards-Library irgendwann in Chrome.

00:04:53.449 --> 00:04:58.128
Das war dann so ein Folgevorschlag.

00:04:58.728 --> 00:05:02.348
Es war jetzt auch, glaube ich, nicht zwingend nur bezogen auf,

00:05:03.136 --> 00:05:06.927
dass man Speicherplatz und Downloadplatz sich sparen möchte,

00:05:07.356 --> 00:05:12.168
sondern auch um den Standardisierungsprozess etwas schneller zu betreiben,

00:05:12.608 --> 00:05:15.779
betreiben zu können, indem man etwas sagt, indem man,

00:05:16.401 --> 00:05:20.618
so eine Sache wie Virtual Scroller nicht als Browser-API implementiert,

00:05:20.618 --> 00:05:24.858
sondern quasi so intern so eine Art Polyfill einbaut.

00:05:25.451 --> 00:05:30.018
Das würde eben den Prozess etwas beschleunigen. Es gab dann eine Geschichte

00:05:30.018 --> 00:05:34.309
rund um die Toasts und so weiter, also diese mini-aufpoppenden Notifications,

00:05:35.203 --> 00:05:38.968
wo dann eben sich herausgestellt hat, das ist vielleicht, wenn man das einfach

00:05:38.968 --> 00:05:43.916
mal nur so kurz zusammenklappt, keine gute Idee, was jetzt Accessibility auch angeht und so weiter.

00:05:45.108 --> 00:05:46.888
Genau, also das ist, würde ich sagen.

00:05:48.397 --> 00:05:54.132
Entfernt vielleicht in die gleiche Richtung einzuordnen, aber es ist schon ein anderes Thema.

00:05:54.956 --> 00:05:59.696
Genau. Worum wir uns eben kümmern wollen, ist zu sagen, es gibt im Web,

00:05:59.696 --> 00:06:03.976
wenn man die gleichen Ressourcen verwendet, durchaus sehr viel verschwenderische

00:06:03.976 --> 00:06:08.195
Downloads, verschwenderische Speicherung von Daten, die man eigentlich schon lokal hat.

00:06:09.072 --> 00:06:12.535
Und wenn man sich darüber ein bisschen Gedanken macht, ist man sehr schnell

00:06:12.535 --> 00:06:17.685
beim Thema Hash-basierte Speicherung, also sprich, dass du halt sagst,

00:06:17.685 --> 00:06:21.705
okay, sobald der Hash eine Ressource der gleiche ist, ist es eigentlich egal,

00:06:21.705 --> 00:06:22.835
wo diese Ressource herkommt.

00:06:23.815 --> 00:06:28.825
Vielleicht einen Schritt zurück. Wir waren ja schon mal da, als wir alle JQuery

00:06:28.825 --> 00:06:33.052
verwendet hatten und dass diese ganzen CDNs gab.

00:06:33.720 --> 00:06:38.675
Das Google Ajax CDN oder Microsoft hat was Ähnliches, wo man eben sagt,

00:06:38.675 --> 00:06:43.425
okay, wenn wir uns einfach alle auf die gleiche URL einigen und in der URL ist

00:06:43.425 --> 00:06:45.475
die Version drin, also irgendwie Google Ajax,

00:06:46.115 --> 00:06:47.465
libraries.com, wie auch immer

00:06:47.465 --> 00:06:54.548
die URL hieß, slash jqud slash v3 slash 1 slash 4 oder was auch immer.

00:06:55.692 --> 00:07:00.445
Dann sind wir eigentlich gut, weil, ja, gleiche URL, die Version ist in der URL drin,

00:07:01.555 --> 00:07:03.935
manche URLs haben ja auch so eine Art Hash, wo man dann sagt,

00:07:03.935 --> 00:07:08.825
okay, man prübelt einfach den Hash direkt in die URL rein und solange wir uns

00:07:08.825 --> 00:07:11.765
dann alle einigen auf die gleiche URL, sollten wir dann eigentlich gut sein

00:07:11.765 --> 00:07:15.055
und das war auch ein Stück weit so, aber,

00:07:15.815 --> 00:07:20.008
sehr schnell fing dann eben an, die Leute sich Gedanken zu machen und zu sagen, okay,

00:07:20.513 --> 00:07:23.695
wir haben doch eigentlich hier Bundler-Abstahl, wir haben doch Webpack und wie

00:07:23.695 --> 00:07:26.795
sie alle heißen und die haben natürlich dann sehr schnell gemerkt,

00:07:26.795 --> 00:07:30.491
so von der ganzen jQuery verwendest du eigentlich nur, was weiß ich mal, 10%.

00:07:31.002 --> 00:07:35.755
Alles andere ist Dead Code und der Bundler ist dann sehr schnell dran und macht

00:07:35.755 --> 00:07:39.825
eben DCE, Dead Code Elimination und haut eben diese ganzen anderen 90%,

00:07:39.825 --> 00:07:42.990
die nicht gebraucht werden, aus deiner lokalen jQuery aus.

00:07:43.587 --> 00:07:47.585
Das ruiniert dir dann natürlich den Cache-Effekt, weil, ja, dann ist natürlich

00:07:47.585 --> 00:07:51.255
deine jQuery-Kopie lokal, die du brauchst, nicht mehr kompatibel mit der,

00:07:51.255 --> 00:07:54.512
die dein Nachbar-Origin braucht. Und, ähm.

00:07:55.401 --> 00:07:58.420
Das Ganze wurde dann noch schlimmer, in Anführungszeichen, als die Leute angefangen

00:07:58.420 --> 00:08:03.740
haben, nicht nur eine Library über den Wandel zu jagen, sondern eben zu sagen,

00:08:03.740 --> 00:08:09.296
okay, lass uns doch allen unseren JavaScript Bedarf in einem großen Paket zusammenwandeln.

00:08:09.894 --> 00:08:16.222
Und dann hast du irgendwie main.js2578, keine Ahnung, min.js.

00:08:16.814 --> 00:08:20.450
Und ja, da war dann eben alles drin, komplett zusammengebundelt,

00:08:20.450 --> 00:08:24.616
irgendwie lowdash und jQuery und was auch immer und natürlich dein eigener Benutzercode.

00:08:25.301 --> 00:08:30.370
Und ja, dann war natürlich das Thema Caching über gemeinsame URLs sehr schnell

00:08:30.370 --> 00:08:35.210
kaputt und selbst als man noch vor diesem Status war, man musste natürlich immer

00:08:35.210 --> 00:08:37.143
sich auf die gleichen URLs einigen.

00:08:37.922 --> 00:08:42.458
CDNs gibt es nicht besandter mehr, aber es gibt doch einige und die Wahrscheinlichkeit,

00:08:42.458 --> 00:08:48.158
dass man eben einen Origin hat, der genau die gleiche URL für die jQuery-Ressource

00:08:48.158 --> 00:08:51.518
verwendet, die man selbst verwendet, war eben relativ klein.

00:08:51.518 --> 00:08:55.618
Und es wurde dann noch schlimmer, in Anführungszeichen, indem es besser wurde,

00:08:55.618 --> 00:08:59.528
nämlich die Browser fingen an, die Caches zu isolieren.

00:08:59.528 --> 00:09:04.136
Also sprich, wenn ich jetzt XAMPP.com bin und Peter hat peter.de,

00:09:04.653 --> 00:09:08.458
und wir beide verwenden theoretisch die gleiche jQuery-Version und einigen uns

00:09:08.458 --> 00:09:09.697
sogar auf das gleiche CDN,

00:09:10.179 --> 00:09:13.498
dann haben Browser angefangen zu sagen, okay, das ist zwar die gleiche Ressource,

00:09:13.498 --> 00:09:18.078
aber sie wird von einer anderen Grundorigin ausgeladen, deshalb separieren wir

00:09:18.078 --> 00:09:19.867
die Caches. Warum wurde das getan?

00:09:20.413 --> 00:09:24.428
Weil im Internet leider nichts Schönes haben kann. Und im Internet wird immer,

00:09:24.788 --> 00:09:28.618
wenn es irgendwie eine Möglichkeit gibt, Missbrauch zu betreiben,

00:09:28.618 --> 00:09:32.191
Missbrauch betrieben und genauso war es eben auch doch bei diesem Thema.

00:09:32.650 --> 00:09:37.928
Die Leute fingen an, ganz einmalige Dateien zu erstellen, für jetzt,

00:09:38.328 --> 00:09:42.128
Shep war auf meiner Seite, Peter war auf meiner Seite, beide haben eine Ressource

00:09:42.128 --> 00:09:45.595
angefordert und heimlich hat mein Server dann eben für jeden von euch,

00:09:46.106 --> 00:09:50.088
eine individuell gemintete Version einer Datei gemacht, die zwar die gleiche

00:09:50.088 --> 00:09:52.410
URL hatte, aber intern einen anderen Wert.

00:09:52.904 --> 00:09:56.414
Und wenn ihr uns dann wieder besucht habt auf unserem bösen Origin,

00:09:56.832 --> 00:09:59.708
dann konnte ich eben einfach sagen, was ist denn hier in eurem Cache drin für,

00:10:00.208 --> 00:10:04.288
diese Datei und ja, haben dann eben gesehen, ah, okay, das ist die ID 1,

00:10:04.288 --> 00:10:07.624
2, 3, dann weiß ich, das war Hans und das war Peter und das war Chef.

00:10:08.309 --> 00:10:12.618
Und genau, das war dann eben nicht mehr möglich, als die Browser angefangen

00:10:12.618 --> 00:10:14.218
haben, die Caches zu separieren,

00:10:14.950 --> 00:10:19.372
und genau all diese ganzen Probleme versucht jetzt Cross-Origin-Storage,

00:10:20.703 --> 00:10:22.408
anzugehen, zu lösen, besser zu machen. Vielen Dank.

00:10:24.161 --> 00:10:28.484
Ja, also ich weiß diese, dass damals auch bei der Diskussion,

00:10:28.804 --> 00:10:33.043
ob man CDNs nutzen soll, also so zu jQuery-Zeiten,

00:10:34.084 --> 00:10:37.344
da gab es eben hier Steve Souders war ja so der Performance-Pubst,

00:10:37.344 --> 00:10:40.022
der hat das halt stark befürwortet.

00:10:41.007 --> 00:10:44.904
Aber schon da war es so, dass einfach durch die hohe Release-Zahl.

00:10:47.164 --> 00:10:52.704
Von jQuery und den anderen Libraries es gar nicht so häufig vorkam,

00:10:52.704 --> 00:10:55.824
dass man exakt dieselbe Version genutzt hat.

00:10:56.144 --> 00:11:00.124
Und also genau, wenn man das dann mal in Zahlen vor sich gesehen hat,

00:11:00.124 --> 00:11:05.924
dann hat man irgendwie gemerkt, oh, also für so zumindest Software,

00:11:06.264 --> 00:11:10.864
die schnelle Release Cycles hat, da hat man irgendwie gar nicht so viel von.

00:11:11.778 --> 00:11:14.744
Und ein Thema hatten wir noch gar nicht erwähnt, bösartige Übernahme.

00:11:14.744 --> 00:11:20.080
Es gab, wie hießen sie, Polyfill.io, glaube ich, von irgendeiner,

00:11:20.463 --> 00:11:24.804
was mit britischen Zeitschrift, meine ich, die das Guardian oder sowas,

00:11:24.804 --> 00:11:26.361
die das ursprünglich betrieben hatten.

00:11:27.017 --> 00:11:30.854
Die Idee war großartig. Du hast gesagt, ich möchte die und die Polyfilts und

00:11:30.854 --> 00:11:33.914
dann hat der Browser eben dynamisch entschieden, brauche ich die,

00:11:33.914 --> 00:11:34.766
brauche ich das oder nicht.

00:11:35.335 --> 00:11:39.424
Dann wurde das CDN übernommen von, ich meine, es war eine chinesische Firma

00:11:39.424 --> 00:11:44.455
und dann war sofort natürlich irgendwie Stamble drin und Tracking und keine Ahnung was.

00:11:45.134 --> 00:11:50.024
Und ursprünglich war da eine URL im schönen Saugerwert, die dir was auch immer

00:11:50.024 --> 00:11:54.954
zurückgegeben hat, jQuery in der Version 3.4.1 und die neue übernommene Version

00:11:54.954 --> 00:11:59.285
war dann eben jQuery 3.4.1 und noch ein bisschen Schindluder dabei,

00:12:00.092 --> 00:12:04.414
und ja, das will man halt natürlich nicht haben, wenn man ein großer Publisher

00:12:04.414 --> 00:12:09.572
ist und eigentlich davon ausgelden, CDN ist eine vertrauenswürdige Quelle. Ja, ja.

00:12:11.098 --> 00:12:13.589
Genau, und also.

00:12:15.882 --> 00:12:18.842
Ihr wollt das Problem lösen. Ich glaube, anders ist tatsächlich dann auch wieder,

00:12:19.742 --> 00:12:27.282
die, da machen wir quasi so den Rückgriff auf die Prompt-API und Konsorten.

00:12:27.982 --> 00:12:32.861
Du hast ja auch gesagt, wenn man jetzt irgendwie sowas wie Transformer.js benutzt und ein Modell lädt,

00:12:33.407 --> 00:12:41.551
dann ist es natürlich sehr unangenehm, wenn eben jede Präsenz das Modell mit,

00:12:41.725 --> 00:12:46.592
keine Ahnung wie viel, 100 Megabyte oder Gigabyte, also nicht 100 Gigabyte,

00:12:46.592 --> 00:12:47.850
aber mit ein paar Gigabyte,

00:12:48.862 --> 00:12:49.842
runterladen muss.

00:12:49.842 --> 00:12:53.381
Und bei der nächsten Seite dieses, also ich glaube, das steht einfach so der

00:12:53.729 --> 00:12:59.372
höheren Adoption dieser Dinge im Weg, so wie vielleicht eben auch von irgendwelchen

00:12:59.372 --> 00:13:02.193
WebAssembly-Paketen, die ein bisschen größer sind.

00:13:04.033 --> 00:13:07.545
Genau, und wir haben es ja gehört, Wenn Browser das shippen,

00:13:07.922 --> 00:13:09.502
dann finden die Leute das irgendwie auch blöd.

00:13:09.502 --> 00:13:12.612
Dann hat man dieses Problem zwar nicht, weil es sozusagen ja mit dem Browser

00:13:12.612 --> 00:13:17.952
kommt, aber hat andere Probleme, wie eben, dass jeder Browser dann anders arbeitet,

00:13:17.952 --> 00:13:22.092
weil jeder sein eigenes Modell mitbringt und du nicht das bekommst, was du haben möchtest.

00:13:24.211 --> 00:13:27.423
Genau, und ich glaube, das war der Anlass, und natürlich funktioniert das auch,

00:13:27.883 --> 00:13:35.467
für andere Typen von Ressourcen, dass die Lösung ist Cross-Origin-Storage.

00:13:35.954 --> 00:13:42.775
Wie funktioniert das? Also wie will es dieses Problem lösen,

00:13:43.495 --> 00:13:49.403
idealerweise endgültig, und gleichzeitig die Probleme, die wir eben genannt haben, umgehen?

00:13:51.377 --> 00:13:57.112
Ja, also nochmal, das Ganze ist nicht nur AI, also das war mir vor allem ganz, ganz wichtig.

00:13:58.001 --> 00:14:01.263
Viele innerhalb von Google haben gesagt, lasst uns das Problem noch lösen für

00:14:01.263 --> 00:14:05.473
AI und nur für AI, weil das ist der größte Hebel, weil was schon erwähnt,

00:14:05.473 --> 00:14:09.146
da geht es eben um Gigabytes und nicht 200 Kilobytes oder Megabytes.

00:14:10.203 --> 00:14:15.193
Aber ja, mir war das eben wichtig zu sagen, nee, das Problem ist weit über AI

00:14:15.193 --> 00:14:19.463
hinaus und heute sprechen wir meistens nicht mehr über jQuery,

00:14:19.803 --> 00:14:21.836
heute sprechen wir über React, über Vue.

00:14:22.603 --> 00:14:27.693
Die ganzen typischen Libraries, Blit, die ganzen Building Blocks,

00:14:27.693 --> 00:14:30.183
die eben für heutige moderne Websites da sind.

00:14:30.764 --> 00:14:34.223
Aber es gibt eben auch sehr viele Hidden Champions. Also du hattest WebAssembly

00:14:34.223 --> 00:14:38.601
erwähnt, es gibt ein sehr populäres Paket, das eben dir erlaubt,

00:14:38.798 --> 00:14:40.973
Silbentrennung im Web zu betreiben.

00:14:40.973 --> 00:14:44.603
Das macht der Browser zwar nativ für viele Sprachen, aber eben für viele Sprachen

00:14:44.603 --> 00:14:47.903
auch noch nicht oder noch nicht gut genug, sodass viele dann sagen,

00:14:48.403 --> 00:14:50.092
wir sind ein etablierter Publisher.

00:14:50.394 --> 00:14:56.513
Bevor wir jetzt dem Browser seine richtig üble Zeilen-Umbrüche nehmen oder Sirben-Umbrüche

00:14:56.513 --> 00:15:00.503
nehmen, schippen wir einfach ein etabliertes Paket, wo wir wissen,

00:15:00.503 --> 00:15:02.260
das sieht dann auch ordentlich aus.

00:15:02.857 --> 00:15:05.763
Und genau, das ist tatsächlich, wie gesagt, ein Hidden Champion.

00:15:05.763 --> 00:15:09.743
Wir verwenden sehr viele Publisher, sehr viele Seiten, die einfach Wert legen

00:15:09.743 --> 00:15:15.814
auf saubere Sirben-Trennung und hat man eben dann das Problem oder das Thema mit WebAssembly,

00:15:16.498 --> 00:15:20.835
Es gibt Flutter, es gibt Kotlin-Multiplattformen, die dann eben sowas wie Diskia,

00:15:21.543 --> 00:15:24.248
Grafikbibliothek nach WebAssembly kompilieren.

00:15:24.724 --> 00:15:31.887
Es gibt PostgreSQL, SQLite als Vasem-Pakete, die dann eben Datenbanken im Web ermöglichen,

00:15:32.537 --> 00:15:37.553
und FFMPEG, auch großes WebAssembly-Thema, also alle, die irgendwie wahrscheinlich

00:15:37.553 --> 00:15:41.616
diese Software, die wir jetzt hier verwenden, SendCaster, aber wenn das irgendwo intern FFMPEG-Versen,

00:15:42.272 --> 00:15:47.043
und genau, Genau, also das Thema ist eben weit über AI hinaus.

00:15:48.123 --> 00:15:52.215
WebAssembly, Webfonts hatten wir auch noch nicht erwähnt. Großes Thema, Webfonts.

00:15:52.697 --> 00:15:58.438
Viele wollen schöne Emojis verwenden, die eben vorhersehbar gut aussehen auf allen Plattformen.

00:15:58.955 --> 00:16:02.753
Man kennt das ja vielleicht von Windows, wo die Fahnen-Emojis dann teilweise

00:16:02.753 --> 00:16:06.408
als Buchstaben dargestellt werden, was viele nicht so wirklich toll finden.

00:16:06.907 --> 00:16:11.003
Und wenn man da eben ein vorhersehbares Rendering haben möchte,

00:16:11.003 --> 00:16:13.879
dann bist du halt sehr schnell bei sowas wie NotoColor-Emoji.

00:16:14.442 --> 00:16:17.973
Und ja, das ist eben eine sehr, sehr große Plattform, die du dann runterladen

00:16:17.973 --> 00:16:20.983
musst, die wahrscheinlich schon irgendwo in deinem Cache liegt,

00:16:20.983 --> 00:16:23.423
aber halt nicht verwendet werden kann. Ja.

00:16:23.881 --> 00:16:27.817
Aber haben all diese genannten Dinger nicht immer noch dieses,

00:16:28.148 --> 00:16:30.893
wir haben viel zu viele verschiedene jQuery-Versionen-Problemen?

00:16:30.893 --> 00:16:36.832
Bei so AI-Modellen scheint mir ja so, da gibt es auch reichlich und reichlich Versionen,

00:16:38.394 --> 00:16:41.543
Aber da scheint mir ja doch insgesamt die Kadenz etwas geringer zu sein als

00:16:41.543 --> 00:16:47.953
jetzt bei, keine Ahnung, ich bin eine populäre mit WebAssembly implementierte Kiste.

00:16:47.953 --> 00:16:51.808
Also wieso ist das jetzt kein Problem mehr, was vorher das Problem war mit jQuery?

00:16:56.121 --> 00:16:58.842
Das Problem können wir anfangen, ein bisschen zu adressieren.

00:16:59.262 --> 00:17:04.631
Wenn wir entsprechend gleich mit den Leuten arbeiten und eben das Thema auf den Tisch bringen,

00:17:05.235 --> 00:17:09.172
dann kann man eben anfangen zu sagen, okay, vielleicht muss das nicht sein,

00:17:09.172 --> 00:17:13.542
dass man jedes Mal jeden Tag sofort neu released, wenn man weiß,

00:17:13.542 --> 00:17:14.912
man macht sich dadurch den Cache kaputt.

00:17:14.912 --> 00:17:19.502
Also, es gibt für Pre-Bit.js ein öffentliches Issue, das können wir vielleicht

00:17:19.502 --> 00:17:22.972
in den Shownotes verlinken, wo die eben ganz genau das gesendet haben.

00:17:22.972 --> 00:17:26.792
Also, Pre-Bit.js, gerade im Publishing-Bereich, sehr populäre Bibliothek,

00:17:26.792 --> 00:17:32.632
um eben, ich glaube, Header-Bidding zu betreiben, also Ads anzuzeigen und fast

00:17:32.632 --> 00:17:34.109
jede Seite verwendet diese Bibliothek.

00:17:34.840 --> 00:17:39.842
Und wenn die eben wissen, das könnte eine Bibliothek sein, die zukünftig von,

00:17:40.322 --> 00:17:42.525
Cross-Origin-Storage-Caching profitiert,

00:17:43.140 --> 00:17:45.872
dann haben die eben direkt ins Issue geschrieben, okay, dann muss es vielleicht

00:17:45.872 --> 00:17:48.652
nicht sein, dass wir sofort releasen, dann können wir vielleicht auch ein bisschen

00:17:48.652 --> 00:17:50.768
unseren Pace verlangsamen.

00:17:51.226 --> 00:17:53.552
Es gibt die Idee, dass man das dann ein bisschen modularisiert,

00:17:53.552 --> 00:17:57.275
also sprich, dass es eine stabile Core-Version gibt, die dann quasi,

00:17:57.757 --> 00:18:00.912
was auch immer, ein paar Monate stabil bleibt und dann eben Module,

00:18:00.912 --> 00:18:04.302
die vielleicht etwas flexibler sind und dann auch öfters aktualisiert werden

00:18:04.302 --> 00:18:06.202
können, die dann natürlich aber kleiner sind.

00:18:07.103 --> 00:18:10.902
Also sprich, das Thema ist natürlich nach wie vor da. Es gibt,

00:18:11.242 --> 00:18:16.532
wenn du auf naxt.fyi gehst, Daniel Rowe hat so eine Seite erstellt,

00:18:16.532 --> 00:18:20.662
wo man eben sehen kann, wie die Seiten, die auf naxt basieren,

00:18:20.662 --> 00:18:22.039
ihre Versionen aktualisieren.

00:18:22.631 --> 00:18:26.392
Und da siehst du, die sind eigentlich fast alle auf dem neuesten Stand.

00:18:26.392 --> 00:18:31.130
Also es gibt so eine Hockeystick-Verteilung und dann eben die neueste Version, die populärste ist.

00:18:31.525 --> 00:18:34.822
Und dann hast du so ein bisschen, ja, gibt es noch ein paar Media-Versionen,

00:18:34.822 --> 00:18:38.622
aber die meisten Versionen sind ja doch, oder die meisten Seiten sind ja doch

00:18:38.622 --> 00:18:40.527
auf der neuesten Version ziemlich schnell.

00:18:41.113 --> 00:18:43.858
Genau, und so, wenn man eben mit den Leuten direkt arbeitet...

00:18:44.795 --> 00:18:49.590
Meinen wir, es gibt durchaus Chancen, dass die Cache-Hitrate sich verbessert.

00:18:50.598 --> 00:18:54.058
JQuery ist natürlich sehr populär, aber ja, fehlt es natürlich Legacy,

00:18:54.058 --> 00:18:59.522
das niemals aktualisiert wird und wahrscheinlich auch in manchen Fällen nie aktualisiert wurde.

00:19:00.044 --> 00:19:04.788
Während viele heutige Applikationen, ja, die bauen natürlich auf großen Bausteinen

00:19:04.788 --> 00:19:10.388
auf und die gehen dann halt quasi den Hype-Train mit und nehmen dann jede React-Version

00:19:10.388 --> 00:19:12.833
mehr oder weniger mit oder jede Vue.js-Version mit.

00:19:13.326 --> 00:19:19.178
Also, wir denken, es könnte durchaus Chancen geben, dass wir äußere Cush-Hydraten

00:19:19.178 --> 00:19:22.778
in der Zukunft haben werden als in der Vergangenheit, wo eben das Thema Cushing

00:19:22.778 --> 00:19:26.533
mehr so ein Nebeneffekt war, aber eben nicht von vornherein eingepreist war.

00:19:27.165 --> 00:19:30.398
Diesmal arbeiten wir von vornherein eben auch gleich mit Nuxt,

00:19:30.698 --> 00:19:32.268
Next und so weiter, also nur großen,

00:19:32.878 --> 00:19:37.168
Meta-Frameworks oder Server-Frameworks zusammen, sodass die eben auch von vornherein,

00:19:37.168 --> 00:19:40.038
wenn sie bundlen, schon mal gucken können, wo ergibt das denn Sinn,

00:19:40.038 --> 00:19:41.908
dass man vielleicht stabile Bundles

00:19:41.908 --> 00:19:45.849
erzeugt, die dann auch eine relativ garantierte Cache-Hitrate haben.

00:19:46.684 --> 00:19:50.668
Und ja, jetzt wollte ich gerade erzählen, wie das Ganze funktioniert.

00:19:51.578 --> 00:19:56.408
Kleiner Seitenabweg hier, aber bei mir ist es durchaus nötig.

00:19:56.930 --> 00:20:01.538
Genau, wie funktioniert das Ganze? Also die Grundidee, das Ganze ist Hash-basiert.

00:20:01.538 --> 00:20:06.368
Also sprich, wenn ich eine Ressource habe, dann berechne ich den Hash von dieser

00:20:06.368 --> 00:20:10.168
Ressource und kann dann sagen, ich bin die Seite, keine Ahnung,

00:20:10.168 --> 00:20:16.040
exsupple.com und ich benötige eine Webfont und diese Webfont hat den Hash abc123.

00:20:17.189 --> 00:20:20.838
Das prügele ich in meinen CSS rein, also das ist ja so eine Front-Face-Declaration

00:20:20.838 --> 00:20:26.448
und diese Front-Face-Declaration hat dann eine URL, diese URL hat eine Source, nee, andersrum,

00:20:27.268 --> 00:20:30.578
diese Front-Face-Declaration hat eine Source und diese Source hat eine URL und

00:20:30.578 --> 00:20:35.108
in diese URL-Funktion schreibt man dann ja normalerweise die tatsächliche URL

00:20:35.108 --> 00:20:37.508
rein, wo die Web-Font herkommt und,

00:20:38.188 --> 00:20:42.278
mit Cross-Origin-Storage für Web-Fonts gibt es dann eben die Möglichkeit,

00:20:42.278 --> 00:20:44.728
dass man dann dort noch sagt, okay, und,

00:20:45.575 --> 00:20:50.573
ich verwende einen neuen Request-URL-Modifier, den wir Cross-Origin-Storage nennen,

00:20:51.182 --> 00:20:54.851
und ja, da kannst du dann eben sagen, wenn diese URL,

00:20:55.751 --> 00:20:59.193
noch nicht in die Ressource mit dieser URL und diesem Cache,

00:20:59.576 --> 00:21:04.998
der über die Integrity übergeben wird, wenn die noch nicht im Cache drin ist,

00:21:04.998 --> 00:21:06.914
also Cross-Origin-Storage, Cache,

00:21:07.688 --> 00:21:11.588
dann zieh sie von der URL, die du hast, steck die Ressource in,

00:21:12.268 --> 00:21:16.916
den Cross-Cache rein und ab da kann dann eben von jeder anderen Website,

00:21:17.049 --> 00:21:20.944
sobald die Integrity übereinstimmt, also der Hashtag übergeben wurde,

00:21:21.316 --> 00:21:25.496
übereinstimmt, kann dann auch jede andere Website diese Web-Fall verwenden.

00:21:27.144 --> 00:21:29.308
Das ist die, eine der deklarativen Formen.

00:21:30.611 --> 00:21:33.760
Grundlegender ist wahrscheinlich die imperative Form, wo man eben sagt,

00:21:34.280 --> 00:21:39.530
wir gestalten eine neue Browser-API, Navigator.CrossOriginStorage,

00:21:39.530 --> 00:21:45.749
das gibt ja schon Navigator.Storage, das wäre Navigator.CrossOriginStorage und dann hast du in.

00:21:47.125 --> 00:21:53.120
Navigator.Storage hast du GetDirectory als Grundfunktion, die dir dann eben

00:21:53.120 --> 00:21:58.839
so ein Root-Verzeichnis gibt und analog dazu haben wir dann eben RequestFileHand.

00:21:59.501 --> 00:22:04.522
Und diese Request-File-Handle-Funktion, der übergibst du den Hash von der Ressource, die du haben möchtest.

00:22:05.109 --> 00:22:09.845
Und ja, dann gibt dir die ein sogenanntes File-System-File-Handle zurück.

00:22:10.020 --> 00:22:15.530
Das im Konzept, das kommt von der File-System-Access-API oder OPFS-API inzwischen

00:22:15.530 --> 00:22:19.453
dann als standardisierte Version. Origin-Private-File-System.

00:22:20.010 --> 00:22:23.920
Und ja, das ist eben so ein klassisches File-Handle. Über dieses File-Handle

00:22:23.920 --> 00:22:26.593
kannst du dann eine File bekommen, also die eigentliche Datei.

00:22:27.295 --> 00:22:32.330
Und ja, ab diesem Moment hast du dann das File, den Block und kannst dann mit

00:22:32.330 --> 00:22:33.256
der Ressource erarbeiten.

00:22:34.520 --> 00:22:40.280
Das ist also die imperative Form. Die Idee ist analog eben gestaltet zu der

00:22:40.280 --> 00:22:46.456
OPFS API, wo du hast diese Get-File-Handle-Funktion.

00:22:47.182 --> 00:22:53.420
Wir haben da eben Request-File-Handle mit parallel auch gestaltet der Create-True-Option,

00:22:53.420 --> 00:22:55.910
wo du dann sagen kannst, okay, wenn das noch nicht existiert,

00:22:55.910 --> 00:23:00.707
dann erstelle es, also sprich, das ist dann der schreibende Zugriff auf Codes,

00:23:01.329 --> 00:23:06.470
und ja, wenn du dann eben create true übergibst, dann kannst du diese Funktion

00:23:06.470 --> 00:23:08.660
am Ende über einen writable streamen,

00:23:09.508 --> 00:23:12.376
den Blob, den du schon hast, in der Codes Cache reinschreiben,

00:23:12.637 --> 00:23:15.470
also rein streamen oder rein pipen, wie auch immer,

00:23:16.038 --> 00:23:20.820
das ist das alles eben sehr elegant möglich über die bisher existierenden APIs,

00:23:20.820 --> 00:23:24.940
die wir einfach nur mitverwenden, Also neue Sachen, die wir erfunden haben,

00:23:24.940 --> 00:23:26.575
sind eigentlich sehr, sehr wenige.

00:23:26.696 --> 00:23:29.064
Es baut auf existierenden Grundbausteinen auf.

00:23:32.430 --> 00:23:36.018
Diese Revision von Working Draft wird euch präsentiert von Node.conf EU,

00:23:36.291 --> 00:23:38.357
einer knuffigen Konferenz rund um Node.js.

00:23:38.781 --> 00:23:42.558
Bologna, liebe Hörerinnen und Hörer, wie wär's, ne? Genau dort steigt nämlich

00:23:42.558 --> 00:23:45.614
Ende September die europäische Edition der Node.conf.

00:23:45.898 --> 00:23:48.178
Dort könnt ihr euch an zwei Tagen nicht nur Talks reinziehen,

00:23:48.178 --> 00:23:50.269
sondern auch Zeit mit der Node.community verbringen.

00:23:50.507 --> 00:23:53.878
Die Konferenz ist nämlich ein unabhängiges Community-Event. Ihr macht also nicht

00:23:53.878 --> 00:23:56.668
irgendwelchen Arschgeigen die Taschen voll, sondern helft tatsächlich der Community

00:23:56.668 --> 00:23:58.919
dabei, solche Events auszurichten.

00:23:59.197 --> 00:24:02.798
Das Ganze steigt dann auch nicht in einem gammligen Holiday Inn in Graustadt

00:24:02.798 --> 00:24:05.031
an der Schnarch, sondern in Italien.

00:24:05.339 --> 00:24:08.768
Es ist sogar ein episches Dinner im Ticketpreis enthalten. JavaScript vs.

00:24:08.768 --> 00:24:11.080
Tortellini ist also keine Entweder-Oder-Frage.

00:24:11.382 --> 00:24:14.928
Wenn ihr also schon immer mal einen Italien-Trip von der Steuer absetzen oder

00:24:14.928 --> 00:24:19.358
über das Fortbildungsbudget eures Arbeitgebers abrechnen wolltet, das ist eure Chance.

00:24:19.782 --> 00:24:24.693
Tickets und Infos findet ihr auf noteconf.eu. Wir wünschen euch viel Spaß in Bologna.

00:24:29.052 --> 00:24:34.533
Und dann gibt es noch andere deklarative Möglichkeiten in Cross reinzugreifen,

00:24:34.533 --> 00:24:38.113
nämlich über direkte HTML-Integrationen, dass du eben sagen kannst,

00:24:38.473 --> 00:24:40.593
über Link oder über Script-Tags,

00:24:41.109 --> 00:24:47.901
dass du denen eben die Integrity übergibst und dann eben auch Cross-Origin-Storage als Attribut.

00:24:48.499 --> 00:24:52.653
Und genau wie bei der Webfront-Geschichte, wenn der Hash passt,

00:24:52.653 --> 00:24:56.883
dann kannst du eben direkt über dem Cosgash die Ressource beziehen und wenn

00:24:56.883 --> 00:25:01.560
nicht, dann wird die Ressource direkt bezogen von Script.

00:25:02.205 --> 00:25:06.693
Das ist relativ elegant, weil wenn ein Browser das Ganze noch nicht unterstützt,

00:25:06.693 --> 00:25:10.043
dann wird das einfach ignoriert, also dann schaut der Browser zwar,

00:25:10.043 --> 00:25:13.903
okay, ich sehe da ein Cross-Ordent-Storage-Attribut, aber ich weiß nicht,

00:25:13.903 --> 00:25:15.370
was das ist, ich ignoriere das einfach.

00:25:16.026 --> 00:25:19.498
Und die letzte Variante, die wir dann noch haben,

00:25:20.573 --> 00:25:27.723
das wäre die JavaScript-Integration und da ist die Idee, dass man eben über

00:25:27.723 --> 00:25:33.493
JavaScript-Imports auch direkt über JavaScript in Kost reinkommt.

00:25:33.493 --> 00:25:38.313
Also es gibt ja dann Import und dann irgendwie hast du den, die URL letztendlich.

00:25:39.408 --> 00:25:41.893
Den Ort, wo die Bessource herkommen soll, also keine Ahnung,

00:25:41.893 --> 00:25:45.813
Import, was auch immer du möchtest, from und dann gibst du eben an,

00:25:45.813 --> 00:25:51.766
wo das herkommen soll und dann hast du den Import, wie heißt das nochmal,

00:25:52.773 --> 00:25:54.913
hat einen richtigen Namen, sollte ich wissen, weiß ich gerade nicht,

00:25:55.249 --> 00:25:56.483
also with und dann sagst du.

00:25:56.513 --> 00:25:58.895
Import-Attributes. Danke, Import-Attributes, danke.

00:25:59.573 --> 00:26:03.986
With type JSON zum Beispiel oder with type was auch immer.

00:26:05.321 --> 00:26:10.283
Und da ist dann die Idee, dass wir uns direkt reinhacken in dieses System und

00:26:10.283 --> 00:26:15.358
sagen, auch hier übergeben wir dann die Integrity, das existiert auch schon,

00:26:15.753 --> 00:26:18.115
und die Cross-Origin-Storage-Storage.

00:26:19.677 --> 00:26:23.472
Das ist ein Cross-Origin-Storage-Attribut und können uns auf diese Art und Weise

00:26:23.472 --> 00:26:26.183
dann eben auch direkt in Cross mit reinhacken.

00:26:26.630 --> 00:26:32.402
Das ist leider nicht progressively enhanceable, also da muss Browsersport da

00:26:32.402 --> 00:26:38.722
sein, sonst ist es eben ein Syntax-Fehler, aber ja, da gibt es wahrscheinlich auch Wege drumherum.

00:26:39.282 --> 00:26:43.853
Wir hatten das ja schon mal über IS-Module-Sims, die dann eben auch so neue

00:26:44.109 --> 00:26:47.942
Funktionen in JavaScript verfügbar gemacht haben, indem sie so ein spezielles,

00:26:48.834 --> 00:26:52.462
ja, Script-Type und dann eben was, was noch nicht unterstützt war,

00:26:52.902 --> 00:26:56.160
was dann der Threadspiler entsprechend umgeschrieben hat.

00:26:57.111 --> 00:26:59.782
Ja, das haben wir noch gar nicht erwähnt. Es gibt eine Extension,

00:27:00.542 --> 00:27:05.532
also eine Browser-Extension, die die ATI heute schon unterstützt und genau,

00:27:05.532 --> 00:27:10.538
da kann man eben über solche Umwege dann quasi die moderne Syntax schon heute verwenden.

00:27:12.669 --> 00:27:17.261
Genau, da gibt es Browser-Plugins für alle Browser, glaube ich.

00:27:18.699 --> 00:27:24.319
Bisher haben wir Chrome und Firefox und Safari ist gerade im App Store Review-Prozess.

00:27:25.671 --> 00:27:29.485
Da weiß man natürlich nie, was da passiert. Firehawks war sehr, sehr schnell, sehr fix.

00:27:30.539 --> 00:27:33.739
Ja, bei Safari war ich noch, was da passiert. Aber vielleicht,

00:27:33.739 --> 00:27:36.619
bis die Folge rauskommt, ist das schon publik.

00:27:37.439 --> 00:27:40.569
Es gibt eine Ressource, die nennt sich Awesome Cross-Origin-Stored,

00:27:40.569 --> 00:27:42.366
also so eine klassische Awesome-Liste.

00:27:42.837 --> 00:27:46.849
Ähm, das sind die ganzen Ressourcen, ähm, gelinkt und sobald die,

00:27:46.849 --> 00:27:49.826
äh, Safari-Version rauskommt, werde ich dann diese Liste auch aktualisieren.

00:27:50.453 --> 00:27:52.479
Auf dieser Awesome-Liste haben wir auch ein paar coole Demos,

00:27:52.479 --> 00:27:55.739
ähm, wo man eben auch heute schon sehen kann, was da alles möglich wird,

00:27:55.739 --> 00:27:57.939
ähm, zum Beispiel, ähm, Mr.

00:27:57.939 --> 00:28:01.239
Doop, kennen viele vielleicht unter seinem, äh, Codenamen, Ricardo,

00:28:01.659 --> 00:28:05.129
ich glaube, Cabello heißt der, ähm, Mr.

00:28:05.129 --> 00:28:08.477
Doop ist wahrscheinlich der gewössige Name, genau, äh, Mr. 3JS,

00:28:08.953 --> 00:28:15.209
ähm, der hat, äh, Descent und, äh, Quake portiert, sodass sie auf 3.js als Bibliothek,

00:28:15.209 --> 00:28:18.508
quasi als Gaming-Bibliothek laufen, Game Engine laufen.

00:28:19.071 --> 00:28:23.289
Und über Cross-Origin-Storage ist es dann eben möglich, dass beide Spiele sich

00:28:23.289 --> 00:28:27.019
die 3.js-Game Engine sozusagen teilen und.

00:28:27.702 --> 00:28:33.679
Dann eben einmal nur runterladen, über Cross-Verfügung machen und kannst du

00:28:33.679 --> 00:28:34.598
eben direkt damit arbeiten.

00:28:34.807 --> 00:28:38.139
Vielleicht stoppt Ihnen das ja so viel Releases-Hausdauen, weil da weiß ich

00:28:38.139 --> 00:28:42.219
auf jeden Fall, also 3.js released ja irgendwie auch 3 war am Tag eine neue

00:28:42.219 --> 00:28:45.727
Version, ich weiß gar nicht, bei welcher Versionsnummer die mittlerweile angekommen sind.

00:28:46.255 --> 00:28:48.606
Echt irre. Ja, also zumindest früher war das so.

00:28:49.169 --> 00:28:52.429
Da bin ich auch drüber gestolpert. Die haben ja tatsächlich kein klassisches

00:28:52.429 --> 00:28:55.949
Sample, sondern die haben einfach nur Versionsnummern, also 162 oder sowas war,

00:28:55.949 --> 00:28:58.979
glaube ich, die aktuelle, als ich ja dem R3...

00:28:58.979 --> 00:29:02.329
Ich glaube, ich war mal bei 60, hatte ich da reingeguckt und als ich fertig

00:29:02.329 --> 00:29:07.066
gelesen hatte, die Doku war die Versionsnummer schon 61 ungefähr. Ja.

00:29:08.203 --> 00:29:12.425
Das ist ja fast Web-Browser-esk. Ja, genau. Wenn die Release-Cycles dann jetzt.

00:29:13.965 --> 00:29:15.767
Alle zwei Wochen, ist es alle zwei Wochen?

00:29:16.835 --> 00:29:19.445
Bei Chrome, ja. Und Firefox hat auch gerade geschickt. Sie wollen jetzt auch

00:29:19.445 --> 00:29:22.585
auf zwei Wochen umstellen. Ja, bald einmal die Woche.

00:29:23.085 --> 00:29:27.347
Ich würde echt sagen, das ist ein Erfolgsrezept, würde ich sagen. Ja, genau.

00:29:31.065 --> 00:29:35.225
Vielleicht müsste man noch ergänzen, wenn man sich entscheidet,

00:29:35.225 --> 00:29:43.201
also man fragt ja an, den Cross-Origin-Storage, hey, hast du,

00:29:45.325 --> 00:29:49.679
diese Datei oder die Inhalte, die unter diesem Hash sich identifizieren, hast du die?

00:29:50.097 --> 00:29:55.635
Wenn ja, gib sie mir. Ansonsten kann man eben, also im Zweifelsfall kann man

00:29:55.635 --> 00:29:59.745
einfach den Fallback machen auf ganz normal, weiß ich nicht,

00:29:59.745 --> 00:30:01.126
Fetch und sich das holen.

00:30:02.505 --> 00:30:07.645
Und das war's. Der Browser cached ja diese Sachen dann auch für das eigene bis

00:30:07.645 --> 00:30:11.413
er irgendwann mal entscheidet, dass er das evikten möchte oder so.

00:30:12.323 --> 00:30:18.139
Und man kann hingehen und dann sagen, ich möchte das jetzt auch wirklich tatsächlich,

00:30:18.777 --> 00:30:21.639
in dem Cross-Origin-Storage abgelegt haben.

00:30:22.228 --> 00:30:25.968
Muss man nicht machen, aber kann man machen. Und das ist dann standardmäßig

00:30:25.968 --> 00:30:28.958
immer gescoped, glaube ich, auf den Same-Site-Origin, richtig?

00:30:28.958 --> 00:30:32.512
Also das heißt, wer anderes würde nicht davon profitieren.

00:30:33.231 --> 00:30:36.108
Magst du mal kurz sagen, wie da,

00:30:37.488 --> 00:30:42.688
der Vorteil in diesem Szenario ist, wenn man eben die Origins nicht,

00:30:43.528 --> 00:30:47.648
erweitert, sondern sagt, ich nehme das Default, was eben nur meine eigene Seite

00:30:47.648 --> 00:30:52.928
ist, werden die Daten dann irgendwie länger im Cross-Origin-Storage gehalten,

00:30:52.928 --> 00:30:55.076
als wenn der Browser die einfach cachen würde?

00:30:56.988 --> 00:31:01.418
Magst du da kurz noch was zu sagen? Also wenn du eine neue Ressource erstellst,

00:31:01.418 --> 00:31:05.728
also sprich schreibend auf den Cache zugreifst, dann rufst du auf Navigator,

00:31:05.728 --> 00:31:06.908
Cross-Origin-Storage,

00:31:07.668 --> 00:31:11.228
Request-File-Handle, übergibst du ihm den Hash von deinem Blob,

00:31:11.228 --> 00:31:16.221
den du speichern möchtest und im zweiten Parameter, also der Options-Spec,

00:31:16.593 --> 00:31:20.738
übergibst du ihm dann Create-True und dann übergibst du ihm die Origins,

00:31:20.738 --> 00:31:22.113
für die das freigeschaltet werden soll.

00:31:22.874 --> 00:31:27.528
Wenn du nichts übergibst, also Origins komplett weglässt, dann ist das Same

00:31:27.528 --> 00:31:30.328
Site. Same Site ist ein bisschen kompliziertes.

00:31:32.028 --> 00:31:35.648
Aber letztendlich, man kann es sich vereinfacht vorstellen als alle Subdomains.

00:31:35.648 --> 00:31:40.108
Also wenn du jetzt der example.com bist, dann kannst du eben quasi alle Subdomains darüber freischalten.

00:31:40.754 --> 00:31:44.288
Das deckt eigentlich schon viele so klassische, was auch immer,

00:31:44.288 --> 00:31:48.428
wir sind in der Office Suite und wir haben jetzt halt officesuite.com und dann

00:31:48.428 --> 00:31:54.309
hast du kalk.officesuite.com, write.officesuite.com und slides.officesuite.com und was auch immer.

00:31:54.802 --> 00:31:58.308
Und das deckt eben schon viele Fälle ab, oder so, keine Ahnung,

00:31:58.308 --> 00:32:03.631
alle diese verschiedenen Office-Programme verwenden ein und dasselbe proprietäre

00:32:04.026 --> 00:32:07.228
AI-Modell für Rechtschaltkorrektur zum Beispiel oder keine Ahnung.

00:32:08.403 --> 00:32:12.188
Wenn du dann eben direkt das so übergibst, indem du Origins komplett weglässt,

00:32:12.577 --> 00:32:17.208
dann wird das freigeschaltet für alle diese Subdomains. Same site.

00:32:18.228 --> 00:32:21.478
Also ist, wie gesagt, etwas kompliziert. Es sind nicht nur alle Subdomains und

00:32:21.478 --> 00:32:26.018
da kommt dann immer Extended, Public, Suffix, West, yada, yada dazu,

00:32:26.018 --> 00:32:27.148
aber vereinfacht kann man...

00:32:27.148 --> 00:32:29.678
Ja, das war, glaube ich, so eine Liste, die die Browser da pflegen.

00:32:29.678 --> 00:32:34.418
Also es gibt Es gab ja auch die Möglichkeit früher irgendwie auf Präsenzen so

00:32:34.418 --> 00:32:38.278
seine eigene Subpräsenz zu erstellen und die hatte dann auch ein Subdomain und

00:32:38.278 --> 00:32:40.869
da will man das dann ja nicht sharen drüber.

00:32:41.241 --> 00:32:45.698
Da hatten wir mal mit dem Fredrik Braun von Mozilla irgendwann das Thema,

00:32:45.698 --> 00:32:47.963
als wir über Core gesprochen haben.

00:32:49.135 --> 00:32:54.599
Genau. GitHub-Pages, die leben ja alle auf github.io und dann hast du eben shep.github.io

00:32:54.599 --> 00:32:56.752
und tomahab.github.io und so weiter.

00:32:57.499 --> 00:33:00.419
Die sind natürlich alle auf github.io, aber letztendlich sind das natürlich

00:33:00.419 --> 00:33:04.588
sehr verschiedene Ressourcen, die du dann natürlich nicht teilen möchtest. Ja.

00:33:05.064 --> 00:33:08.289
Dann die zweite Variante ist, du gibst eine Liste von Origins an,

00:33:08.289 --> 00:33:14.199
also dann sagst du eben, ich bin example.com und ich habe auch nach marketing-site.io

00:33:14.519 --> 00:33:17.660
und was auch immer cdn.jadajada.dev.

00:33:18.719 --> 00:33:22.899
Und dann kannst du eben quasi so eine Liste an Origins übergeben und die finale

00:33:22.899 --> 00:33:26.439
und wahrscheinlich die mächtigste Variante ist dann, dass du einfach sagst Origins

00:33:26.439 --> 00:33:28.533
und dann sagst du Stern, also sprich für alle.

00:33:29.235 --> 00:33:32.828
Und das ergibt natürlich Sinn für sehr viele Ressourcen, die eben sehr, sehr populär sind.

00:33:34.314 --> 00:33:39.699
Jackfury, React, was auch immer, vorher besprochene WebAssembly,

00:33:39.699 --> 00:33:41.675
Silventrennungsengine und was auch immer.

00:33:43.515 --> 00:33:46.633
Und da ist es natürlich dann einfach zu sagen, okay, Moment,

00:33:46.749 --> 00:33:49.299
wir hatten das ja schon mal, hatte ich ganz am Anfang erwähnt,

00:33:49.299 --> 00:33:51.319
mit im Internet kann man keine schönen Dinge haben.

00:33:52.182 --> 00:33:56.029
Was, wenn ich jetzt sage, ich prügele dann einfach eine eindeutige Ressource

00:33:56.029 --> 00:33:57.436
rein für jeden Benutzer?

00:33:58.599 --> 00:34:02.249
Schritt zurück. Die eindeutige Ressource hat dann natürlich auch einen eindeutigen

00:34:02.249 --> 00:34:04.152
Hash. Also das würde schon nicht mehr funktionieren.

00:34:04.814 --> 00:34:08.291
Und dann ist natürlich noch spannend das Thema Cross-Site-Leaks.

00:34:08.732 --> 00:34:10.689
Die Hashes, die sind natürlich kein Geheimnis.

00:34:10.689 --> 00:34:17.539
Also, wenn ich jetzt weiß, es gibt, keine Ahnung, meinebank.de und meinebank.de,

00:34:17.899 --> 00:34:22.329
die zeigt ein anderes Logo an, wenn ich eingeloggt bin, als wenn ich ein nicht

00:34:22.329 --> 00:34:23.279
eingeloggter Kunde bin.

00:34:23.279 --> 00:34:29.890
Also, sagen wir, die zeigt dann an, keine Ahnung, meinebank.de, loggedinuser.png, ja.

00:34:30.622 --> 00:34:32.839
Ja, wenn ich das rausfinde, dann kann ich natürlich sagen, okay,

00:34:33.164 --> 00:34:37.819
wenn ich weiß, dass diese Ressource im Kurs liegt, dann kann ich davon ausgehen,

00:34:37.819 --> 00:34:41.465
der Kunde, der Benutzer ist ein Kunde von meinebank.de.

00:34:42.382 --> 00:34:48.167
Und wäre natürlich blöd, von meinebank.de diese Versource im Kost reinzulegen,

00:34:48.167 --> 00:34:50.138
aber letztendlich hindert sich niemand daran.

00:34:51.636 --> 00:34:55.157
Hashes sind kein Geheimnis. Jeder könnte, sobald man das rausfindet,

00:34:55.157 --> 00:34:57.787
dass das der Fall ist, den Hash von meinebank,

00:34:58.410 --> 00:35:02.857
ist ein gelobter User, GNG, wie auch immer ich die Detail genannt hatte,

00:35:03.095 --> 00:35:06.717
den Hash ausrechnen und dann einfach direkt Proving betreiben.

00:35:06.717 --> 00:35:10.367
Also ich bin jetzt irgendwie Evil Attacker und möchte rausfinden,

00:35:10.867 --> 00:35:14.597
gibt es jemand, der jetzt vielleicht Kunde dieser Bank ist, dann schaue ich

00:35:14.597 --> 00:35:18.372
einfach, hat er die Ressourcen mit dem Hash von diesem Logo im Kausgleich.

00:35:18.957 --> 00:35:24.297
Und wenn die Bank jetzt quasi noch ungeschickter war und das dann geshared hat

00:35:24.297 --> 00:35:31.184
mit Star, also sprich für alle, dann wäre dieser Zugriff tatsächlich theoretisch möglich,

00:35:32.083 --> 00:35:34.555
dass das aber nicht der Fall ist, also dass das nicht geht.

00:35:35.014 --> 00:35:40.395
Da kommt dann ein weiteres Konzept hinzu und das nennt sich die Public Hashlist, PHL.

00:35:41.163 --> 00:35:45.127
Die Idee ist letztendlich, dass die Browsermann-Loren sich zusammentun und sagen,

00:35:45.689 --> 00:35:49.837
lass uns doch einfach mal schauen global, was wissen wir, was sind die populärsten

00:35:49.837 --> 00:35:54.211
Ressourcen und sobald ich eben weiß, eine Ressource ist sehr, sehr populär,

00:35:54.879 --> 00:35:57.607
dann wird es eben nicht mehr zum Orakel, also sprich, wenn ich dann weiß,

00:35:57.987 --> 00:36:00.109
der Benutzer war auf einer Seite, die React verwendet hat.

00:36:01.084 --> 00:36:06.587
Gut, weiß dann nicht viel über die Person, das ist dann kein identifizierendes Merkmal mehr.

00:36:06.993 --> 00:36:09.827
Wenn man nicht weiß, welche Seite React benutzt hat.

00:36:09.827 --> 00:36:15.032
Genau, dann hast du so eine sogenannte K-Anonymity, also sprich,

00:36:15.450 --> 00:36:19.166
k, und k ist dann natürlich sehr, sehr groß, k Seiten verwenden diese Ressource,

00:36:19.717 --> 00:36:24.087
und weil das k eben sehr, sehr groß ist, ist dann am Ende nichts mehr Nützliches

00:36:24.427 --> 00:36:28.645
über diese, ja, über diesen Leak, in Anführungszeichen, möglich.

00:36:29.464 --> 00:36:33.407
Genau, und auf dieser Public Hashlist ist dann eben die Idee,

00:36:33.407 --> 00:36:37.667
dass sich die Vendoren zusammentun und dann eben verschiedene Quellen anschauen,

00:36:37.667 --> 00:36:39.013
also es gibt ja verschiedene ...

00:36:39.994 --> 00:36:44.442
Mehr oder weniger offene CDNs, es gibt die guten und alten Google Ajax und das

00:36:44.442 --> 00:36:48.655
Microsoft Ajax CDN, wo man die ganzen alten jQuery-Versionen drauf findet,

00:36:49.096 --> 00:36:53.242
es gibt NPM, HTTP Archive wahrscheinlich, genau, leichter zu bekommen,

00:36:54.162 --> 00:36:56.898
wo man die Downloadzahlen hat, HTTP Archive.

00:36:57.922 --> 00:37:01.652
Chrome selbst verwendet eine sogenannte Most Pervasive Resource Liste,

00:37:01.652 --> 00:37:07.502
die eben letztendlich auch über das HTTP Archive gespeist wird und genau,

00:37:07.502 --> 00:37:09.256
da sind wir gerade dabei, so ein bisschen zu schauen,

00:37:09.888 --> 00:37:14.632
Wäre das denn möglich, dass man die meisten Ressourcen, die eben im Web so anzutreffen

00:37:14.632 --> 00:37:18.979
sind und die sehr, sehr populär sind, dass man die auch diese Public Hashlist, PHL, übernimmt?

00:37:19.705 --> 00:37:22.512
Und dann hast du natürlich noch das Problem mit den AI-Modellen.

00:37:22.512 --> 00:37:27.001
Also AI-Modelle sind natürlich populär, aber längst nicht so populär wie jQuery.

00:37:27.657 --> 00:37:32.232
Und ja, da ist dann die Idee, dass man sagt, okay, Hugging Face,

00:37:32.232 --> 00:37:38.882
was ja das bisher zentrale AI-Modell-Hub ist, die haben auch so eine Art Ranking,

00:37:38.882 --> 00:37:41.804
wo sie eben sagen, was sind die populärsten AI-Modelle.

00:37:42.315 --> 00:37:44.862
Und da schauen wir uns einfach an, die oberen, was auch immer,

00:37:44.862 --> 00:37:50.674
10.000, 100.000, 1.000, muss man jetzt noch genau schauen, was der Schwellwert dann ist.

00:37:51.249 --> 00:37:57.658
Und genau diese 10.000, wie auch immer, AI-Modelle, deren Hashes,

00:37:57.959 --> 00:38:01.831
übernehmen wir dann eben auch manuell sozusagen auf die Public-Hash-List.

00:38:02.545 --> 00:38:08.488
Das heißt, das ist dann quasi eine zweite, also das ist dann sozusagen wie so ein Türsteher.

00:38:08.785 --> 00:38:12.882
Das heißt also, auch wenn die Bank alles falsch configuriert hat,

00:38:12.882 --> 00:38:17.532
also diese Ressource dann angemeldet hat im Cross-Origin-Storage und auch dann

00:38:17.532 --> 00:38:19.698
noch alle Origins zulässt obendrein.

00:38:21.752 --> 00:38:26.509
Und diese Ressource dann aber nicht auf dieser Liste der weitverbreitenden,

00:38:26.869 --> 00:38:31.259
populären und, keine Ahnung, vielleicht auch sinnvollen Ressourcen für dieses

00:38:31.259 --> 00:38:35.289
Szenario steht, dann wird es halt trotzdem nichts.

00:38:35.289 --> 00:38:39.849
Also man würde dann dennoch quasi einen Fehler zurückbekommen und würde gar

00:38:39.849 --> 00:38:45.425
nicht wissen, dass diese Ressource schon irgendwo im Cache sozusagen oder im Storage.

00:38:46.487 --> 00:38:50.739
Das ist quasi so ein Sicherheitsmechanismus, der eben dann versichert,

00:38:50.739 --> 00:38:55.899
dass du A, entweder sehr, sehr populäre Ressourcen oder eben erlaulistet Ressourcen,

00:38:55.899 --> 00:38:57.829
also AI-Modelle zum Beispiel, wo wir eben sagen,

00:38:58.689 --> 00:39:02.936
die sind nicht populär genug heute, aber wir wissen, da ist durchaus Bedarf da,

00:39:04.226 --> 00:39:06.123
dass du eben dann diese Ressourcen bekommst.

00:39:06.484 --> 00:39:11.865
Ich habe noch kurz eine Frage zu dieser Liste. Wo genau lebt die?

00:39:12.161 --> 00:39:13.444
Ist die in den Browser eingebacken?

00:39:14.042 --> 00:39:18.649
Die würde quasi VG Public Suffix List regelmäßig vom Browser dann runtergeladen

00:39:18.649 --> 00:39:21.606
werden und der Browser würde intern der Kopie davon aufnehmen.

00:39:23.243 --> 00:39:28.612
Okay, also ich frage mich gerade so, es werden ja Dinge auch wieder weniger populär.

00:39:30.470 --> 00:39:35.789
Die fliegen die dann von der Liste runter und wenn ja, kann ich dann Code bauen,

00:39:36.169 --> 00:39:40.066
der in zehn Jahren nicht mehr funktioniert, weil die Liste nicht mehr die ist, die ich erwarte.

00:39:41.481 --> 00:39:44.831
Also die Grundidee ist, dass das Ganze komplett automatisiert und wie gesagt

00:39:44.831 --> 00:39:48.791
neutral funktioniert, also wenn dann eine Ressource nicht mehr populär ist,

00:39:48.791 --> 00:39:50.801
also irgendwie verschwindet von den,

00:39:51.727 --> 00:39:57.318
was auch immer, most popular lists, dass sich dann diese Liste quasi ständig aktuell hält.

00:39:58.648 --> 00:40:01.851
Cross-Origin-Storage ist von vornherein Progressive Enhancement.

00:40:01.851 --> 00:40:04.971
Also du machst dadurch nichts kaputt. Du machst das in Zweifelsfall besser,

00:40:04.971 --> 00:40:07.126
indem du von Cost-Crash profitierst.

00:40:07.568 --> 00:40:10.569
Aber du musst immer davon ausgehen, die Ressource ist noch nicht vorhanden.

00:40:11.401 --> 00:40:14.725
Oder, und da komme ich jetzt gleich noch dazu, oder der Browser lügt.

00:40:15.811 --> 00:40:18.475
Also jedenfalls das Ganze ist ... Das ist klar, dass das so gedacht ist.

00:40:19.461 --> 00:40:24.071
Aber ich kämpfe gerade damit, in einer Windows XP Virtual Machine Internet Explorer

00:40:24.071 --> 00:40:27.061
6 zum Laufen zu bringen, frag nicht. Du hast Hobbys.

00:40:27.345 --> 00:40:30.741
Und das Ding ist jetzt natürlich dann erstmal maximal isoliert,

00:40:30.741 --> 00:40:33.173
weil ist halt Windows XP, da wird ja sofort jeder einmarschieren.

00:40:34.596 --> 00:40:39.437
So ist ja irgendwie klar, kriegt also kein Internet, hat keine Updates und da ist ja dann,

00:40:40.563 --> 00:40:43.402
hab ich ja damit zu kämpfen, dass ich halt eben diese alte Technologie habe

00:40:43.756 --> 00:40:47.151
und ich würde ja gerne dann auch die alten Webseiten aus der Zeit mit dieser

00:40:47.151 --> 00:40:51.000
alten Technologie zumindest darstellen können. Natürlich alles irgendwie sicher eingepackt und sowas.

00:40:51.389 --> 00:40:54.881
Und deswegen meine Frage nach, kann ich Code schreiben, der mir in Zukunft auf

00:40:54.881 --> 00:40:59.481
die Füße fällt, wenn dann der Zukunftspeter mit einer antiken Chrome-Version

00:40:59.481 --> 00:41:01.454
in 20 Jahren den gleichen Stunt nochmal probiert?

00:41:02.029 --> 00:41:04.095
Kann ich also irgendwelchen JavaScript-Code geschrieben haben,

00:41:04.298 --> 00:41:05.601
der sich daran aufhängt, dass

00:41:05.601 --> 00:41:08.652
die Liste in 20 Jahren nicht mehr meinen Erwartungen von heute entspricht?

00:41:09.407 --> 00:41:12.411
Das könntest du heute schon, indem du alle deine Ressourcen über einen Service

00:41:12.411 --> 00:41:16.785
Worker beziehst, der erwartet, dass diese Ressource schon im Cache liegt.

00:41:16.959 --> 00:41:19.479
Machst du natürlich nicht, weil du weißt, das wird nicht der Fall sein.

00:41:19.978 --> 00:41:23.431
Der Service Worker Cache kann jederzeit erdiktet werden, genauso kann der Cost

00:41:23.431 --> 00:41:24.784
Cache jederzeit erdiktet werden.

00:41:25.231 --> 00:41:29.041
Also jede Zeit, da kommen wir noch dazu. Also sprich, du musst immer davon ausgehen,

00:41:29.401 --> 00:41:31.408
eine Ressource ist nicht vorhanden im Cost Cache.

00:41:31.715 --> 00:41:35.281
Genauso wie du heute auch davon ausgehst, in der Cache API, da kann irgendwas

00:41:35.281 --> 00:41:39.959
passieren, der Benutzer kann den Cache zurücksetzen. was auch immer.

00:41:41.707 --> 00:41:44.873
Theoretisch wäre es möglich, den Code so zu schreiben, aber das macht keiner.

00:41:44.873 --> 00:41:48.943
Und genauso wird das mit Cos genauso wenig. Bist du sicher, dass das auch nicht

00:41:48.943 --> 00:41:54.423
jemand machen würde für irgendwie, keine Ahnung, das ist die Version von React,

00:41:54.423 --> 00:41:56.045
mit der ich dieses Ding geweipcoded habe?

00:41:56.305 --> 00:42:01.103
Es ist meine Absicht, das niemals wieder anzufassen. Und ich packe da halt eben

00:42:01.103 --> 00:42:03.921
auch nur so das absolute Mindestmaß an Vorsicht rein.

00:42:04.566 --> 00:42:09.223
Ja, aber da kann ich einspielen. Selbst dann muss diese App initial deine damals

00:42:09.223 --> 00:42:11.123
festgepinnte React-Version runterladen.

00:42:11.123 --> 00:42:14.873
Und das musst du ja irgendwie sicherstellen. Und über diese eine Quelle,

00:42:14.873 --> 00:42:18.695
das ist dann eben dein Single Point of Failure, selbst wenn du davon ausgehst, in der Zukunft,

00:42:20.140 --> 00:42:24.393
du startest das Ding in 30 Jahren, die Public Hash List existiert nicht mehr,

00:42:24.393 --> 00:42:27.473
das heißt, der Browser wird versuchen, die Route zu laden, es gibt sie nicht mehr, der

00:42:27.873 --> 00:42:31.943
Browser sagt dann, okay, meine Public Hash List ist leer, dann wird immer noch

00:42:31.943 --> 00:42:35.622
dein Fallback funktionieren, wo du dann eben zurückfällst und sagst, okay,

00:42:36.122 --> 00:42:38.792
das ist eben die Ressource,

00:42:39.506 --> 00:42:44.433
das ist der Hash davon und wenn dann deine URL nicht mehr funktioniert in 30

00:42:44.433 --> 00:42:45.973
Jahren, dann ist das eben so.

00:42:46.533 --> 00:42:50.680
Das ist aber genau heute auch schon der Fall, wo du halt URLs hast, die gestorben sind.

00:42:52.148 --> 00:42:54.965
Okay, aber das ist jetzt wichtiger Kontext, weil ich müsste mich wirklich anstrengen,

00:42:54.965 --> 00:42:58.795
um das zu schreiben und durch schiere Unachtsamkeit würde ich nicht in die Situation

00:42:58.795 --> 00:43:00.216
kommen. Das ist gut genug für mich.

00:43:01.278 --> 00:43:05.342
Genau, und wie gesagt, das wäre heute schon über eine Service Worker Seite möglich,

00:43:05.678 --> 00:43:09.103
aber du musst natürlich irgendwie initial die Daten in deine Cache reinbekommen.

00:43:09.695 --> 00:43:13.863
Das hast du im Service Worker nicht, weil Service Worker ist ja Origin Isolated.

00:43:15.262 --> 00:43:20.065
Ähm, ja, aber ja, das müsstest du dann halt über Kost, könntest du es theoretisch

00:43:20.065 --> 00:43:22.379
irgendwie hinbekommen, indem du halt davon ausgehisst,

00:43:22.820 --> 00:43:26.035
äh, ich verlasse mich halt drauf, dass dieses Sicherheitsnetz von irgendwer

00:43:26.035 --> 00:43:29.115
hat das schon in Kostcash gepackt, aber das ist völlig unbewillenssicher,

00:43:29.115 --> 00:43:30.738
also niemand würde seine Seite so programmieren,

00:43:31.331 --> 00:43:35.055
es sei denn, man macht eben einen Test quasi so, wie wie Corporate ist,

00:43:35.055 --> 00:43:38.732
ist denn tatsächlich äh, was auch immer, eine Ressource, die ich erwarte,

00:43:38.970 --> 00:43:39.794
das sind Corporate Links.

00:43:40.143 --> 00:43:43.335
Aha, okay, wenn ich in den nächsten paar Jahren so ein Ding mal finde in freier

00:43:43.335 --> 00:43:45.170
Wildbahn, gibst du mir ein Bier aus. Läuft?

00:43:45.588 --> 00:43:48.229
Auf jeden Fall, das war es. Okay.

00:43:50.006 --> 00:43:54.576
Genau, du hattest es eben, wolltest du noch erzählen, dass es eben nicht nur

00:43:54.576 --> 00:43:56.986
sein kann, dass der Browser sagt so, hey,

00:43:57.626 --> 00:44:04.296
es gibt diese Ressource nicht im Cross-Origin-Storage derzeit oder sie ist vielleicht

00:44:04.296 --> 00:44:10.196
da, aber er lehnt dennoch ab, weil sie eben nicht auf der eben erwähnten Liste steht.

00:44:10.196 --> 00:44:12.886
Und dann meinst du, gibt es aber eben auch die, noch den Fall,

00:44:12.886 --> 00:44:18.326
dass der Browser auch theoretisch lügen kann, also beides sehr wohl zutrifft,

00:44:18.326 --> 00:44:21.896
aber der Browser dennoch sich entscheidet, irgendwie zu sagen,

00:44:21.896 --> 00:44:24.498
zu behaupten, nee, richtig? Genau.

00:44:25.406 --> 00:44:28.796
Also ich hatte ja schon erwähnt, wenn du weißt, eine Seite ist mit React gebaut,

00:44:28.796 --> 00:44:34.156
dann findest du nicht wirklich viel über den Nutzer raus, weil eben k-anonymity,

00:44:34.156 --> 00:44:35.726
das ist ein super schwieriges Wort.

00:44:39.766 --> 00:44:42.356
Dann kannst du dir aber natürlich irgendwie was zusammenfassen,

00:44:42.356 --> 00:44:46.806
wo du dann eben sagst, vielleicht React alleine nicht, aber React mit Vue,

00:44:46.806 --> 00:44:49.425
mit keine Ahnung was, mit noch diesem AI-Modell.

00:44:49.605 --> 00:44:53.859
In der Kombination gibt es nur auf der Seite, so rasterfahndungsmäßig.

00:44:54.698 --> 00:44:58.473
Richtig. Und da kannst du natürlich irgendwann dazukommen und sagen,

00:44:58.473 --> 00:45:02.924
okay, jetzt habe ich was, was vielleicht eindeutig genug sein könnte.

00:45:03.708 --> 00:45:07.473
Aber, und dann kommt eben dieses Prinzip dazu, der Browser lügt einfach hin

00:45:07.473 --> 00:45:10.103
und wieder mal und sagt, bei einer Datei, bei einer Ressource,

00:45:10.103 --> 00:45:12.993
wo es jetzt nicht wehtut, also irgendwie, wo du, sagen wir, ein paar hundert

00:45:12.993 --> 00:45:17.680
Kilobyte im Maximalfall runterladen musst, wo du sie eigentlich schon im Cache hättest.

00:45:18.679 --> 00:45:22.003
Da flippt der Browser dann irgendwie randomly ein Byte und sagt,

00:45:22.303 --> 00:45:25.713
EnBit und sagt, okay, diese Ressource ist nicht in CrossCache,

00:45:25.713 --> 00:45:26.997
obwohl sie eigentlich fahren muss.

00:45:27.671 --> 00:45:31.560
Und dadurch wird eben auch dieser Angriff ziemlich unmöglich gemacht,

00:45:31.955 --> 00:45:35.362
weil du halt nie weißt, ja, hat der Browser jetzt gelogen, eigentlich.

00:45:35.856 --> 00:45:41.585
Das Konzept nennt sich Grease, kommt, glaube ich, irgendwie so aus der SSL Terminologie.

00:45:42.483 --> 00:45:47.033
Wenn du diese User Agents, weißt du ja, Advanced User Agents API oder wie auch

00:45:47.033 --> 00:45:48.621
immer, wenn du die anschaust,

00:45:49.218 --> 00:45:53.073
das machen wir auch schon dort, wo da eben, ich glaube, drei User-Agent-String

00:45:53.073 --> 00:45:56.363
hast und die heißen dann irgendwie Not-A-Browser-Agent und dann irgendwie eine

00:45:56.363 --> 00:45:57.629
Zufallszahl und so weiter.

00:45:58.221 --> 00:46:01.878
Also, da wird das auch schon so ein bisschen betrieben und genau,

00:46:01.989 --> 00:46:06.253
so, das ist eben die Idee, dass der Browser hin und wieder einfach mal unvorhersehbar

00:46:06.253 --> 00:46:09.158
lügt und sagt, diese Ressource ist nicht in meinem Cause-Cache.

00:46:09.628 --> 00:46:12.653
Ich weiß, sie tut uns nicht weh. Also, der Browser würde nicht lügen,

00:46:12.653 --> 00:46:14.684
wenn du sagst, hey, ist Jammer 4 im Cache.

00:46:15.603 --> 00:46:19.343
Das wäre natürlich blöd. Aber bei so kleinen Ressourcen, wo es halt nicht wehtut,

00:46:19.343 --> 00:46:23.363
ja, kann der Browser durchaus mal lügen. Mhm.

00:46:26.149 --> 00:46:30.797
Ich glaube, damit haben wir erst mal das Funktionsprinzip dieser API beschrieben.

00:46:31.877 --> 00:46:34.577
Vielleicht kann man noch kurz sagen, wir haben jetzt,

00:46:35.237 --> 00:46:40.897
gerade noch mal über die imperative Form, also das quasi mit JavaScript zu schreiben

00:46:40.897 --> 00:46:47.220
gesprochen, bei der deklarativen, also die so sich in CSS und HTML einhängt.

00:46:48.537 --> 00:46:53.317
Wie ist es da? Werden diese Ressourcen dann auch angelegt automatisch,

00:46:53.817 --> 00:47:01.097
wenn man quasi dieses Cross-Origin-Storage-Attribut oder die CSS-Funktion oder

00:47:01.097 --> 00:47:04.989
wie auch immer ihr das dann da löst, aber ich würde jetzt mal tippen CSS-Funktion wahrscheinlich.

00:47:07.497 --> 00:47:12.327
Wenn ihr das da macht oder sind die sozusagen nur passiv, konsumieren die nur

00:47:12.327 --> 00:47:16.204
und können gar nicht den Cross-Origin-Storage auch befüllen.

00:47:17.197 --> 00:47:20.680
Ich dachte auch, also die würden auch gefüllen. Die Idee ist einfach,

00:47:21.100 --> 00:47:22.990
das quasi als Progressive-Enterment zu machen.

00:47:24.412 --> 00:47:27.830
Die Source oder Ahrefs oder was auch immer du mal hast, die ist natürlich nach

00:47:27.830 --> 00:47:31.576
wie vor da. Und das ist auch die Quelle, wo die Daten dann herkommen.

00:47:32.720 --> 00:47:35.740
Der Browser würde aber zuerst gucken, habe ich dann die Ressource mit dem Hash

00:47:35.740 --> 00:47:37.125
schon in meinem Cross-Cache drin?

00:47:37.537 --> 00:47:40.900
Wenn ja, dann wird überhaupt kein Network-Progress gemacht. Wenn nein,

00:47:40.900 --> 00:47:42.460
dann wird der Network-Progress gemacht.

00:47:42.460 --> 00:47:48.019
Und eben, wenn das Opt-in entsprechend ist, also sprich dein Cross-Origin-Storage,

00:47:48.473 --> 00:47:52.840
auf, ja, ein Sternchen, eine Liste von Origins oder eine Liste von,

00:47:53.744 --> 00:47:59.171
äh, Quatsch, oder nicht gesetzt ist im Sinne von Same-Site, dann würde die Ressource,

00:47:59.613 --> 00:48:02.585
in den Cross-Cash reingelegt werden, wenn, und das ist auch wichtig,

00:48:02.881 --> 00:48:04.080
wenn der Hash dann stimmt.

00:48:04.080 --> 00:48:09.520
Also, kannst du dir sagen, ich vertue mich, ich mache jetzt irgendeinen Tippfehler.

00:48:10.926 --> 00:48:14.590
In der Hash-Ressource oder es kann natürlich auch einen Angriff sein,

00:48:14.590 --> 00:48:19.617
wo du eben sagst, okay, das ist jetzt zwar ein legitimer jQuery-Hash,

00:48:19.889 --> 00:48:23.616
aber letztendlich liefere ich irgendwie kaputtes jQuery.

00:48:24.493 --> 00:48:27.580
Da würde der Browser das aber sofort abfangen, weil das funktioniert dann eben

00:48:27.580 --> 00:48:31.840
direkt über SRI, also was so ist, wie heißt das, Sub-Resource-Integrity.

00:48:31.840 --> 00:48:33.119
Sub-Resource-Integrity, ja.

00:48:33.345 --> 00:48:35.860
Genau, da würde der Browser dann sofort merken, hey, Moment,

00:48:36.260 --> 00:48:41.310
die Hashes stimmen nicht und das würde dann sofort auch verleigert werden und

00:48:41.310 --> 00:48:45.310
der Browser würde dann A, das gibt überhaupt nicht, und B, würde er es auch

00:48:45.310 --> 00:48:47.252
nicht in den Cross-Cash reinlegen.

00:48:47.449 --> 00:48:52.020
Aber die Idee ist tatsächlich, dass wenn diese Cross-Attribute gesetzt sind,

00:48:52.020 --> 00:48:55.280
Und dass eben direkt sich das dann mit Cross auch integriert.

00:48:57.958 --> 00:49:01.432
Genau, also ich habe mir da so ein bisschen Gedanken auch zu gemacht.

00:49:01.432 --> 00:49:10.102
Also ein Gedanke, den ich hatte, ist, ihr habt diese API so gewählt oder auserkoren,

00:49:10.862 --> 00:49:15.562
weil sie auch nah an der File Storage API ist, so von ihrer Art und Weise.

00:49:15.562 --> 00:49:18.990
Sondern man muss nicht so viel Neues lernen, man kann viele Dinge wiederverwenden.

00:49:20.004 --> 00:49:29.302
Was würde dagegen sprechen, das Ganze oder die Browser, die bestehende Cache-Mechanik in den Browsern,

00:49:30.302 --> 00:49:33.832
eben so auf diesen Stand zu heben, zu sagen, also zum einen,

00:49:34.255 --> 00:49:39.802
vielleicht ziehen wir die Caches eben nicht nach Origin, sondern machen vielleicht

00:49:39.802 --> 00:49:43.542
irgendwie doch Same-Site, also öffnen uns wieder ein bisschen.

00:49:43.994 --> 00:49:53.142
Und zum anderen eben vielleicht auch diese Origins-Geschichte irgendwie über Header oder so dann,

00:49:54.356 --> 00:49:59.812
vielleicht regelbar zu machen, weil im Grunde gibt es ja diese Infrastruktur

00:49:59.812 --> 00:50:06.842
schon und man müsste, man könnte quasi sozusagen eigentlich minimalinvasiv könnte man.

00:50:08.126 --> 00:50:13.321
Diese Features unterbringen und dann eben quasi entweder über,

00:50:14.338 --> 00:50:18.727
auch da eine API oder eben über HTTP-Header oder wie auch immer man das halt

00:50:18.727 --> 00:50:21.774
so heutzutage tut, sozusagen draufsatteln.

00:50:21.902 --> 00:50:27.272
Habt ihr darüber gesprochen oder ist das jetzt sowas, was gedanklich noch nicht so richtig so...

00:50:27.974 --> 00:50:29.587
Da haben wir auf jeden Fall drüber gesprochen.

00:50:30.580 --> 00:50:35.277
Also verschiedene Probleme. Also A, viele dieser Cache-Mechanismen basieren

00:50:35.277 --> 00:50:40.187
eben irgendwann auf dem Konzept URL und COS macht das eben nicht.

00:50:40.187 --> 00:50:46.038
Das heißt, du kannst jetzt irgendwie eine Ressource laden von tomsketchyserver.com,

00:50:46.537 --> 00:50:49.287
und solange der Hash stimmt, kannst du dann eben sicher sagen,

00:50:49.287 --> 00:50:54.374
das ist jetzt genau das reiche, wie wenn ich das über das offizielle CDN runtergeladen habe.

00:50:54.844 --> 00:50:56.397
Dieses Konzept haben eben die

00:50:56.397 --> 00:50:59.494
traditionellen Caches nicht. Die sind alle basierend auf regulären URLs.

00:51:00.404 --> 00:51:06.251
Es gibt natürlich auch das Problem, ja, Back-Compatibility, das Ganze muss natürlich

00:51:06.251 --> 00:51:07.521
auch so funktionieren, dass es auch

00:51:07.945 --> 00:51:11.561
mit Browsern, die jetzt sich entscheiden, diese AGI nicht zu implementieren,

00:51:11.561 --> 00:51:15.433
dass es eben nach wie vor funktioniert, oder halt Browser, die alt sind.

00:51:16.716 --> 00:51:19.661
Das Ganze funktioniert eben sehr, sehr elegant über Progressive Enhancement,

00:51:19.661 --> 00:51:23.241
wo du sagst, okay, als Seite guck ich halt, kann ich Kost verwenden,

00:51:23.241 --> 00:51:25.540
wenn nicht, dann hab ich alle bisherigen Mechanismen auf.

00:51:26.950 --> 00:51:32.471
Header, wie gesagt, das hängt natürlich dann mit URLs zusammen, und ja, letztendlich,

00:51:32.976 --> 00:51:36.991
ist es natürlich auch einfach nur eine neue API, wo man dann eben sagt,

00:51:36.991 --> 00:51:40.011
man macht eine ganz bewusste Entscheidung als Developer und sagt,

00:51:40.391 --> 00:51:44.451
okay, das ist eine Ressource, wo ich jetzt auch erwarte, dass ich die Herrschers entsprechend,

00:51:45.154 --> 00:51:49.111
ja, habe, also sprich, das ist dann auch so ein gewisses Opt-in sozusagen in

00:51:49.111 --> 00:51:51.255
einen neuen Speichermechanismus.

00:51:52.323 --> 00:51:55.251
Wenn du dir intern anguckst, wie jetzt zum Beispiel auch die Extension implementiert

00:51:55.251 --> 00:52:01.739
ist, die Extension verwendet die reguläre Cache-API über eine Offscreen-Page in der Extension.

00:52:02.528 --> 00:52:07.431
Und dadurch hast du dann eben den gleichen Cache-Intern-Mechanismus und ich

00:52:07.431 --> 00:52:11.911
vermute auch, die native Implementierung wird dann auch sich in die native Cache-API,

00:52:11.911 --> 00:52:15.665
die schon existiert, mit reinhacken sozusagen von der Implementierung,

00:52:16.751 --> 00:52:18.974
ohne dann halt diese ganze Origin-Geschichte zu haben.

00:52:19.142 --> 00:52:23.801
Also sprich, so intern, ab viel neue Code, wahrscheinlich wird es gar nicht

00:52:23.801 --> 00:52:28.291
so viel brauchen, weil man kann sich eben sehr viel, wie du schon gesagt hast,

00:52:28.291 --> 00:52:31.011
auf existierende Konzepte stützen und,

00:52:31.692 --> 00:52:35.611
genau, aber so von der Developer Surface ist das schon eine ganz bewusste Entscheidung,

00:52:35.611 --> 00:52:39.551
dass das eine neue Ecke ist, aber eben, und da sind wir dann wieder bei den

00:52:39.551 --> 00:52:40.718
deklarativen Varianten.

00:52:42.251 --> 00:52:45.128
Für den Entwickler soll das eine super einfache Lernkurve sein.

00:52:45.128 --> 00:52:48.968
Also sprich, wenn du SRI schon mal gemacht hast, dann noch Cross-Origin-Storage

00:52:48.968 --> 00:52:50.477
dazunehmen, das ist trivial.

00:52:51.408 --> 00:52:54.658
Und diese interaktive API, da könnte man dann natürlich argumentieren,

00:52:54.658 --> 00:52:56.014
warum brauchen wir die überhaupt?

00:52:56.375 --> 00:53:01.728
Und da ist die Antwort dann letztendlich tatsächlich AI, weil in AI ist natürlich

00:53:01.728 --> 00:53:03.678
immer die Geschichte, welches Modell hast du?

00:53:04.194 --> 00:53:08.803
Und angenommen, du machst jetzt irgendwie so eine Transcription-App,

00:53:09.168 --> 00:53:11.625
Also sprich, Speech-to-Text.

00:53:12.176 --> 00:53:15.967
Und deine App funktioniert großartig mit dem Whisper-Tiny-Model.

00:53:16.588 --> 00:53:19.528
Wenn du jetzt aber kommst und über Kost feststellst, oh, der Benutzer hat aber

00:53:19.528 --> 00:53:22.688
schon das Whisper, wie auch immer es heißt, Whisper-Medium, Whisper-Giant.

00:53:23.635 --> 00:53:26.375
Dann sagst du dir natürlich auch nicht Nein und lädst dann Whisper-Tiny runter,

00:53:26.735 --> 00:53:30.848
sondern du könntest dann sagen, okay, ich weiß, ich funktioniere relativ gut

00:53:30.848 --> 00:53:33.875
mit Whisper-Tiny, Whisper-Medium, Whisper-So und So.

00:53:34.351 --> 00:53:38.778
Und könntest dann einfach kurz mal probieren, welche Varianten sind dann schon verfügbar.

00:53:39.080 --> 00:53:43.618
Das Gleiche mit Coding-Modellen, also wenn du sowas hast wie einen Harness,

00:53:43.618 --> 00:53:47.508
wie jetzt Pi zum Beispiel, da kannst du auch verschiedene AI-Modelle dahinter kennen.

00:53:47.828 --> 00:53:50.748
Du kannst dann mit Cloud arbeiten, du kannst mit was auch immer arbeiten,

00:53:50.748 --> 00:53:53.035
Open-A-Rei-LGIs arbeiten.

00:53:53.768 --> 00:53:56.398
Der Harness gehört der Gleiche. Also sprich, diese ganze Idee,

00:53:56.398 --> 00:54:01.168
wo du dann eben sagst, ja, letztendlich das Modell, nicht alle sind kompatibel,

00:54:01.168 --> 00:54:04.239
aber ein Subset davon sind kompatibel.

00:54:04.948 --> 00:54:08.424
Das könnte dann funktionieren. Deshalb haben wir ja auch diese integrative API,

00:54:08.819 --> 00:54:11.872
wo du dann einfach mal probieren kannst, was ist denn vorhanden.

00:54:12.728 --> 00:54:17.956
Fingerprinting ist dann wieder wichtig, also da gibt es auch dann so eine Art Limit, also sprich,

00:54:18.788 --> 00:54:22.028
du darfst jetzt nicht irgendwie 10.000 verschiedene Hashes durchprobieren,

00:54:22.675 --> 00:54:25.228
da wird der Browser dann irgendwann mal sagen, Moment, das sieht jetzt aber

00:54:25.228 --> 00:54:29.578
ziemlich nach einem Fingerprinting-Attempt aus, da sagt der Browser dann irgendwann mal, okay, stopp.

00:54:31.145 --> 00:54:34.934
Weil wir mit Hashes arbeiten, ist das aber auch sehr faktisch, weil diese Hashes,

00:54:35.805 --> 00:54:39.429
Da ist natürlich irgendein Inhalt dahinter. Das heißt, der Browser kann dann auch,

00:54:40.569 --> 00:54:45.679
tatsächlich im Browser AI rausfinden, okay, die Hashes sehen jetzt zwar irgendwie

00:54:45.981 --> 00:54:49.949
random aus, aber natürlich weiß ich als Browser, okay, das sind jetzt alles

00:54:49.949 --> 00:54:53.174
Hashes aus der, sagen wir, bis bei AI-Moder-Familie.

00:54:53.766 --> 00:54:56.099
Das ergibt Sinn, dass die zusammen abgefragt werden. Also sprich,

00:54:56.442 --> 00:55:00.799
da kann man auch so gucken, gibt es irgendwie, braucht man nicht bei AI dafür,

00:55:00.799 --> 00:55:05.199
da kannst du einfach schauen, ja, sind die typischerweise in einem Cluster?

00:55:05.199 --> 00:55:09.764
Sie sind irgendwie verwandt und da kann man eben über den Browser auch sagen,

00:55:10.292 --> 00:55:13.520
da brauchst du jetzt nicht hart kodiert sagen, 10 Prokes und das war's,

00:55:13.839 --> 00:55:16.899
sondern du kannst halt eben auch sagen, weil das eben ein spezieller API ist

00:55:17.032 --> 00:55:20.184
und eben nicht integriert in existierende APIs,

00:55:21.246 --> 00:55:24.358
ja, das sind jetzt auch Patterns, die man dann dynamisch feststellen kann.

00:55:26.621 --> 00:55:30.093
Mhm. Und wie ist das? Macht man dann einen Request-File-Handle für jeden Hash

00:55:30.093 --> 00:55:36.153
oder kann man dann in die, also quasi als Parameter auch ein Array oder eine,

00:55:36.893 --> 00:55:39.217
beliebige Menge Hashes eingeben? Das hatten wir tatsächlich zuerst so.

00:55:39.658 --> 00:55:45.213
Wir haben dann aber über die Extension festgestellt, alle, die das implementiert

00:55:45.213 --> 00:55:49.043
haben, und da haben wir noch gar nicht drüber gesprochen, also bisher basierend

00:55:49.043 --> 00:55:52.922
auf diese Extension haben das schon implementiert, Transformers.js.

00:55:54.913 --> 00:56:02.965
LLM, WLama aus der AI-Familie, und dann haben wir Flutter, wir haben M-Scripten,

00:56:03.953 --> 00:56:07.655
und alle diese Implementierungen haben eigentlich nur die Singularform verbindet.

00:56:08.137 --> 00:56:11.753
Und typischerweise in Chrome hast du ja diesen Mechanismus der Dev-Trials,

00:56:11.753 --> 00:56:15.103
der Origin-Trials und so weiter, bis dann die API shipped.

00:56:15.579 --> 00:56:20.113
Über diese Extension haben wir quasi schon in Anführungszeichen ein Origin-Trial

00:56:20.113 --> 00:56:24.593
vor dem Origin-Trial und haben eben festgestellt, alle Implementierungen verwenden

00:56:24.593 --> 00:56:29.453
nur die Singular-Form und ja, die Singular-Form macht dann eben sehr viel das einfacher, weil,

00:56:30.235 --> 00:56:33.373
wenn jetzt zehn Hashes anfragst, also erstmal ist die Frage,

00:56:33.373 --> 00:56:34.856
wie viele sollen da erlaubt sein,

00:56:35.673 --> 00:56:38.629
Weil da musst du dann irgendwie sagen, okay, maximal 20 oder so,

00:56:39.293 --> 00:56:42.501
wenn du nicht diesen Thinkerprint-Vektor haben möchtest.

00:56:42.983 --> 00:56:47.610
Und was passiert, wenn dann nur Partial-Matches sind? Da musst du irgendwie sagen, okay, äh...

00:56:48.719 --> 00:56:52.481
Was auf einmal ABC 1, 2, 3 habe ich, ABC 3, 4, 5 habe ich nicht.

00:56:54.344 --> 00:56:59.167
Das macht dann eben die gesamte API ziemlich unerwartet. Ich habe gedacht,

00:56:59.167 --> 00:57:02.487
vielleicht, wenn man so bei deinem Whisper-Beispiel eben sagt,

00:57:03.307 --> 00:57:06.887
im Grunde ist die API-Oberfläche immer gleich, die sind nur unterschiedlich

00:57:06.887 --> 00:57:09.141
groß und dann kann ich irgendwie,

00:57:09.967 --> 00:57:15.077
alle drei Hashes übergeben und kriege dann quasi den ersten Match zurück aus

00:57:15.077 --> 00:57:18.580
der Liste und kann damit arbeiten, so dachte ich.

00:57:19.103 --> 00:57:23.357
Aber letztendlich, da hast du dann bessere Primitieren, also Promise Race oder

00:57:23.357 --> 00:57:26.330
Promise All Settled oder was auch immer der Sinn ergibt für die jeweilige App.

00:57:26.777 --> 00:57:31.027
Und ja, auf diese Art und Weise lässt sich das dann eben sehr viel einfacher

00:57:31.027 --> 00:57:35.987
gestalten. Und wie gesagt, das Ganze wurde auch von vornherein modelliert,

00:57:35.987 --> 00:57:40.046
basierend auf der OPFS API und die hat eben auch nur eine Single-Auffrage.

00:57:41.193 --> 00:57:45.657
Ja, genau. Und da gab es dann eben vor, das war im Juni, glaube ich,

00:57:46.781 --> 00:57:49.791
Spec-Änderung oder Explainer-Änderung, wo wir dann gesagt haben,

00:57:49.791 --> 00:57:53.941
okay, wir schmeißen die Pluralform aus und übernehmen jetzt nur noch die Singularform.

00:57:54.475 --> 00:57:58.581
Vorteil, wie gesagt, über die Extension dann ist, wir machen damit niemand kaputt.

00:57:58.581 --> 00:58:01.631
Über die Extension habe ich dann quasi Code drin, der sagt, okay,

00:58:01.631 --> 00:58:04.501
du verwendest das die Deplicated Pluralform.

00:58:04.501 --> 00:58:08.889
Ähm, ich draht dir das intern um und mach dann eben verschiedene Singular-Calls draus,

00:58:09.469 --> 00:58:12.951
ähm, und dann, ja, kannst du eben sagen, okay, alle, die das bisher verwendet

00:58:12.951 --> 00:58:17.231
haben, ähm, sollen ihren Code entsprechend anpassen, ähm, hatte vor kurzem auch

00:58:17.231 --> 00:58:21.881
ein PR offen bei Transformers, wo ich das eben, äh, direkt quasi implementiert

00:58:21.881 --> 00:58:23.657
hab noch, und, äh, gefixt habe,

00:58:24.272 --> 00:58:28.121
und, genau, auf diese Art und Weise haben wir dann eben so ein Origin-Trial

00:58:28.121 --> 00:58:31.283
vor dem Origin-Trial, und, äh, in Q3 soll es dann losgehen,

00:58:32.229 --> 00:58:36.751
dass es, äh, den ersten echten testbaren Code irgendwann mal in Cron selber dann geben wird.

00:58:36.751 --> 00:58:40.415
Also natürlich ganz klassisch, so Cron Canary hinter einer Flag und so weiter.

00:58:40.920 --> 00:58:45.251
Und irgendwann, wenn es dann ein bisschen stabiler wird, da wird es dann den

00:58:45.251 --> 00:58:49.673
klassischen Original Trial und so weiter geben und ja, F-Trial vorher noch.

00:58:50.341 --> 00:58:54.351
Genau. Aber bisher über die Extension kannst du eben alles schon testen,

00:58:54.351 --> 00:58:57.458
wie es funktionieren wird, inklusive der deklarativen Varianten.

00:58:58.973 --> 00:59:04.087
Ist dann eigentlich ziemlich cool. Macht man Spaß, daran zu arbeiten. Mhm.

00:59:06.501 --> 00:59:11.011
Dann habe ich noch eine Frage und zwar, du hast ja, wenn man Origins-Sternchen

00:59:11.011 --> 00:59:13.816
setzt, dann ist man ja so,

00:59:16.092 --> 00:59:20.661
dann hat man ja die Spendierhosen an und sagt so, die ganze Welt kann diese

00:59:20.661 --> 00:59:25.921
Library oder genau die ganze Welt, wenn sie denn mit dem Browser mal auf unserer

00:59:25.921 --> 00:59:28.601
Seite war, kann dann auf einer anderen Seite diese Library benutzen.

00:59:28.601 --> 00:59:33.541
Ähm, wer würde das machen, also,

00:59:34.255 --> 00:59:37.941
äh, würden das, würden da normale EntwicklerInnen dran denken,

00:59:38.341 --> 00:59:42.527
also, dass sie sagen, immer wenn, äh, wenn ich React einbinde,

00:59:42.840 --> 00:59:47.966
dann äh, setze ich das, eben packe ich das da mit rein, also, wer sind dann die,

00:59:48.506 --> 00:59:53.411
die gebenden, die natürlich ja auch von den Browsern besucht werden müssen,

00:59:53.550 --> 00:59:57.329
also, damit das im Cross-Origin Storage landet, also, wer das dann,

00:59:57.962 --> 01:00:02.431
Google, weil die so viel Präsenzen haben und so die Großen, wo fast alle Leute

01:00:02.431 --> 01:00:05.062
eben immer vorbeisurfen. Weißt du da was?

01:00:06.223 --> 01:00:09.543
Die Idee wäre, du machst das, wenn du eine realistische Erwartung hast,

01:00:09.543 --> 01:00:13.993
dass deine Ressource von jemand anderem schon verwendet werden würde,

01:00:13.993 --> 01:00:15.366
also du auch profitieren könntest.

01:00:15.976 --> 01:00:19.933
Also das ist so ein bisschen wie wenn du in die Bar gehst, jeder zahlt mal eine

01:00:19.933 --> 01:00:24.833
Runde, du weißt, okay, diesmal trifft es mich, ich mache die Ressource in den

01:00:24.833 --> 01:00:27.953
Kostkash rein, aber nächstes Mal muss ich dann die Runde nicht bezahlen,

01:00:27.953 --> 01:00:28.827
weil jemand anders bezahlt.

01:00:30.223 --> 01:00:33.553
In vielen Fällen wird dir aber diese Entscheidung direkt abgenommen,

01:00:33.553 --> 01:00:37.543
weil, wie ich schon erinnert hatte ganz am Anfang, wir arbeiten auch direkt

01:00:37.543 --> 01:00:39.456
mit Nuxt und Next und so weiter zusammen,

01:00:40.507 --> 01:00:44.245
dass das eben quasi dann direkt auf deine Meta-Framework schon passiert und

01:00:44.582 --> 01:00:52.262
dann Nuxt schaut, okay, wir machen irgendwie View und View keine Ahnung was in unser Bundle rein.

01:00:52.715 --> 01:00:57.383
Wir kümmern uns um das gesamte Wandling und das kannst du heute auch schon testen.

01:00:57.383 --> 01:01:03.477
Es gibt ein Beat Plug-in Cross-Origin Storage, das hat der Daniel Rowe entwickelt,

01:01:03.982 --> 01:01:08.852
wo du eben heute schon über deine Nuxt-App testen kannst, wie wird das funktionieren.

01:01:09.323 --> 01:01:12.233
Und wie gesagt, alles pro bestehende Anzement, da geht nichts kaputt,

01:01:12.233 --> 01:01:16.263
wenn jetzt der Benutzer COS nicht aktiviert hat, weil die Extension nicht aktiviert

01:01:16.263 --> 01:01:19.899
ist, oder einfach in Zukunft, wenn das im Browser nativ landet,

01:01:20.299 --> 01:01:22.132
vielleicht der Browser das noch nicht unterstützt,

01:01:23.329 --> 01:01:26.113
geht nichts kaputt, du machst das im Zweifelsfall einfach besser,

01:01:26.113 --> 01:01:27.793
aber du machst das nie schlechter.

01:01:27.793 --> 01:01:31.937
Und die Ressourcen, die dann eben benötigt werden, die werden runtergeladen so oder so.

01:01:32.338 --> 01:01:35.362
Also sprich, in vielen Fällen wird dir das Framework, das du verwendest,

01:01:35.820 --> 01:01:39.163
die Entscheidung schon abnehmen. Das ist dann halt einfach Teil davon,

01:01:39.163 --> 01:01:41.596
wenn du eine neue Next-App erstellst oder was auch immer.

01:01:42.885 --> 01:01:46.403
Genau, und wenn du das alles von Hand kloppelst, bin ich auch großer Fan von,

01:01:47.436 --> 01:01:50.810
Mache ich auch alles am liebsten selber. Dann ist das halt jedes Mal so ein

01:01:50.810 --> 01:01:54.970
Judgment-Call, wo du sagst, okay, ist das realistisch, dass jemand diese Ressource

01:01:54.970 --> 01:01:57.042
verwendet? Dann gucke ich im Costcash.

01:01:58.395 --> 01:02:03.092
Du würdest natürlich dem Costcash nicht zwämmen mit was auch immer deinem eigenen Logo oder,

01:02:04.201 --> 01:02:08.040
es gibt natürlich so proprietäre Ressourcen, also Fonts ist immer ein klassisches

01:02:08.040 --> 01:02:12.910
Beispiel, wo du sagst, ich bin Publisher, wir haben unsere Corporate-Font und

01:02:12.910 --> 01:02:16.959
die wird verwendet auf unseren drei Websites, die wir haben und vielleicht noch der Marketing-Site.

01:02:17.988 --> 01:02:20.960
Da profitierst du dann natürlich von Kurs, aber da wirst du dann auch sagen,

01:02:20.960 --> 01:02:25.114
okay, realistisch gesehen weiß ich eben genau, auf welchen Origins das auftritt

01:02:25.456 --> 01:02:26.803
und ich lese die direkt entsprechend auch.

01:02:28.040 --> 01:02:31.314
Das Ganze ist kein Geheim, das ist so ein Hash.

01:02:31.883 --> 01:02:36.240
Wer die Ressource kennt, der kann den Hash berechnen. Also das ist nicht irgendwie

01:02:36.240 --> 01:02:37.409
so ein Sicherheitsmechanismus.

01:02:38.431 --> 01:02:41.580
Die Visibility von einer Ressource kann auch upgegradet werden,

01:02:41.580 --> 01:02:47.579
also wenn ich jetzt weiß irgendwie Sheps Newsmag verwendet eben die Shep Tooltripe Font,

01:02:48.560 --> 01:02:51.800
dann kann ich eben diese Ressource auch runterladen und auf Tom's Sketchy Server

01:02:51.800 --> 01:02:55.898
legen ob das jetzt legal ist oder nicht dahingestellt und dann könnte ich eben

01:02:56.084 --> 01:02:57.982
diese Ressource, die ich von dir bekommen habe,

01:02:58.900 --> 01:03:04.361
auch in meinen CrossCache legen und dann sagen, das geht jetzt auf Tom's Sketchy Server .com.

01:03:04.901 --> 01:03:09.050
Also das Ganze ist kein Sicherheitsmechanismus, ähm, intern wird dann eben einfach

01:03:09.050 --> 01:03:15.873
nur, ähm, der Browser sagen, okay, ähm, der Hash abc1.i, was jetzt Scherz Code Webfront wäre, ähm,

01:03:16.639 --> 01:03:21.647
Wird jetzt ursprünglich verwendet von Chefs Origin und von Chefs Marketing Site

01:03:21.984 --> 01:03:23.917
und eben auch von Tom's Sketchy Server.

01:03:25.757 --> 01:03:29.633
Wenn ich diese Ressource jetzt aber quasi deren Visibility erweitere,

01:03:29.633 --> 01:03:34.863
also sprich, die halt neu jetzt auf Tom's Sketchy Server auch verfügbar machen

01:03:34.863 --> 01:03:38.383
möchte, dann muss ich die Ressource trotzdem nochmal selber schreiben.

01:03:38.383 --> 01:03:42.000
Also ich muss die Ressource herunterladen und dann in den CrossCache nochmal aktiv schreiben.

01:03:42.702 --> 01:03:47.023
Der Grund ist, dass eben dann auch auf dieser Fingerprinting-Attack-Vector oder

01:03:47.023 --> 01:03:51.043
Cross-Site-Leak-Vector wegfällt, weil dann kann ich eben nicht mehr wissen,

01:03:51.683 --> 01:03:55.653
war der Benutzer jetzt auf einer von Sharp-Seiten oder war der Benutzer auf

01:03:55.653 --> 01:03:58.499
meiner eigenen Seite und dadurch fällt das eben dann weg.

01:04:00.368 --> 01:04:05.987
Und diese Zugangsliste, also sozusagen diese gemeinsam von Vendoren gepflegte

01:04:05.987 --> 01:04:13.717
Liste, die kommt aber nur zum Einsatz bei quasi Wildcard-Origin-Angaben, oder ist das so?

01:04:14.057 --> 01:04:20.597
Weil sonst könnte ich ja teilweise eben genauso meine kleine Mini-Ressource,

01:04:21.657 --> 01:04:26.647
die aber nur ich, aber auf mehreren Origins benötige, könnte ich ja dann gar

01:04:26.647 --> 01:04:28.614
nicht zum Fliegen bringen.

01:04:30.677 --> 01:04:34.807
Wenn der sozusagen immer einschreiten würde, weil dann diese Ressource ja gar

01:04:34.807 --> 01:04:37.597
nicht so populär ist, dass sie es auf diese Liste schafft.

01:04:40.009 --> 01:04:43.357
Aber das Ganze kann natürlich dann noch passieren. Also du kannst jetzt anfangen

01:04:43.357 --> 01:04:48.322
als unpopuläres Framework und wenn du dann irgendwann mal einfach organisch

01:04:48.734 --> 01:04:53.267
über NPM oder über CDNs oder was auch immer es auf die populäre Liste geschafft hast,

01:04:53.767 --> 01:04:56.199
dann wird das quasi einfach direkt abgegradet.

01:04:56.877 --> 01:05:01.997
Dann kann uns irgendjemand anderes sagen, ich lege die Ressource in den Costcash

01:05:01.997 --> 01:05:04.488
mit Sternchen, weil inzwischen ist sie populär geworden.

01:05:05.150 --> 01:05:08.107
Dann würdest du selbst aber auch profitieren davon, weil du hast halt ursprünglich

01:05:08.107 --> 01:05:11.877
die Ressource mit deiner eigenen Liste von Ressourcen.

01:05:12.777 --> 01:05:17.277
Also selbst wenn meine Origins sozusagen eingeschränkter sind oder waren beim

01:05:17.277 --> 01:05:21.397
Reinschreiben, genau, ist es dann beim Konsumieren egal.

01:05:21.507 --> 01:05:24.712
Also dann bekomme ich die, wenn sie eben auch...

01:05:26.767 --> 01:05:31.029
Und wir haben auch über die Public Hashlist so eine manuelle Funktion vorgesehen,

01:05:31.029 --> 01:05:32.548
also dass man eben auch sagt,

01:05:33.077 --> 01:05:36.909
es gibt jetzt eine manuelle Variante, wo man eben sagt,

01:05:37.409 --> 01:05:41.829
ich weiß, ich werde nie populär sein, aber aus irgendeinem Grund werde ich halt,

01:05:42.169 --> 01:05:45.047
also nie populär im Sinne von, ich werde es nie auf eine dieser Listen schaffen,

01:05:45.354 --> 01:05:48.506
aber ich bin trotzdem irgendwie populär, ich habe eine Motivation, warum.

01:05:49.679 --> 01:05:52.529
Dann kannst du jetzt eben auch sagen, okay, also sagen dir was auch immer,

01:05:53.269 --> 01:05:59.599
es gibt Covid-27, ja, also, wo alle eine Corona-Erkunde laden müssen und das

01:05:59.599 --> 01:06:01.649
wäre dann zum Beispiel so ein konstituierter Fall, wo man sagt,

01:06:01.649 --> 01:06:05.299
okay, da wollen wir jetzt nicht warten, bis irgendwie das organisch auf irgendwelche

01:06:05.299 --> 01:06:06.235
Listen es geschafft hat.

01:06:06.630 --> 01:06:12.305
Es gibt dann so eine neutrale Governance innerhalb der Watt Working Group,

01:06:12.775 --> 01:06:17.029
wo man halt sagt, okay, das ergibt Sinn, lass uns diese Liste quasi manuell

01:06:17.029 --> 01:06:18.649
auf die Public Hash List üben.

01:06:19.131 --> 01:06:23.468
Ich sollte vielleicht noch erwähnen, die Public Hashlist, das Ganze ist bisher noch eine Idee,

01:06:24.349 --> 01:06:30.269
das wurde noch nicht mit den anderen Bendoen quasi groß geteilt, es wurde so informell,

01:06:31.209 --> 01:06:38.149
im Juni geteilt auf der, es gab bei Egalia das Web Engines Hackfest,

01:06:38.149 --> 01:06:42.209
da wurde diese Idee so ein bisschen geflootet, aber es gab jetzt noch keinen formalen,

01:06:42.849 --> 01:06:47.359
Vorschlag, also was wir so bisher diskutiert haben, das ist hauptsächlich ein

01:06:47.359 --> 01:06:50.689
bisschen intern, was wir uns überlegt hatten, was rumziehen könnte und,

01:06:51.413 --> 01:06:53.108
wo so ein bisschen von anderen Mentoren,

01:06:53.892 --> 01:06:55.969
vorsichtige Zustimmung gehört hatten.

01:06:55.969 --> 01:06:59.749
Aber es ist noch nicht offiziell irgendwas entschieden hier.

01:07:01.369 --> 01:07:05.682
Vermutlich dann im Oktober, glaube ich, genau im Oktober ist der TPEC in Dublin.

01:07:06.649 --> 01:07:11.119
Da wird es dann vermutlich einen etwas größeren Themenkomplex geben,

01:07:11.119 --> 01:07:14.724
wo das ganze Thema dann Cross-Origin-Storage diskutiert wird.

01:07:17.858 --> 01:07:21.908
Okay, das heißt also Augen aufhalten, so um Oktober rum, ob da,

01:07:22.308 --> 01:07:27.548
was da passiert, da kann es dann auch sein, dass wenn man dann die Position

01:07:27.548 --> 01:07:31.088
der anderen Vendoren endlich mal hat, dass das dann noch,

01:07:32.336 --> 01:07:34.071
das Ganze umdesignt wird.

01:07:35.418 --> 01:07:40.068
Genau, also eine Mozilla-Position gibt es schon als Stub, also direkt nach dem

01:07:40.068 --> 01:07:44.648
Web-Engine-Hackfest hat das Kagami angelegt von Mozilla, können wir vielleicht

01:07:44.648 --> 01:07:45.780
in die Show-Notes auch übernehmen.

01:07:46.748 --> 01:07:49.928
Ich glaube, die beste Liste ist die Awesome Gross Origin Storage,

01:07:50.428 --> 01:07:53.884
weil da werde ich halt alles dann direkt aktualisieren, sobald sich da was tut.

01:07:54.928 --> 01:07:58.868
Wir werden jetzt auf bald eine WebKit-Position anfragen und dann kann man sich

01:07:58.868 --> 01:08:03.120
einfach auf diese GitHub-Misches subscriben und wenn dann irgendwas passiert,

01:08:03.532 --> 01:08:05.268
bekommt man Bescheid, was da los ist.

01:08:05.268 --> 01:08:10.448
Und dann natürlich der ganze klassische wir wollen eine neue Browser-API-Ship-Prozess,

01:08:10.448 --> 01:08:16.214
also sprich das Tag-Review und ja, dann den ganzen Origin-Trials und so weiter, was da kommen wird.

01:08:16.598 --> 01:08:21.688
Also, da ist noch ein bisschen, ja, Zukunftsmusik, die dann zu komponieren ist,

01:08:21.688 --> 01:08:24.968
aber, genau, auch heute, wie gesagt, schon kann man das alles testen,

01:08:26.251 --> 01:08:30.328
über die Browser-Extension und die Idee ist halt dann auch, diese Browser-Extension,

01:08:30.728 --> 01:08:33.746
sollte es irgendwelche API-Changes geben, wird dann halt angepasst,

01:08:34.100 --> 01:08:36.308
sodass jeder Code, der heute geschrieben ist,

01:08:36.808 --> 01:08:40.018
dann am Ende auch mit der finalen API funktionieren wird.

01:08:40.018 --> 01:08:43.188
Und die Extension, die ist so geschrieben, dass sie detected,

01:08:43.188 --> 01:08:47.578
gibt es Cross-Ordance, gibt es Cross-Origin-Storage und Browser nativ?

01:08:47.578 --> 01:08:49.355
Wenn ja, dann mache ich einfach gar nichts.

01:08:50.248 --> 01:08:56.019
Und wenn nein, dann arbeite ich eben und injecte meinen Polyfill. Ja.

01:08:59.108 --> 01:09:02.602
Alles klar. Peter, hast du noch Gedanken?

01:09:04.817 --> 01:09:07.417
Ich habe Gedanken, aber ich glaube, keine, die zu diesem Thema so richtig passen.

01:09:08.917 --> 01:09:12.097
Ich fühle mich auf jeden Fall jetzt ziemlich gut informiert.

01:09:12.097 --> 01:09:16.817
Und ich werde testen. Ja, ich habe auf jeden Fall alles hier,

01:09:17.317 --> 01:09:20.387
alle möglichen Themen und Tabs, über die wir gesprochen haben,

01:09:20.387 --> 01:09:25.682
die habe ich hier alle offen. Und die waren definitiv in die Shownotes.

01:09:27.266 --> 01:09:28.178
Genau, also ...

01:09:29.067 --> 01:09:34.168
Lieber der Aufruf an die Hörerinnen und Hörer. Wenn das ein Thema ist,

01:09:35.308 --> 01:09:39.143
das ihr euch interessiert, dann bringt euch gerne jetzt schon ein.

01:09:39.562 --> 01:09:42.093
Also früher ist ja immer besser als später.

01:09:43.649 --> 01:09:47.463
Genau, und was euch an Gedanken kommt und probiert es aus.

01:09:49.088 --> 01:09:52.780
Und dann schauen wir mal, wie es weitergeht bei dem Ding.

01:09:54.104 --> 01:09:57.868
Genau, also auf jeden Fall testen, ausprobieren. Das Ganze ist nicht auf AI,

01:09:57.868 --> 01:10:01.748
nur spezifiziert. Also wenn ihr eine Flutter-App programmiert,

01:10:02.348 --> 01:10:04.498
dann geht das von selber.

01:10:04.615 --> 01:10:11.000
Flutter, das SDK, wird dann euch eben automatisch einopten in das ganze Thema.

01:10:11.868 --> 01:10:16.228
Wenn ihr über WebAssembly mit ihrem Script um was bastelt, da ist das noch ein

01:10:16.228 --> 01:10:19.648
Experiment der Flag. Also da muss man eine Art in den Docs schauen,

01:10:20.148 --> 01:10:22.907
Cross-Origin-Storage aktivieren und so weiter als Compile-Flag.

01:10:23.289 --> 01:10:26.958
Aber auch dann macht der interne, die interne Toolchain alles für euch.

01:10:28.028 --> 01:10:32.848
Das ganze JavaScript, BlueCode und Wumpf. Also, wenn jetzt eine populäre oder

01:10:32.848 --> 01:10:36.491
vielleicht auch eine nicht populäre WebAssembly Lib bastelt,

01:10:36.809 --> 01:10:40.919
gerne ausprobieren und dann auch die ganzen deklarativen Varianten mal testen.

01:10:41.389 --> 01:10:43.788
Ist, glaube ich, ein ziemlich großer Hebel auch da insgesamt,

01:10:43.788 --> 01:10:48.348
wenn man jetzt so globalen Internet-Traffic sich anguckt,

01:10:49.231 --> 01:10:53.438
ja, wie viele unnötige Ressourcen eigentlich verschoben werden,

01:10:53.438 --> 01:10:57.753
die wir schon alle irgendwo haben im Rahmen von Privacy.

01:10:59.200 --> 01:11:02.588
Kann man, glaube ich, schon dann irgendwann, hoffentlich, wenn die API ausrollt,

01:11:03.209 --> 01:11:07.330
so ein bisschen vielleicht einen kleinen Einbruch im globalen Internet-Traffic sehen.

01:11:08.248 --> 01:11:12.138
Hugging-Face, die freuen sich da natürlich auch, wenn die Leute nicht jedes

01:11:12.138 --> 01:11:18.267
Mal Gemma 4 runterladen von ihrem Hub, sondern halt das ganze über Kost geliefert wird.

01:11:19.603 --> 01:11:23.827
Ja, das macht Sinn. Ich meine, es ist ja auch ein Hemmnis, die großen Downloads

01:11:23.827 --> 01:11:29.687
für die Adoptionsrate bestimmter Dinge, die das dann möchte,

01:11:29.687 --> 01:11:33.047
vermeidet man das vielleicht eher, sowas einzubinden.

01:11:34.963 --> 01:11:43.189
Ja, cool. Danke, dass du dir die Zeit genommen hast und zu Gast warst bei uns.

01:11:43.311 --> 01:11:45.647
Das ist immer sehr interessant. Ja, sehr gerne. Vielen Dank für die Fragen.

01:11:47.275 --> 01:11:51.187
Wie gesagt, wenn jemand Feedback hat, Gerne über die bekannten Kanäle,

01:11:51.707 --> 01:11:53.677
ist ja wahrscheinlich dann alles Teil der Show Notes.

01:11:54.827 --> 01:11:59.277
Macht Issues auf, probiert das aus, testet mal die Extensions.

01:11:59.277 --> 01:12:05.187
Und findet Security Holes, ich glaube, das ist ja glaube ich so das größte Ding.

01:12:05.309 --> 01:12:09.197
Also da werden natürlich einige andere auch gucken, aber ich glaube,

01:12:09.197 --> 01:12:13.427
das ist ja so, dass ja der Grundforms eben die anderen Sachen nicht mehr gab

01:12:13.427 --> 01:12:16.937
vorher und das soll ja hier dann nicht mehr passieren.

01:12:18.997 --> 01:12:24.464
Ja, super. Dann vielen Dank. Danke auch fürs Zuhören bis hierhin.

01:12:25.404 --> 01:12:29.114
Wenn ihr die Folge gut fandet, dann wisst ihr, wie ihr das kunden könnt.

01:12:29.114 --> 01:12:31.861
Genau, unsere Kontaktkanäle sind alle auf unserer Webseite.

01:12:32.459 --> 01:12:37.533
Natürlich werden wir auch Toms Kontaktkanäle verlinken, wie Tom schon selber gesagt hat.

01:12:39.373 --> 01:12:43.374
Dann hören wir uns nächste Woche wieder. Ich weiß das Thema gerade nicht,

01:12:43.374 --> 01:12:45.874
aber es wird bestimmt super. Genau.

01:12:48.318 --> 01:12:50.864
Wann ist es das jemals nicht gewesen? Wann ist es das jemals nicht gewesen?

01:12:50.864 --> 01:12:53.814
Moment, ich kann es aber auch gerne nochmal hier. Warte, hier,

01:12:53.814 --> 01:12:55.364
da. Was ist nicht so dran?

01:12:58.326 --> 01:13:03.634
Ah, ja, das wird so ein bisschen, vielleicht wird das so ein bisschen juicy.

01:13:03.634 --> 01:13:08.124
Es geht um die Akquisition von Void Zero durch,

01:13:10.224 --> 01:13:14.834
Cloudflare. Genau, also eher ein, kein so technisches Thema,

01:13:14.834 --> 01:13:20.448
sondern eher ein, wie ist das so und wie wird es in Zukunft sein, Thema.

01:13:21.168 --> 01:13:23.574
Ja komm, aber wenigstens geht es da um Sachen, die tatsächlich passiert sind

01:13:23.574 --> 01:13:26.914
und wirklich existieren und nicht um APIs, die vielleicht eines Tages mal angefangen

01:13:26.914 --> 01:13:28.134
werden können, zu implementieren.

01:13:28.476 --> 01:13:31.483
Ah, okay, also was Handfestes.

01:13:32.533 --> 01:13:35.604
So, Dinge, die wirklich existieren und die irgendwen interessieren.

01:13:35.604 --> 01:13:39.784
Naja, aber wir heißen ja auch Working Draft und das ist ja, genau, da ist das Programm.

01:13:41.444 --> 01:13:44.904
Und ich finde das immer gut. Mir macht das Spaß.

01:13:46.302 --> 01:13:52.386
Dankeschön, Tom und ja, bis bald Bis bald, tschüssi, ciao.