3 ms·
So your setup is: outer.example userN.inner.example shared.example/resource Since, as you say, outer.example could load the shared resources
by jefftk 5y ago
So your setup is:
outer.example
userN.inner.example
shared.example/resource
Since, as you say, outer.example could load the shared resources and postMessage them into userN.inner.example, it does seem to me like there should be a way for outer.example and userN.inner.example to opt into letting userN.inner.example use the outer.example cache partition.
Have you considered raising a spec issue?
- derefr 5y agoI would think that the original intent of the origin cache sandboxing here, is to disallow different source origins from sharing a target origin, even if that target origin wants to be shared. Think "the target origin is an ad-tracking provider domain." I don't see any good way of enabling a target origin to opt into allowing source origins to share caches with it, that wouldn't also reintroduce the privacy leaks. (As, after all, even if the only things malicious-site-X can see in your cache are ad-tech providers' origins that opted into allowing anyone to interface with them, that's likely still enough to fingerprint you.)
- jefftk 5y agoIt would still be sharded by top-level domain, though, which would be enough to prevent cross-site tracking. This is specifically for the case where a page looks like: [common top level origin] -> [iframed different origin].