6 ms·

The cache segregation is a bit of a nuisance when building sites that uses iframes on different domains to sandbox user content. For example, Framer (where I wo

by blixt 5y ago

The cache segregation is a bit of a nuisance when building sites that uses iframes on different domains to sandbox user content. For example, Framer (where I work) sandboxes each user project on a unique subdomain of framercanvas.com, which is on the public suffix list so that different projects can’t share cookies, localStorage etc. But all resources loaded on these subdomains are always loaded fresh for new projects because of cache segregation, even if it’s the same old files being loaded over and over. I wish there was a way to establish a shared cache between two domains, because we could manually implement a content tunnel between framer.com and the sandbox that sends down cached content with postMessage, so optionally sharing cache doesn’t seem like an additional tracking issue if opted in explicitly.

torgard 5y ago
That's interesting. Just so I understand it correctly: * The iframe loads resources, e.g. /static/bundle.js and /public/index.css (does this include user-defined resources?). * But due to the iframe being embedded on sub**.framercanvas.com, the cache key includes the subdomain. So all resources are fetched again for all projects?
atirip 5y ago
Load all resources with fetch(), store to cache by yourself, take the response, clone and transfer into anything that can be sent with postMessage()
- mrblampo 5y ago
  Clever! It would be better for the intended behavior to be supported, though, right?
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 ago
  I 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 ago
    It 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].
finnthehuman 5y ago
>Framer (where I work) Your website runs terribly on firefox. Multiple hundred-of-millisecod periods where the viewport went blank.
tomnipotent 5y ago
> even if it’s the same old files being loaded over and over Is there a large enough audience visiting multiples sites that would make the effort worth it?

by blixt 5y ago

torgard 5y ago

That's interesting. Just so I understand it correctly: * The iframe loads resources, e.g. /static/bundle.js and /public/index.css (does this include user-defined resources?). * But due to the iframe being embedded on sub**.framercanvas.com, the cache key includes the subdomain. So all resources are fetched again for all projects?

atirip 5y ago

Load all resources with fetch(), store to cache by yourself, take the response, clone and transfer into anything that can be sent with postMessage()

mrblampo 5y ago
Clever! It would be better for the intended behavior to be supported, though, right?

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 ago
I 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 ago
  It 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].

finnthehuman 5y ago

>Framer (where I work) Your website runs terribly on firefox. Multiple hundred-of-millisecod periods where the viewport went blank.

tomnipotent 5y ago

> even if it’s the same old files being loaded over and over Is there a large enough audience visiting multiples sites that would make the effort worth it?