The content cache is a vector for third party tracking (by way of embedded identifiers in scripts, iframes, etc). In Tor Browser, we created an additional string-based cache key that functions like the HTTP POST cacheKey id to effectively double-key the cache to the first party domain (but using the domain name string rather than an integer). We currently set this cacheKey from a Torbutton http-on-modify-request observer, but we could also set it from nsHTTPChannel as well.

Steve, the Tor folks are working on this over here: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.4.0esr-4.5-1&id=6b35de93e3439f9a746a29e81be857273de82065

After reviewing the Tor patch, I think it's better if we punt on this for now in favor of bigger changes to AppId. See https://groups.google.com/d/topic/mozilla.dev.privacy/XQza_CmYDr4/discussion In short, the goal there would be to generalize AppId to allow for double keying in different contexts, e.g. per App, per Site, per Window.

Here's a link that tracks the latest version of the Tor Browser patch: https://torpat.ch/13742 and here are the regression tests: https://torpat.ch/13749

By "Content Cache" do you mean HTTP Cache (regular network cache) or DOM Cache (used by script and service workers - https://developer.mozilla.org/cs/docs/Web/API/Cache)?

According the patch, this tries to modify how we are keying the HTTP cache data. I think I follow the idea, just the patch is very much displaced. But I have not enough (if any) info about this whole effort to suggest how this should be actually implemented.

(In reply to Honza Bambas (:mayhemer) from comment #5) > According the patch, this tries to modify how we are keying the HTTP cache > data. Yes, by "Content Cache" I meant the HTTP Cache. And our patch does work correctly to the extent that our regression tests in https://torpat.ch/13749 indicate that objects in the HTTP Cache are kept separate according to URL bar domain. So, for example, two pages with different URL bar domains will cache separate copies of one script from the same third-party URL. > I think I follow the idea, just the patch is very much displaced. Can you clarify what you mean by this? Do you mean the code should be in another location, or do you see a problem with the implementation? > But I have not enough (if any) info about this whole effort to suggest how this > should be actually implemented. I'm happy to provide any info about the Tor Browser effort that would help.

Once we have origin attribute support across the platform, it will be very easy and clean to use a "first-party-domain" origin attribute to double key stored data. So the current code, while it works now, will not be necessary in the future.

(In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #7) > Once we have origin attribute support across the platform, it will be very > easy and clean to use a "first-party-domain" origin attribute to double key > stored data. So the current code, while it works now, will not be necessary > in the future. I don't watch progress on extending origin attributes (OA) these days that closely. But it seems like Tanvi has answered the question here. Simply said, if the referer-domain (or first-party-domain) information will be stored in OA (and thus in OriginSuffix string), cache will treat it transparently as a distinct separator. There is no need to do this anywhere in upper levels. nsHttpChannel::AssembleCacheKey is used only to identify POSTs and is sufficient in the current form. OA and OriginSuffix string are automatically added to the cache identification keying. It's taken from LoadContext automatically when opening a cache entry (info that the cache API now requires). So we are all good here and I think this bug can be closed as duplicate of adding first-party-domain to OA. What I don't much like on this is we loose resource sharing between sites (fonts, jquery etc hosting on e.g. googleapis), which is a performance regression, definitely. Do you have any performance data?

honza, in general with the tor patches this would be preffable. The assumption would be that we wouldn't make a change in default firefox prefs for it unless the performance data (in this case including storage utilization) worked out. but its still valuable to land it in tree for tor.

Removing my assignment while we find out if bug 1260931 already takes care of this.

Setting this bug depend on bug 1191418 is not appropriate. Bug 1191418 is a meta bug for the entire Containers feature. Per comment 10, this bug might be resolved by bug 1260931.

this patch is a test cache that confirms that http/content cache isolation is working with first party origin isolation. since it appears to be working, i'm going to close this bug as resolved, duplicate.