Open Bug 1870002 Opened 7 months ago Updated 7 months ago

Localstorage is not displayed in data maintenance dialogue when using always private mode

Categories

(Core :: Storage: localStorage & sessionStorage, defect)

Firefox 120
defect

Tracking

()

People

(Reporter: bug.reporter.321, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

  1. Set firefox to always use private mode
  2. Visit rebuy.de
  3. make search
  4. open web developer tools
  5. examine localStorage
  6. observe your search terms
  7. go to settings and launch the site data dialogue
  8. oberserve it is empty

Bonus steps:

  1. go to youtube.com
  2. play a video
  3. go to site dialogue again
  4. observe youtube.com is shown

Actual results:

Rebuy's localStorage is not displayed in the site data dialogue

Expected results:

Rebuys localStorage should be displayed but it is not

The Bugbug bot thinks this bug should belong to the 'Core::Storage: localStorage & sessionStorage' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Storage: localStorage & sessionStorage
Product: Firefox → Core

Harveer, perhaps you know how this is supposed to work?

Severity: -- → S3
Flags: needinfo?(hsingh)

I can look this through but I think this could be because in Private Browsing, localstorage keeps their data in-memory only and there are no file-system objects.

If this dialogue is all about file system, then in private mode noone should write there (and therefore not be listed), also not youtube.com
Also, I think you should display all the data, because who cares if the tracking cookies are stored in memory or on disk.

If there is in private mode no way to clear cookies and tracking data other than closing the browser, then this should clearly be displayed in the UI.

This is the major point. Having a clean vanilla filesystem might be nice if the wife inspects your hard disk, but the really important point about history and cache cleaning is to get rid of the trackers

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(hsingh)

(In reply to Jan Varga [:janv] from comment #5)

Aha, I think this regressed when https://phabricator.services.mozilla.com/D175915 landed, but it needs to be checked.
This line https://searchfox.org/mozilla-central/rev/5920b970c9996c7820c7ebf4e7b072e77017edf2/dom/localstorage/ActorsParent.cpp#8467
probably needs to be fixed.

Besides that, LSNG currently doesn't initialize origins (it doesn't initialize origins without creating origin directories either) for private browsing.
See https://searchfox.org/mozilla-central/rev/c3263d48f391c2c6c984b874986341baf667bf12/dom/localstorage/ActorsParent.cpp#6875
This shouldn't be so hard to change, but there are two things which probably prevent us from doing it right now:

  • origin initialization will also plug localStorage usage into shared quota usage tracking (shared with other quota clients and with other persistence types, this is already the case for IndexedDB and Cache API), so we probably need to investigate if there could be any unwanted side effects
  • related code is being refactored in https://phabricator.services.mozilla.com/D195551, so I would rather wait for that to land

Just a question without wanting to interfer: Jan, does your comment indicate that isolation-by-1st-party-origin also does not work in private mode?

I need to check, I don't see a reason why it wouldn't work. Anybody can create a simple test which tries to store more than 5MB data in two different contexts (normal and isolation). The issue here is about the way how we collect usage which is reported in the site data dialog. localStorage for private browsing currently doesn't create any directories or files on disk (as opposed to IndexedDB and Cache API which store encrypted data on disk) but the usage collection depends on having a corresponding directory on disk for a given origin (there are also some other small issues, and it should be possible to fix this bug even without creating any directories on disk, but I don't want to provide too many details for now which could cause even more confusion).

(In reply to Hannes from comment #7)

Just a question without wanting to interfer: Jan, does your comment indicate that isolation-by-1st-party-origin also does not work in private mode?

All privacy features relating to partitioning are unaffected by LocalStorage's Private Browsing Mode PBM specialization here. The choice of storage key (spec concept) / the firstPartyDomain (TOR-used OriginAttribute) or partitionKey (Firefox-used OriginAttribute) are made upstream of QuotaManager and LocalStorage.

thanks that is good news. if we get localstorage to display in the dialogue, will also cookies and other transient data be displayed?

You need to log in before you can comment on or make changes to this bug.