Yves: I've not commented yet, but I have two issues. The first is the prefilled list. It may promote sites that you have a relationship first. The other issue is when you're sharing things and putting them in the cache, if you can check something is there, that gives you 1 bit of info. If you add 10 things to the cache (they could be small) then you have 10 bits of info. If it bypasses the restriction of cross-site sharing, but works in this way, there is still a perfect (if limited) channel for sharing info.

Brian: I left a comment. This is currently a Chrome-only feature. It's only enabled when you have 3pc because it doesn't make the situation any worse. TAG already has expressed an opinion that 3pc have to be removed, so entrenching them should not happen. I had other parts to my comment, but that's the most straightforward.

Yves: I saw the 3pc requirement, but if the spec evolved to work even if 3pc are not set, by using the hash-only checking, then it has the issue that I hightlighted, which is being able to share things bethween colluding sites that may check the same hashes from different origins.

Brian: I commented also that you'd have to specify so many things that aren't specified in order to make this work at all. It sounds like the performance gains from this in cases that are not the AI case are disappointing. I think you'd have to specify things to the degree that this would be a different proposal. I don't think it's possible to address these concerns.

Christian: The idea is that you'd have to show permission prompts if you want to access the cross-origin storage. If you really share data via caching cross origins and the prompts are turned off if 3pc are on, that part is only about the prompting. Good points and I will check out your comments.

Yves: Saw Christian's answer about 3p cookies. It's still doesn't address the fact that you can store things and use the presence to exchange data between site. Maybe having a fixed list, and not updateable, might be a good solution. Curating the list is even more important in that case.

Dan: There are some very different types of things proposed to be in here. Common libraries like React, or Google Fonts, might give very little information. Game engines, AI models, might give more information. The cross-origin thing is a legitimate concern. Explainer might address how AI models used by few people interact with libraries used by a lot. How can browsers limit the number of requests people make into the registry to limit the amount of information they can gather. This makes a lot of sense ... is there a core that would be possible? Chrome already does something like this with "cache sharing for pervasive resources". Can something like this be standardized, with better privacy guarantees?

Lola: How does this differ from shared storage access? https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API A way for cross-site content, in 3p content, to gain access to unpartitioned state that would be available in the 1p context.

Christian: Scope is different because this isn't about cookies and small information, or the iframe boundary, but about sharing large dependencies used by multiple sites across different contexts.

Lola: Storage Access wouldn't be able to be extended to accept bigger resources?

Christian: Not sure; please add it to the brainstorming comment.

Jeffrey: Storage Access gives a third-party iframe access to its first-party sotrage. If it has access to the same iframe as some other iframe, that is not shared. Cross-origin storage is meant to share somethign that is byte-identical across different origins. I think they're different enough to have separate APIs.

Brian: Things they're proposing to be able to do, are pretty different. Not just a JS API or an attribute. Here's how you can make a local proxy/cache and use it through script include, CSS, etc. A lot more dicey than some other things you could do.

Yves: cache with preemptive deduplication