1868448 - Private browsing site data displayed in regular manage site data dialog

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[Emma Zühlcke [:emz]]

I've just tested Bug 1817596 again, but with youtube.com instead. Even though I've only browsed in private browsing youtube.com shows up in "Manage Cookies and Site Data".
It could be that since we now enable Cache API in private browsing (Bug 1835300) we show PBM data in the Site Data Manager too.

Though I'm worried that we might be leaking private browsing data into normal browsing buckets. Have we potentially regressed Bug 1814733?

+++ This bug was initially created as a clone of Bug #1817596 +++

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

1. (in normal mode) I check cookies: settings-> cookies and site data -> manage data -> (specifically "arkadium.com") and it is not there.
2. open a new private window
3. go to arkadium.com (I'm not sure it matters, but I play "classic solitaire"
4. Close the private window
5. (Back in normal mode) check cookies: settings-> cookies and site data -> manage data -> (specifically "arkadium.com") and it >is< there.

Actual results:

A website visited in private mode places cookies in normal mode.

Expected results:

Cookies, in private mode, should not appear in normal mode.

Comment 1

[Emma Zühlcke [:emz]]

:hsingh, you last updated the storage access code for the Cache API here: https://searchfox.org/mozilla-central/diff/0890b51845b7045d3da7d134c8d5d17ee014af87/dom/cache/CacheStorage.cpp#578
Is it possible that this regressed Bug 1814733? How can we ensure that there are no leaks to normal browsing buckets and that its purely a UX issue?

Comment 2

[Emma Zühlcke [:emz]]

Clearing obsolete bug info from cloned bug.

Comment 3

[Emma Zühlcke [:emz]]

Looking at the data in SiteDataManager._sites, the principal for the entry has the origin "https://www.youtube.com^privateBrowsingId=1". That's unexpected to show up in "Manage Cookies and Site Data" but might be in indicator that this bug is really just a cosmetic issue.

Comment 4

[Benjamin VanderSloot [:bvandersloot]]

I was unable to reproduce this on my local build or Nightly 121, (2023-10-27) (aside- that is out of date, wow!) with youtube or arkadium.

I did trick myself into thinking I had a reproduction for a second. If you are clearing data in Step 1 of your instructions, then you have to click "Save Changes" in the Manage Data modal to actually clear the data. If you delete the row but don't click the button, it is missing from the UI but will be isn't removed and will right back as soon as you reload about:preferences#privacy. That may be a UX issue, even if it isn't what you encountered.

Comment 5

[Benjamin VanderSloot [:bvandersloot]]

Reproduced on Nightly 122, (2023-12-01) with youtube. No cookies, but there is Storage.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Couldn't repro this from arkadium, I could not see any entries when on PBM either. I'll try YouTube again.

Comment 7

[Emma Zühlcke [:emz]]

Attachment: 1868448.m4v

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

I can reproduce it with YouTube but it's indeed just a cosmetic issue:

1. Prepare a new profile
2. Open PBM
3. Open https://www.youtube.com/watch?v=ViBlMIhglWs and play the video
4. Open about:preferences#privacy in normal window and see there's data
5. Close PBM
6. Refresh the preferences tab
7. See there's none anymore

The data properly goes to storage/private. Closing the PBM session removes the directory, and there's no relevant subdirectory in storage/default.

Comment 9

[Emma Zühlcke [:emz]]

Awesome, thanks for confirming! Looks like we can make this bug public then.

For the UX issue, I'm wondering if the call here https://searchfox.org/mozilla-central/rev/413b88689f3ca2a30b3c49465730c0e7d40f9188/browser/modules/SiteDataManager.sys.mjs#234 should simply not return PBM usage? Alternatively we can filter out PBM entries in the SiteDataManager too.

Comment 10

[Emma Zühlcke [:emz]]

Most likely a regression of Bug 1864684.

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

A bit more explanation: the storage is from indexedDB (we get idb subdirectory). You can see the same with minimal repro:

1. Open PBM
2. Open example.com
3. Copypaste this to devtools console:

const request = indexedDB.open("foo", 2);
request.onupgradeneeded = (event) => {
  const db = event.target.result;
  const objectStore = db.createObjectStore("customers", { keyPath: "ssn" });
  objectStore.createIndex("name", "name", { unique: false });
  objectStore.createIndex("email", "email", { unique: true });
};

1. See whether the site data includes example.com in about:preferences#privacy
2. Open example.com in a normal tab
3. Open devtools and see there's anything in Storage tab, under IndexedDB (there is none)
4. Close PBM
5. Refresh the preferences tab and see whether it still includes it (it does not)

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1864684

:hsingh, since you are the author of the regressor, bug 1864684, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

Probably Cache API should show the same behavior but let's point to bug 1831058 here.

Comment 14

[Harveer Singh]

I don't think this is a regression of 1864684. I think if an application is using any client side storage (local storage, indexedDB and now, CacheAPI), we could leak their origin names in 'Manage Cookies and Data' settings and is not strictly tied with cacheAPI. You could confirm this by loading sites in PBM which uses IndexedDB only or by disabling the dom.cache.privateBrowsing.enabled pref explicitly.

However, opening up CacheAPI in PBM does make the issue bit more severe.

I will follow up on this shortly again.

Comment 15

[Harveer Singh]

I played a bit more with this. Origin names never makes to disk and the private origins in 'Manage cookies and site Data' are only shown until the private session is active. Once, an user closes the session, private origins disappear and all their origin data gets deleted.

I am not sure if this is an issue per se, because this just effects UI and is lifetime'd properly; after all we want user to manage these private origins so displaying the names does make sense. I don't think security threat model considered this as a threat vector in private browsing mode feature elaboration.

Comment 16

[Jan Varga [:janv]]

(In reply to Paul Zühlcke [:pbz] from comment #9)

Awesome, thanks for confirming! Looks like we can make this bug public then.

For the UX issue, I'm wondering if the call here https://searchfox.org/mozilla-central/rev/413b88689f3ca2a30b3c49465730c0e7d40f9188/browser/modules/SiteDataManager.sys.mjs#234 should simply not return PBM usage? Alternatively we can filter out PBM entries in the SiteDataManager too.

The referred call has always returned all usage, including usage for PBM. Changing it to exclude PBM should be easy, but is that really an issue ?

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #9)

For the UX issue, I'm wondering if the call here https://searchfox.org/mozilla-central/rev/413b88689f3ca2a30b3c49465730c0e7d40f9188/browser/modules/SiteDataManager.sys.mjs#234 should simply not return PBM usage? Alternatively we can filter out PBM entries in the SiteDataManager too.

It's probably appropriate for Product in conjunction to UX to revisit the purpose and design of Site Data Manager given that PBM support for IndexedDB and Cache API can result in a meaningful amount of disk usage. A major simplification right now is that the Site Data Manager combines/conflates all of the following, as I understand it, although there are also docs on FSD:

• all subdomains of an eTLD+1 base domain into a single named eTLD+1 base domain aggregate item
• all partitioned storage resulting from iframes/non-toplevel-browsing-contexts into the eTLD+1 of the top-level page that partitioned their storage.
• all OriginAttribute variations of an origin (other than partition key which is handled above), regardless of container and private browsing status. The site data manager does maintain a separate tally of storage user per container but I don't understand where, if ever, this is surfaced to users. I don't see any place cited in the end-user documentation linked to from the container addon repo.

I see there being three potential major uses for this UI right now:

1. Where did all my disk space go?
2. Privacy spring cleaning: see what sites are storing data and clearing it up without a specific site in mind.
3. Targeted privacy cleanup: wanting to clear data with specific sites in mind. (Although there are other options for this like the URL bar lock icon identity panel mechanism, the history forget about this site mechanism, and the clear recent history based on time and probably wipe way more data than you intended to because your pinned tabs probably will get wiped too mechanism.)

Combining PBM data with non-PBM data definitely is confusing for all use-cases. But not providing a way to know how much disk space is being used by PBM but that will be cleared when the current PBM session ends would also be confusing.

An option to deal with this would be to have the Site Data Manager partition data by PBM versus non-PBM and to basically duplicate the "Cookies and Site Data" section for PBM. So the text that reads "Your stored cookies, site data, and cache are currently using 3.1 GB of disk space." for me right now might instead read: "Your current private browsing session is currently using 3.1 GB of disk space." If we're doing that, or a variation on that[1], I think it might also be interesting to consider duplicating the section for each of the user's defined containers. It might also make sense to apply this idiom to the permissions section of the page as well, as I believe the permissions UI as exposed on this page is likely highly confusing due to conflation of the different OriginAttributes as well.

I'm setting a needinfo on :mconca who I think is the right product person for DOM Storage to decide or delegate and 1 for :pbz to 1) set the right needinfo for the relevant product manager for anti-tracking/privacy, and 2) maybe you know where the per-container usage tallies might be exposed to the user?

1: We would probably want something that would establish a visual hierarchy that makes it clear that the storage for each of the "default container/PBM/all explicit containers" are part of a set.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

It looks like there's a little bit of room for confusion here, but nothing that's actually dangerous to the user (we've verified that the site data from private windows is cleared once the last private window closes). Setting S4 and P3.

This may or may not be something that the gang working on Felt Privacy might want to look at, so cc'ing mhowell.

Comment 19

[Emma Zühlcke [:emz]]

Thanks for the great summary Andrew!

The container specific code in SiteDataManager comes from Bug 1715535 which was part of a project adding UI to support managing site data per container. Looks like the UI part (Bug 1713069) was never implemented though.

NI for :mbalfanz from product. Updating this UI to support managing normal browsing data, private browsing data and containers seems like a cool project! This would be beneficial for permissions too as they're currently isolated between normal browsing and private browsing. I had also implemented isolation of permissions between containers, but we never ended up enabling it (Bug 1641584), because we were lacking proper UI support.

Comment 20

[Martin Balfanz [:mbalfanz]]

Attachment: CleanShot 2024-01-05 at [e-mail]

Thanks for flagging me. "Manage Data" is one of the more interacted with options in about:preferences#privacy. The data stored from private windows also increases the counts in disk space summary and clear data dialog, so I think we should improve it to avoid confusion.

Given the ephemeral nature of private windows, I'm not convinced yet that users need the same level of control as they might do for normal windows.

I think we could achieve a good result by:

• filtering out private window data from the manage data list
• add a summary of how much temporary data is stored in private windows

Something like the screenshot attached.

In any case, I'll take this to UX and the felt team and see what they think!

Comment 21

[Emma Zühlcke [:emz]]

Thanks! That seems technically feasible, but it might be a bit odd to show that PBM uses data while not providing a mechanism / button to clear that data. Let's see what the UX folks think about it.

Comment 22

[Mike Conca [:mconca]]

Removing my NI as Martin is engaged.

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #21)

Thanks! That seems technically feasible, but it might be a bit odd to show that PBM uses data while not providing a mechanism / button to clear that data. Let's see what the UX folks think about it.

One thing to consider is whether it makes sense to include some combination of a direct link to a support.mozilla.org page and/or an upsell to an "expert" UI. In bug 1677736 we have a proposed about:storage UI page that would likely end up providing a much more "debug UI" experience like about:serviceworkers because it would be a debug UI. It could definitely surface much more granular data, although I think a major caveat would be that any clearing options would likely be biased to only clearing QuotaManager storage, and optionally at a per-client granularity, because usually when debugging that's what we want[1]. That said, as long as we think we can do things in a non-brittle way, it seems reasonable to offer the option to also perform data-clearing via nsIClearDataService[2].

The support.mozilla.org page could explain that private browsing data will be closed when the private browsing windows are closed. It could also mention that if users are interested in more granular data clearing they could use about:storage, but explicitly contextualize that it's a debugging UI. The idea would be that this could provide an escape hatch for expert/power users without overly complicating the normal UI.

1: In particular, I found myself asking a user to manually clear just their Cache API storage for gmail, and I would ideally not want them to clear cookies, as that could create a hassle for them.

2: If we ended up wanting more involved UI for configuring the use of nsIClearDataService, maybe the about:storage UI could generate a link to something like about:clear-data-service#originWithSuffix=https://the.clicked.origin^privateBrowsingId=1 which could avoid needing to replicate the origin-listing UI but decouple maintenance of the UIs.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1986456: S3

:mstriemer, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 27

[Scott Macpherson]

There are a couple of assertions in this discussion that nothing terrible is happening here and there's no danger to the user. While this bug isn't leaking any "data" it is leaking domain names of sites that were visited in (now closed) private browsing windows. That is… alarming.