Open Bug 1371651 Opened 7 years ago Updated 2 years ago

about:cache does not show entries when `privacy.firstparty.isolate` is set to `true`

Categories

(Core :: Networking: Cache, defect, P3)

52 Branch
defect

Tracking

()

People

(Reporter: gk, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor 22451][necko-backlog][dfpi-ok])

Steps to reproduce: A) 1) Start Firefox with a clean profile 2) Switch `privacy.firstparty.isolate` to `true` 3) Go to torproject.org 4) Open `about:cache` -> there won't be images etc. loaded from torproject.org listed (but these entries are there if one inspects the cache database on disk; things are likewise broken if one uses the permanent private browsing mode as we do in Tor Browser) B) 1) Start Firefox with a clean profile 2) Go to torproject.org 3) Open `about:cache` -> you'll find all the images etc. cached as expected It would be pretty helpful and way less confusing if `about:cache` would show all the cache entries available (including the isolation keys for easy inspection). (We track that issue in bug 22451 on our side)
Assignee: nobody → allstars.chh
Priority: -- → P2
Assignee: allstars.chh → nobody
I think the changes need to be made to nsAboutCache.cpp The way to filter by extra attributes, is via the checkboxes (private, anonymous, appId, ... ) Another checkbox needs to be added for firstPartyIsolation. The way the filtering works is by adding '&context=' to the URI, which gets parsed via nsAboutCache::Channel::ParseURI -> CacheFileUtils::ParseKey -> ParseTags.
Whiteboard: [tor] → [tor][necko-backlog]
Priority: P2 → P1
Priority: P1 → P3

I poked at this a little. about:cache?storage=&context=O^firstPartyDomain=ritter.vg, is the incantation to show you cache entries for items with the FPD so specified.

But the more I think about it; the page seems flawed. For FPI we want to show a page containing all the cache entries for all firstPartyDomains. To do so meaningfully we need to show the entire cache key. That would include things like the private browsing bool, whatever 'anonymous' means, etc (and of course firstPartyDomain).

But I can't see the real cachekey being exposed to this page so it could possibly be output.

Whiteboard: [tor][necko-backlog] → [tor 22451][necko-backlog]

There's no such issue with dFPI. Besides torproject.org, my experiment for Images under iframes are also listed in about:cache.

Whiteboard: [tor 22451][necko-backlog] → [tor 22451][necko-backlog][dfpi-ok]

That reads like dFPI isn't affected, removing the meta bug.

No longer blocks: DynamicFirstPartyIsolation
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.