-
Notifications
You must be signed in to change notification settings - Fork 13
2026 Cross‐Origin Storage (COS)
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/85
- URL: https://meet.jit.si/WEH2026-cos
- Slides: https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/edit?usp=sharing
Sometimes it'd be nice to share big resources (WASM modules, LLM weights, and so on), but it's not possible because caches are (for very good reasons) partitioned on all browsers (mainly avoid cross-site leakage).
https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/edit?usp=sharing
New block-storage in the browser. You access it by hash, but resource visibility can be restricted to origins (e.g., for proprietary resources). The API is similar to OPFS.
The API does not have a permission prompt, but the user agent could still fail/throw an error because of some other gate (popularity, etc...).
Also a declarative way (e.g., for fonts, directly in CSS, in the @font-face block).
This can be already tried/tested with an extension: goo.gle/cos-extension. It also has a polyfill for CSS.
There are some very popular resources that Chrome had to reduce its partitioning
The idea is that Chrome's list will likely be released with a permissive license, so that other browsers will be able to use it. However, the exact license is to be decided.
Q: Do you have any use cases that aren't covered by the declarative API? E.g., add options to fetch to work around this? Or JS imports? A: One is the CSS, also JS imports were considered. A non-mentioned use-case is when you need to use options. E.g., enabling/disabling features on models. If you already have the bigger version of the model, you don't need to download the smaller one.
Q: Who does maintain the popularity list? What are its criteria? Would this give some bias to frameworks that are already popular? A: The pervasive list from the slides is based on an HTTP archive query, Web almanac also had some analysis Some resources (e.g., AI models), might not make it to the popular list. Therefore, there will be exceptions or some list to handle such resources (e.g., there's a sort of agreement with hugging face). Anyway, the team is open for ideas to improve this.
Q: Is there a limit on the number of origins? Not having one could allow some attacks. A: Yes, user-agent should have some limits to prevent this. Order of magnitude could be tens or hundreds.
Q: Privacy mitigations? A: Your resource should be in an allowed list to be actually fetched (e.g., Hugging Face's allow list). Each browser could define lists with their own methodology. Sensitive browsers could keep isolation, and that won't be worse than today's web.
Q: (something about abusing the difference between the not allowed and the not found errors) A: The behavior is basically the same, so it's possible to move to a single error (maybe even a good idea!). (Filed https://github.com/WICG/cross-origin-storage/issues/62)
Q: What about adding some fake failures to exercise the else path, add noise, etc? A: It would be possible to add it. (Filed https://github.com/WICG/cross-origin-storage/issues/63)
Q: Disabling the API when third party cookies are disabled will only work with Chrome, as others already disable it A: Yes, acknowledged.
Q: This has OPFS-like APIs. What about future changes in OPFS? Or IDB? Would it make sense to open those existing storage mechanisms to cross-origin sharing? A: No, they serve different purposes and are isolated by origin for good reasons. They can be used together with COS, store your database in OPFS, but load the SQLite Wasm library from COS.