Chromium’s Cross-Origin Storage Prototype Could Make AI Web Apps Much Faster
The web can run an AI model locally. The awkward part is paying for the same download again and again.
Today, two web apps on different origins generally keep separate copies of their cached resources. That isolation is an important privacy boundary, but it becomes expensive when several products depend on the exact same model weights, WebAssembly runtime, game engine, font, or large JavaScript bundle. The user may already have the bytes on the device, yet another app still has to fetch and store them.
Chromium has now taken a concrete early step toward changing that. An August 18 intent to prototype puts Cross-Origin Storage on the browser engine’s development agenda. A freshly updated WICG draft specification describes how the browser could reuse one verified copy of a large file across multiple origins without turning its cache into a cross-site tracking system.
This is not a shipped Chrome feature. It is an experimental proposal moving into Chromium prototyping. But it targets a real distribution problem that is becoming more urgent as installable web apps take on heavier, more local workloads.
What Cross-Origin Storage actually does
Cross-Origin Storage, or COS, is designed as a content-addressed browser cache. Ordinary web caching typically starts from a URL. COS instead identifies a file by a cryptographic hash of its bytes. If two origins request a resource with the same hash, the browser knows they are asking for byte-for-byte identical content, even if each site would normally download it from a different URL.
The draft exposes the cache through navigator.crossOriginStorage.requestFileHandle(). An app supplies a known hash and asks for a file handle. If an eligible copy already exists, the browser can return it. If the lookup is unavailable or deliberately withheld, the app receives a miss and can fall back to its normal network request.
That fallback is important. COS is being designed as progressive enhancement, not as a new prerequisite for loading a web app. Products would still need a reliable network path, their existing service-worker strategy, and app-specific storage. The proposal does not replace the Cache API, IndexedDB, Origin Private File System, or the web app manifest.
It adds a narrower capability: reuse identical, unusually large resources without storing a separate copy for every origin.
Why this matters for installable AI web apps
Local AI changes the shape of a web application. The interface and application code may remain compact, while the model or runtime becomes the dominant download. That creates a first-run penalty, consumes device storage, and makes users wait before the product’s most valuable feature is ready.
Now imagine a user trying several installable AI tools: a writing assistant, an image utility, a transcription app, and a private document analyzer. If those apps rely on the same public model or WebAssembly runtime, origin-isolated storage can make the user retain multiple identical copies. Open-web distribution remains easy, but the underlying payload starts to resemble repeatedly downloading the same package.
COS could alter that equation. After one participating app has stored an eligible file, another participating origin could reuse the verified local copy when the browser permits it. That could reduce repeat onboarding time, bandwidth consumption, and disk duplication. It could also make links and web-app catalogs more competitive as distribution surfaces for heavyweight software: the next app might open with much less setup because a shared dependency is already present.
The biggest beneficiaries would not be ordinary sites with small bundles. They would be products built around large, stable, reusable assets:
- Local AI tools using public model weights or shared inference runtimes.
- Creative and engineering apps built on substantial WebAssembly modules.
- Browser games sharing engines, graphics libraries, or large common assets.
- Database and media tools using the same SQLite, codec, or processing runtime.
- Installable app ecosystems where several independent products intentionally build on a common open component.
The privacy problem is the product
A global cache sounds simple until one site can ask whether a particular file exists. Cache presence can reveal history. If a resource is strongly associated with a health service, political organization, or niche product, another site could probe for its hash and infer where the user may have been.
Modern cache partitioning exists partly to prevent that kind of cross-site signal. COS therefore cannot succeed by merely removing the partition.
The draft proposes several layers of control. Files are verified against their cryptographic hashes, preventing one origin from substituting different bytes under the same content identity. An app can keep a stored resource limited to the same site, allow a bounded list of origins, or request global availability. Developers cannot enumerate everything in the shared cache; they must already know the hash they want.
Globally shared entries face an additional gate. Their hashes must appear on a proposed Public Hash List, intended for resources common enough that confirming their presence should not reveal a meaningful piece of browsing history. The draft describes a k-anonymity-style popularity threshold and allows browsers to withhold some otherwise valid hits to make probing less dependable.
Those safeguards are not implementation details to clean up later. They determine whether a shared cache can exist without quietly reversing years of browser privacy work. Governance of the Public Hash List, its admission rules, browser consistency, eviction behavior, and user-facing storage controls will matter as much as raw performance.
What developers should do now
Production apps should not depend on COS yet. There is no stable cross-browser capability to target, and the WICG report explicitly remains an incubated proposal rather than a W3C Standard.
Teams building heavyweight web software can still use the proposal to test architectural assumptions:
- Separate large immutable assets from frequently changing application bundles. Content addressing works best when identical bytes remain identical across products and releases.
- Keep a network fallback. A lookup can miss because the file is absent, ineligible, evicted, or intentionally hidden by the browser.
- Do not abandon app-specific offline storage. A service worker and origin-bound cache still own the installed app’s shell, private data, update behavior, and offline reliability.
- Plan visible storage management. If a product asks users to retain large local models, users need understandable controls for inspecting and deleting them.
Founders and investors should read this less as an API launch and more as a signal about where browser capability is heading. The open web is trying to support software whose valuable payload may be far larger than its interface. Efficient distribution of those payloads is becoming a platform concern, not merely an optimization inside one app.
Que surveille IndApp ensuite
Four developments will show whether COS becomes infrastructure or remains an interesting prototype. First is a testable native Chromium implementation and a credible path toward an experiment or release milestone. Second is substantive feedback from WebKit and Mozilla; a shared cache delivers much less strategic value if every browser invents a different model.
Third is governance. The Public Hash List must be transparent, vendor-neutral, difficult to game, and responsive to new versions without becoming a privileged distribution channel. Fourth is developer ergonomics: build tools will need to produce trustworthy hashes, integrate reliable fallbacks, and explain cache behavior without forcing every product team to become a browser-storage specialist.
The payoff is worth watching. Installable web apps already have frictionless links, instant updates, and independence from store packaging. If browsers can safely let them reuse their heaviest public dependencies, the web gains something packaged platforms take for granted: download a shared building block once, then let more than one app benefit.
Pour aller plus loin
Actualités récentes
