What is Cross-Origin Storage? - Thomas Steiner

On this edition of Coffee with Developers we welcome back Thomas Steiner, Developer Relations Engineer at Google, to tell us all about the cross-origin storage proposal, that would let different websites share a single cache for large files using a cryptographic content hash.

----------------------------------------
Welcome to WeAreDevelopers, the #1 developer community in Europe!
This is your one-stop destination for the latest tech insights, tutorials, and career advice to elevate your developer career.

Stay updated Dev Digest, with our weekly newsletter featuring the most recent tech trends, career guidance, and original content crafted by developers, for developers. Subscribe now

Interested in advancing your career? Browse through our job board featuring over 190,000 jobs. Unlock job opportunities with a free developer profile

Don't miss out on the annual highlight of every developer's calendar - the WeAreDevelopers World Congress. Network with 15,000 peers and learn from over 500 speakers.  Secure your spot and save 10% with "wearedevs_yt"

#CareerInTech #Tech #ProgrammingTutorials #DevRel #CodingTools #TechJobs #TechTalks #DeveloperSkill...

Transcript

Copy Transcript Copied

SPEAKER_00 0:01

Hello and welcome to another edition of Coffee with Developers. I've got a friend here again who's been on the show a few times on the live show as well. Please welcome Thomas Steiner, who is a developer relations engineer at Google. How are you doing today, Thomas?

SPEAKER_01 0:15

Hello, I'm doing great.

SPEAKER_00 0:16

How are you? I'm not bad. We both complained that the weather the summer is almost over after we complained that it was too hot for a long time. And we're both German, so if we don't complain, we're unhappy. So I think that's the main thing.

SPEAKER_01 0:27

Well, the core difference is you live in Berlin, I live in Spain.

SPEAKER_00 0:30

So my summer is still technically not over, but like now, Thomas, you pinked me that you have something cool and new happening to us. You've been known to me as somebody who works on web platform things that actually allow the web platform to go beyond where the web was going before. Like you were part of Project Fugu, and you actually allowed browsers to access things that they weren't able to access before. Now, today you said that you have something new called cross-origin storage or cos. What's that about?

SPEAKER_01 0:59

Well, cross-origin storage solves one of the uh oldest problems in computer science, um, which is uh not naming things but caching. Um so we were both around for a long time, right? So we remember the age of uh the jQuery CDNs and so on, and um this super early promise of hey, let's just agree on the same CDN uh URL of jQuery and the same version, and then if we browse different websites that happen to use those same URLs, then we will get a cache benefit. And um, yeah, we will just have jQuery for free um when the first page has loaded it and the second page then uses it. In practice, it never was that easy just because there were so many jQuery-ish like CDNs around. So there was the Ajax, uh Google Ajax library, uh, there was a Microsoft um similar Ajax library um thing around. Um people, of course, wanted to self-host thing things. Um people didn't agree on the same version. So there was a lot of um churn essentially around um like yeah, actually agreeing on the same thing. And then, of course, bundles happened. So uh bundles really quickly um yeah entered the market, and uh people started realizing oh, um, from the entire jQuery, I'm only using um whatever 70%. So the other uh 30% I can just uh that code eliminate and uh move them away. And then of course bundles starting to actually mingle things together. So you had um jQuery and Lodash and your own vendor, um whatever is something code, and it got uh all mingled together in one big bundle, and then of course, uh this um ruined all of the caching immediately. And then also um privacy happened. So um in the uh old days when we still could have good things, um, people started realizing oh, um, there's a way how I can time an attack. So if I know that a certain page puts a certain resource on the cache, as an attacker, I can just request this uh resource and time and see how long did it take um for this resource to arrive. Um if it was short, it was cached. So I could say, um, let's see if uh Chris has something from uh whatever randombank.com in his cache. And if I know that uh the logo of randombank.com is in Chris's cache, I can with a certain probability say that Chris is likely a customer of uh randombank.com and uh has been there recently. Um of course that's upgrade. So uh pages um yeah, could sniff what was in other people's caches. So um browsers, all of them essentially started isolating their caches, which means um even if now you agreed on the exact same URL, exact same uh version number, um, it didn't work anymore because browsers just yeah, refused to give you access to something that was not the current pages uh caching context. So, long story short, um this is like part of the motivation, but then of course, um you mentioned uh I work on things that were previously not um possible on the web. And um, one of the things that we started having on the web is um Web AI. So um it is one thing if you don't have jQuery and you need to uh download it again, um, even if you have it already, but it's an entirely different thing if you work with AI applications, and those AI applications try to load a model like uh let's say the Whisper um audio uh transcription model, and um you use two different apps that would depend on the same model, but of course each of them has to download the model again, and um, it starts to become prohibitive relatively quickly, which is why we have seen a lot of web AI demos, but we've not seen that many um actual production rollouts with uh AI. Um, people might remember the last time I was on a show, this was uh I forgot when, a year ago maybe, um, when we talked about Web AI, um, but in the context of built-in AI. So one of the approaches to dealing with this problem is to just say, okay, so rather than having each page download its own model, we just put one model in the browser and um call it the built-in um browser uh model that you can just use from high-level JavaScript APIs. This works for many cases, but not for all of them. And um, people also want control. So people uh in some cases um need absolute control, they uh actually exactly want to know what is, for example, an embedding model that they use so that uh they can run embeddings on the server and on the client, and the same embeddings, whatever uh location they've been created at still work. So there's this, but then also there's things like uh web fonts. Like um, if you think uh in uh CJK languages, um, people need web fonts um that are um yeah very, very powerful. They have the full range of uh the glyphs um in CJK languages. You have uh emoji uh color fonts that are really big that a lot of pages need because like uh native uh emojis support sometimes isn't great. So, for example, on Windows um for a long time, I'm not sure if today still, but you had um instead of the flag emojis, you had like uh the named flag. So instead of the German flag, you had DE as a uh like icons, which just didn't look great. Um, so these kind of things. So people started uh to depend on um uh web fonts for that. So there's a whole range of things, like uh resources in general that uh people want, but they don't necessarily want to download. So if they have them, it's great, but like downloading them every single time can become expensive, um, like download-wise, storage-wise. Um, if you work in AI and you uh download, let's say Gemma 4, um one of Google's models, uh 2.5 gigabytes, I think, uh, in one of the typical web runnable uh quantizations, um you just end up with a browser profile that is full of cached resources that you already have several times if you work with several applications. And long, long story short, um, this is where then finally um the cross-origin storage API proposal comes in. The core idea is rather than addressing things by their URLs, so the jQuery uh URL kind of problem, we address things by their content hash. So if you have a resource, you can calculate the hash of that resource. And as long as the hash stays the same, it doesn't matter if you have downloaded it from my SketchGD server or Chris's official CDN or Microsoft's super, super highly official CDN, as long as the hashes match, um, you can be sure that the integrity of the resource is given. So this is the first thing that we sort of uh thought about. So it's a content address storage. Um, so wherever you got a resource from, as long as the hash matches, um, it can be shared. And um, cross-origin storage is also an API that has different entry points. So it's an imperative API, but also a declarative API. Um, imperative in a sense of um you can ask the browser, hey, browser, do you have in your cross-orig storage a resource with the hash ABC123? Um the browser will then look in its cost cache and say, yes, I have that, or it will say, No, I don't have it. Um, if you have it, great, because then you can just use it. Um, if not, you can download it from the network, just as you uh would do today. And then, of course, ideally, once you download it, uh put it in the cost cache for the next time for yourself, like your own uh usage, but also of course for other pages that you um yeah hope that will also use that resource. So it's a giving and a taking. So um the idea is really um if you put something in the cost cache, there needs to be a certain likelihood that other pages would use this um resource as well, or that you um could use it if some other page has put this into the cost cache. There's different um levels of sharing. So um you can think of like the easiest one, which is global share. So you put something and it's just there, like in the old days with the HTTP cache that was shared. Um, but then there's nuances in between, like you can say um we are, let's say, an office suit. So we have uh uh write.example.com, calc.example.com, and slides.example.com. And this office suit has a shared um AI model that uh they use, for example, for a proofreading. So I could say, okay, so this is my shared AI model. Um, I want to make this available for my three pages that I I know um use this resource. And when I say pages, that's actually origins. Um need to be precise with the terms here. Um so you can say, yeah, I'm sharing this resource with these three uh origins. And then um you can also um just not say anything. So if you um just put a resource in the cache, um, it will be shared for the same site resources, um, which is like a little bit more complex, but you can think of it um as the um all of the subdomains of a of a given um URL. So more or less that's the entire story. And then um I said this is the imperative API. There's also a declarative way of tapping into the cost um storage. And um, the idea there is um you today when you load a script, you put a script tag. Um, if you load a style sheet, you put a link um href uh pointing at the CSS resource. Um and the idea there is to just say um by adding an attribute, cross-origin storage, you opt those resources into taking part in your entire uh cross-ordin storage story. So you say um this is my um, let's say tailwind, and I know the tailwind version 123 has their hash ABC uh four five six, and um you put this information in the integrity um attribute on the link tag and in the cross-origin storage uh attribute, you put how you want to share this resource. So, like if a tailwind or something like that, it would be global. So you would put a star, um, which makes it available globally. And um, yeah, if the resource is found in the cost cache, it will be just used. And if it's not, it will be downloaded from the URL that you have given and then put in the cost cache. And then, of course, I said the integrity is part of this. So um, whatever URL you put there, it could be your own server-hosted, um, self-hosted uh server, it could be um a CDN of whatever tab or jQuery or whatever. Um, as long as the integrity matches, the uh hashes match that you um mentioned um is the one that you expect, and then the downloaded bytes have exactly that hash, you can be sure that um the resource is um the one that you actually expected. So that's more or less the story.

SPEAKER_00 11:10

I mean, it solves the problem also that CDNs going away or CDNs being uh domains expiring, people taking those over. I mean, we had that problem, I think, with one of the jQuery extensions kind of things, where then a malware distribution happened because people just pointed to a URL. Now, my question is uh I have a few questions. Uh the first one is like uh we do uh we do this by hash, that makes a total sense. That's what we did with BitTorrent as well. But who controls the hashes and who generates them? So how do you know that the hash that that actually you have right now is the one that has been uh has been the proper one, not a malware controlled one. Is there a centralized service or a W3C protocol where you can get the hashes from?

SPEAKER_01 11:54

So it depends. Um, if you want to use your own resources, of course, you control them, you can calculate the hashes yourself. Um, you can always calculate the hashes yourself, even for resources that you don't control. So you can um download something from a CDN and then just uh calculate the hash. Um ideally, the CDN already publishes uh the hash. If you think in the AI space, um most people get their models from Hugging Face. Hugging Face publishes all the um SHA 256 uh hashes alongside each of the model resources. Um ideally, um yeah, you just have the uh hashes already. Um if you think uh in the world of uh npm, each of the resources on npm um has a hash already. So there's uh JS Deliver, one of the um like on top CDNs, um, make available the hashes for all of the NPM resources. So um there's no central institution or something that would publish a hash because yeah, it wouldn't really make sense, and also everyone can just calculate the hashes themselves. So in the case of as I said AI, um I guess most people would trust the uh hash that is uh published by Hugging Face, but then even then something could go wrong on the way, like there could be a bit flip or something. Um but in the browser, the um API built into um the browser, like the cost um API, would still check the hash. So it would say I'm expecting a resource to arrive in the cost cache that has the uh hash ABC123. But if the um actual resource that comes down um through the wire, like after a fetch or something, is um presented with a different hash, it would then just refuse this resource and say, like, oh, there's a data um error, so that's a hash mismatch. I won't put that resource in the in the cost cache. Um one of the like, I guess, most popular cases of this um abuse scenario that you mentioned happening was I think polyfill.io. Um I think it came out of the Guardian or something, so some UK um publisher or maybe Financial Times, I'm not sure anymore. Um, but like they were taken over by I think some Chinese investor, and then this Chinese investor decided to just apart from delivering polyfills, also to deliver whatever tracking and abuse and stuff um software. So with this, um it would get noticed immediately. So um you would call the same URLs as always, but then all of a sudden something else would come back that is no longer um yeah, uh meeting the hash requirements, and um you would catch it in the other thing, of course, is then the storage on my device.

SPEAKER_00 14:26

Like, do I uh uh do I the but once I call the API, do I get to pick a folder, or is this something that happens in memory as part of the browser? Or uh and in what format is the data being stored? Is it just as files or is it in a SQLite database, or how do I how do I pick in my device where I want to store these things?

SPEAKER_01 14:45

So in the native browser implementation, um you don't do anything as a user, you just uh as a developer call the API, and then the browser just takes care of uh storing the file somewhere. So I guess the simplest implementation could be to just put it somewhere in your browser profile, um like application support, Chrome, Edge, whatever you have as your browser, somewhere deeply nested um in your browser uh browser profile. Um, but this is more uh an implementation detail. The browser could, for whatever reason, decide to put those into um blobs in an index DB or SQLite database, um whatever is cheapest. Um it's an implementation detail that you as a developer um don't need to be concerned with. Um you can try already some of the um like demo implementations um that I did. Um if you go to goo.gleslash cos-chromium, um you can download a special Chromium um build for Mac that has the API already um enabled and you can just test it locally. It even has DevTool support so you can inspect what is going on. Um this is an early prototype, it's not uh official at all. Um, but for just seeing how the API would work, um, it is very um useful already. Um like this is one thing, um, but then also um you mentioned how the data is stored. Yeah, again, this is something that each browser vendor can decide for themselves. Um, I think most of them will just do something that already is implemented. So um, I guess there are some code paths that you can share with, for example, the cache API, like the regular um SOS worker kind of cache API, um where you have similar um requirements, you need to store vlogs somewhere, um, files. There's the OPFS API. So I think um for many browsers, um, yeah, it will be not that many new things to invent if they decide to implement. Um, I just had my uh AI uh implement a whole bunch of uh yeah different browsers uh with this API. And um, like looking at the code that uh Claude at least generated, it was typically around um 45,000 lines of code. So not a massive, massive change um compared to uh like I don't know, other features that require super um substantial changes in the code base.

SPEAKER_00 16:59

Uh that of course brings me to storage limits and storage uh opportunities. I remember when we did local storage for the first time, and then we didn't set any limits in Firefox back then when I worked in Mozilla, and then there were scripts that basically flooded my hard drive with like two seconds. Um is there a quota API? Is there is there a way of knowing what can be stored and what can't be stored?

SPEAKER_01 17:20

So um the core idea is to just have the same logic as with uh the regular cache API. Um it should be impossible for one origin to flood your um cache. So there's like implementation limits uh in place where you can just say um this is um like most browsers do do it in a way that they uh don't look actually at the actual free disk space, but they um make up, for example, 10 gigabytes uh free disk space to avoid finger printing so that you don't work on the actual free disk space, but on this supposed disk uh space. And then um you just look at how much of this is already um occupied by other um resources like index db, cache API, whatever, and um you then get a share of this. So um again, there's nothing new invented. Um there should be no new attack vectors. Um, one attack vector, of course, that you might be wondering about uh uh about is wait, um, this entire timing attack. Um so if you can determine um there was a resource that is uh in someone's cache, how does this new proposal deal with it? And the response to that is um the so-called public hash list. So the idea of this is um we only allow you to share resources globally if those resources meet a popularity minimum threshold. So if you have something like React, that's on many, many pages, um, that's a very popular uh framework, or let's uh even uh today uh use jQuery, still the most popular framework of them all. Um it is a very popular framework. So um by looking at um your cache, you can find out yes, the user visited a site that has React or has jQuery or something, um, but like there's not much that you could derive from this. So there's no private information like before when I mentioned um your uh bank logo that someone in theory could put into the cost cache and make available globally, um, because the bank logo would not be a resource that is uh globally very popular, it would not be um yeah, it would not be shared um with everyone. So this is um one way of uh avoiding this attack, and then the other is um just to reduce the amounts of what we call probes. So uh a probe is when you ask the cost cache, hey, do you have the resource ABC? Um, two, three. And um, by just limiting the uh number of probes that you can make, um, you can avoid um having like uh what um what most people say uh 32 bits is enough to identify you uh on the internet. Um so by having a probe limit that is way beyond that, you can avoid um yeah having uh you exposed to this kind of attack where you say um this is something that uh you have in your cache and all and then you create a bit vector and hope for a 32 uh bit vector uh to then identify the person, um the browser will actively make it impossible to uh probe too many times.

SPEAKER_00 20:15

So uh who's on board with that one already? I mean, you have uh I posted here as well, you have a preview in Chrome, uh which is Chromium, which means probably Brave and Edge as well. Uh but uh is there any insight, is there any interest from Apple's side, from Firefox's side already as well, or is it just very early days on that?

SPEAKER_01 20:35

So it is definitely early days. Um there are um position senders position requests um for Apple and Mozilla. The Mozilla one was filed by a Mozilla employee, um, the other one was filed by uh by us by Chrome. Um who is on board with that API also is a lot of um partners that we work with. So um there's the Chrome status page for um the API, and on this Chrome status page we list um the partners that are interested already and have implemented. Um amongst them are Transformers.js, um, WebLLM and uh WLAMA, so in the AI space, all the big names essentially. Um, because of that for them, of course, this uh AI model um caching is a big, big uh prohibiting factor, limiting factor. Um internally, we have Light RT, uh LMJS, who is also working on adding support. So we have essentially the whole range of AI frameworks. Um, Flutter is another partner um internally at Google that has implemented the API. So if you have two Flutter applications, um, they both can share through COS the SKIA framework that Flutter applications use to render. And um in the WebAssembly space, we also um have the MScripten open source um team on board at Google, and they also have uh added support to MScripten. So if you um work on a WebAssembly package, you can opt in your build to um be cross-origin uh shareable. So I think that's also something that could be interesting for a lot of bigger packages like SQLite, like FFMHEC, all those big, big tools that people compile to WebAssembly and then use on like your video editors or any kind of local first database apps, for example. So there's a lot of ecosystem interest. And there's also someone from the like US data public space who has expressed interest in this API for big law databases that this person wants to work with. So there's a lot of interest from essentially all those spaces. Internally at Google, we also have the Google Fonts team. So they make uh the Google Fonts API available, and through this API you can download the Google Fonts directory of fonts. The big, big ones are, of course, the Noto emoji font that is really big but also really beautiful and yeah, makes your emoji look consistent on all the platforms. So there's a lot of interest uh from Google Fonts as well.

SPEAKER_00 23:06

You also have an extension here that actually allows you to play with that. How does that work? Does that simulate the storage in another way?

SPEAKER_01 23:14

Or I mean that there's extensions for all the uh major block browser platforms. So you can install it for Chrome, for uh Firefox, and for Safari. And then of course, when I say Chrome, this uh includes all of like Edge and Brave and uh all the other Chromiums. And um, the way this works is um that it injects the proposed API into each web page. So uh navigator.cross origin storage dot request uh file handle um would be the uh imperative API. It injects that uh into each pages um that you uh browse to, and then um it has a so-called um extension off-screen page, and this off-screen page does have a cache. Um, so internally it just uses this off-screen pages service worker uh cache. Um, but as a developer, you get exactly the um experience that you would get um from the final API, just um bundled into an extension. So um the idea is of course, um if there's any kind of changes to the API, which still might happen, it's early A's, um, we will reflect them in the extension. So if you work with the extension code against the extension um API surface, um, you will at some point, if the uh API changes, have to make some adjustments locally. But then once the API ships um in Chrome, hopefully, uh sometime in Q4. Um if you have coded against the extension, um, it should be just something that is uh a zero up for you. So no changes required. Um the extension would then just recognize oh, the browser already has the API natively, I don't do anything, so the extension becomes a no-op, and um you can uninstall the extension um if you want to um after the browser has gained native support.

SPEAKER_00 24:54

The last thing, of course, every time we came up with some storage bits were like uh uh um was it synchronous, was it asynchronous, what is the speed of it to load? Uh, I guess you didn't go for a service worker because you could have extended a service worker to do that as well, right?

SPEAKER_01 25:09

Um so the service worker cache, yes, to some extent, but then it doesn't mentally really super well fit the service worker model, um, because there's various ways um how you could feed into the cost cache. So um you could download from a resource, but you could also just make up your own um blobs from whatever local uh logic that you have. You could even imagine um, like a lot of people have downloaded uh AI models locally to OLAMA or something. So um you could even imagine having some sort of browser setting. You could say um I want to uh upload um with uh scare codes my local AI model that I already have from OLAMA into the cost cache, so that would not be a URL to begin with. Um so there's a lot of um nuances there where we said um it makes more sense to develop this as its own um like storage mechanism that is clearly from the start um content addressed. Um but then like there's of course all the different uh entry points. So I mentioned before there's uh the link and the script tag entry point um where you can just have regular HTML um for fonts. Um you have uh CSS font face declarations. Um, so you declare a font face, like at font face, and then you uh at some point need to declare the uh source of um yeah, where the font should come from. And this source it looks like a function, so it's uh it's a URL parenthesis, then you provide the actual URL. And then after that, you have space separated um request uh URL modifiers, and um one of them is integrity that's already there. Um so for just making sure that uh the font that you get back has actually the um hash that you expect it to have. Um but then with this new proposal, um you would also have a uh URL request modifier cross-orget storage that opts in this resource uh into cost. And then the final integration that we have will be for fetch, so just a regular uh fetch API, um, where you have a request init uh option. So um just like today, where you have um as a first parameter the URL, and then as a second, um you have an object, and one of those object fields would be cross-origin storage, again with all those uh separate uh options that I said before, like you could have star for global sharing, you could have um empty string for same-site sharing, and you could have an array of the origins that you want to uh share your resource with. Um, so yeah, in the background, um yeah, as I said, it might be even using some logic that is already there from OPFS, from the cache API or something, but like it's a separate thing as a storage mechanism, as brokehost.

SPEAKER_00 27:44

Now, uh, what would you want people to do to help you with that? Like you have an audience of millions here right now. What would what would make you happy if people play with it? Where can they give feedback? What kind of feedback are you looking for?

SPEAKER_01 27:57

So because the X Engine exists for all of the browsers, um definitely do try the API. Um there's an explainer um that we have that is uh pretty pretty comprehensive. It has a lot of examples that you can just hopefully copy and paste and um just work with it. Um there's some convenience functions that I have published uh on my GitHub around, for example, getting a resource and making sure this entire uh Sha hashing um is being resolved correctly for you. Um so try the API, give us feedback. If you see you as a developer can use this for your project, for your app, um definitely um on our GitHub there's a way to express support. So I can formally say, like, we are Project ABC, um, we publish this and that. Um, we have exactly this problem that costs would solve. Um, here is the numbers. Um, like I don't know, I'm making this up. So we are FFmpeg. Um not saying that FFmpeg does, we are FFmpegvasm, and we are being used on whatever these thousand pages, each of those thousand pages, sorry, origins, again, um the uh term somatic here, each of those thousand origins use the exact same copy of um WebAssembly, uh sorry, FFFMP sorry, FFMPEG, that's a hard word, um, to use uh for WebAssembly. And um, yeah, if this API existed, um this would help us a lot. So the idea there is really to demonstrate uh developer interest um with yeah, actual numbers that people can uh look at and say, yeah, uh as a browser vendor, if I'm considering this API over something else, um I can say, yeah, this does make sense for uh solving the use case. Um if you have any kind of feedback, of course, uh around the API shape, around um how things work, um definitely the GitHub is our uh place. Um once the code lands in uh Chromium, you can of course also file um implementation bugs. So if something is specified to do XYZ, but it actually does XYZ prime, um, you should tell us about this bug. So um, this is of course then once uh actual code lands. Um the first uh change lists, CL, um, are up. So if you're really interested, um I maintain um a list called uh uh awesome cross-origin storage, and on this list, awesome cross-origin storage, you will find um, for example, the umbrella bug. So if you are uh super eager to uh see every single thing that is moving around this API, you can um yeah, star the umbrella bug or even star one of the dependency bugs and see um how the um API progresses uh implementation-wise. But I the biggest thing today is try it out, um, make use of uh even just uh an application that already or an API that already has implemented um the um the API, so uh Transformers.js, as I mentioned before, like build an application with Transformers.js, enable um the flag in Transformers.js that opts you into using uh cross origin storage. Um nothing breaks. So from the start, this is uh conceived as a um progressive enhancement. So if you don't have the API, if you don't have the extension supported uh or installed, um if you use a completely different browser that um refuses to implement the API, which is always something that can happen, um, nothing should break. So you don't make it worse than it is today. Um, in the worst case, the person already has downloaded the Gemma 4 model and they just need to download it again. Um, but uh yeah, this is just how it is. Um you can make it better, um, but like you can't make it worse by using this APA.

SPEAKER_00 31:34

Excellent. Well, thanks, Thomas. This was once again an interesting thing. I'm gonna put an article around it as well once we have the recording here done and list to all the resources so people don't have to actually look at the banners that I put in there. And uh yeah, good luck with that. I think it's a uh it's a great opportunity to think about uh uh differently and the sizes that we want to store these days. Like, I mean, we we we we kind of gave up on CDNs for like things like jQuery because uh with HTTP2, it wasn't that much of an issue anymore. And people are not too worried about uh about long I mean performance has changed a lot because people take on a lot more things. I mean, you can turn you can turn your app if from a web app to an AI app just by renaming every loading into thinking and then making people wait that way. And we kind of got got used to that one. But it's a great opportunity to uh and I love that it's uh that it's a what uh uh uh WICG uh thing as well, and not just a uh a Google one, so that there's more people involved as well. And um, yeah, once again, innovating in public, and uh that's where people can take part in. And uh we need you to actually tell us about what you think about that. So take a look at the cross-origin storage bits and bobs that Thomas has talked about. And I want to thank you for uh bringing it up to me. So, any last words for people out there?

SPEAKER_01 32:57

Many one thing that I forgot. Um, one of the interesting integrations that we have is also Nuxt. So if you work uh with a Nuxt app, um you can also integrate um with the proposal from the start. So there's uh on Daniel Rose uh GitHub repo, there's a um a repo called um uh cross-original storage, and there's a beat plugin um that you can just enable with your Nuxt app. Um, so even if you don't build anything AI, and this was something that I super uh yeah emphasized um during the development, we shouldn't just solve this for AI, we should solve this for the general part. Um, like if you build a Nuxt app, uh definitely also just give this a try. Um, I think what you mentioned before, um, we gave up on uh CDNs and so on. Um this time, I hope we have a chance to get it right by working with the frameworks, with uh Nuxt and uh friends from the start. Um, yeah, we can get it right this time um so that uh the bundlers can actually be bundling uh aware of something like COS. Um so I think this is also something um that we can get uh right this time. So yeah, I think that's maybe the final word. Um thanks so much for having me here. And um, yeah, look forward to a lot of people testing.

SPEAKER_00 34:08

Well, enjoy Spain, I will enjoy Berlin, and it was great to have you once again. And uh um sadly enough, I guess you won't be in America because we're coming with the We Are Developers World Congress to San Jose at the end of the month, but I don't think that's on your list at the moment, is it?

SPEAKER_01 34:24

Uh not at the moment. I'm actually enjoying a travel-free September because my October and November will be crazy. But yeah, September is just me in my home office.

SPEAKER_00 34:34

Well, there will be lots of other people from Google and probably some of them that are involved with this as well that you can talk to. This was Coffee with Developers with Thomas Steiner once again, and uh we probably will have you again on the show. Thanks very much, and thanks for watching.

SPEAKER_01 34:48

Cheers.