1869734 - Firefox Settings UI has misleading claim about permanent private-browsing-mode: "cookies and site data will always be cleared when Firefox is closed", but in fact your *preexisting* cookies/data (before you entered permanent PB mode) will not be cleared

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Bug]

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

Steps to reproduce:

1. Visit youtube in non-private mode.
2. Go to manage cookie and website data.
3. See youtube listed there.
4. Set firefox to "always use private mode"
5. accept the browser restart thing
6. Go to manage cookie and website data.
7. observe youtube is still there
8. quite and restart FF
9. Go to manage cookie and website data.
10. observe youtube is still there, and not deleted.

The info box in the UI says:
"In permanent private browsing mode, cookies and site data will always be cleared when Firefox is closed."

This is actually not correct. It leaves the data that was stored when private mode was not yet active. It remains unclear if private mode can access data that was previously stored in non-private mode.

Actual results:

Data was not deleted.

Expected results:

Data should have been deleted.

Or the documentation should say
A) that non-private data is still stored
B) private mode can/can-not access the old non-private data

Ideally, the "manage cookie and website data" dialogue should display the context, i.e. a description of the data container that stores the data. Do not bundle in-private numbers and private-numbers into the same entry; Display two entries for the same host, and distinguish between transient (private mode) and persistent data (non-private mode).

At least please fix the UI widget text.

Comment 1

[Bug]

Do not bundle in-private numbers and private-numbers into the same entry; this should read:
Do not bundle in-private numbers and non-private-numbers into the same entry;

Comment 2

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

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

Comment 3

[Daniel Holbert [:dholbert]]

Thanks for the bug! I can reproduce. (BugBot seems to have misclassified; I'm reclassifying to Settings UI since that's where this lives.)

The text that you highlighted...

"In permanent private browsing mode, cookies and site data will always be cleared when Firefox is closed."

...would be more correct if it said something along the lines of the following (could be phrased better but the bold part is the important bit):
"In permanent private browsing mode, when Firefox is closed, cookies and site data from the current browsing session will always be cleared".

I suspect we don't want to actually delete historical data (not unless the user explicitly clicks the button to do so), because that turns this setting into a pretty-catastrophic "whoops, you just torched your whole history" tripping-hazard that folks may accidentally trigger without realizing the consequences.

This string was added in bug 1443644, it looks like; I'm adding a dependency on that bug.

Comment 4

[Daniel Holbert [:dholbert]]

As noted in bug 1443644, this message is meant to explain why another piece of UI becomes unavailable/hidden when you're in permanent private browsing mode -- specifically, we normally show a checkbox Delete cookies and site data when Nightly is closed, and that checkbox isn't shown when you're in permanent-PB-mode.

(Note that in normal i.e. non-permanent-pb mode, this Delete cookies and site data when Nightly is closed checkbox does cause preexisting data to be cleared at shutdown, unlike the similar data-clearing-at-shutdown that happens in permanent-PB mode which just clears ephemeral data from that session.)

Gijs: bug 1443644 was in response to a request from you, so I'll tap you in here -- any thoughts on whether we should change the messaging vs. clear-the-preexisting-data vs. something else?

Comment 5

[:Gijs (he/him)]

Attachment: Screenshot of the message

Right... to be fair, I do still think it'd be confusing for that checkbox to just be greyed out with no context. It would make more sense to just hide it? But then also, would people think that data that shows up in "manage data" has to be manually deleted every time?

I agree that clearing the pre-existing data when first enabling permanent private browsing mode would be a massive footgun. I don't think the slight user confusion here is worth trying to add more complex logic to try to remove the data once you've used permanent private browsing mode a little while (plus it would probably interrupt people at a bad time and/or lead to even more confusion).

We could also just hide the non-PB data from the "manage data" dialog, but then that also has downsides (removes the ability for users to delete that data from disk), and there are probably other artifacts of this (maybe http cache?) that show up, and trying to airbrush all of it is proabbly a losing battle.

Really, I don't think there's a winning move here.

I'm fine with updating the messaging to be more precise, perhaps something like "Browsing data created in permanent private browsing mode is always cleared when Firefox closes".

(it's actually a bit better than that, I think we try pretty hard not to write such data to disk at all, so it goes away by virtue of Firefox no longer being in memory... anyway. Not sure we want to guarantee anything about that.)

Maybe Katie can suggest someone from content design who could come up with a better message here. My suggestion is above, Daniel has one in comment 3, and I've attached a screenshot of the context here, but I can help with questions as needed.

Also, Paul, I don't suppose you have any thoughts on this given the relation to "manage site data"?

Comment 6

[Daniel Holbert [:dholbert]]

"Browsing data created in permanent private browsing mode is always cleared when Firefox closes".

(I like this wording better than my quoted strawman-phrasing in comment 3, FWIW. Though probably should say "Cookies and site data" rather than "Browsing data" to be consistent and more directly comparable to the UI-that-we're-hiding, whose absence this message is trying to explain.)

Comment 7

[Bug]

@Gijs: Can't we have non-private and private data both be displayed in the "manage data" dialogue, but tagged with their origin?
I.e. youtube.com = 750kb and 10 cookies from non-private mode
youtube.com = 250kb and 3 cookies from private mode?

(Plus a sentence clarifying whether private youtube.com has access to the non-private youtube.com data?)

This would help greatly, I think, and it would also help me trace some other issue.

I have reason to believe that when "always use private mode" is on, this is not entirely true; I feel that the "non-private" tabs that were open before switch to permanent private browser are STILL open somehow. Sometimes, I see "undeletable data" respawn in the manage data dialogue, i.e., data that will not be cleared when you close FF. Since this data is likely originating from a non-private context, I wonder when firefox would refresh the tabs that should actually be dormant in case of FF-wide private browsing mode.

Furthermore, please also consider to display "localStorage" and other data in the manage data dialogue. As I reported in bug 1851558, the manage data dialogue seems to be broken in always private browsing mode anyway somehow. You cannot delete any localStorage with it. And I think, when user request purge of site data, this should really be done, and not silently ignored. The localStorage of rebuy.de which I described and screenshotted in 1851558 is invisible to the manage data dialogue.

Having more consistent data displayed in "manage Data" would do a great deal.

Comment 8

[Bug]

Usability-wise, please also note, in always private mode the only way to clear data is to close the browser.

But on the mac, when you use the red X to close the browser, only the window will close. The process is still active, and your data is all way retained. Unless you note und understand that you have to close the browser by using Firefox->Quit Firefox from the menu, private mode will only make your situation WORSE.

Shouldn't you clear private mode data also when the red X is used to "close" the browser??? (yes I think you should)

Please be aware that all privacy measures are in vain if usability issues prevent them from going effective.

Comment 9

[Bug]

(I have just opened 1869987 for this)

Comment 10

[:Gijs (he/him)]

(In reply to Hannes from comment #7)

@Gijs: Can't we have non-private and private data both be displayed in the "manage data" dialogue, but tagged with their origin?

This is discussed in bug 1868448.

I have reason to believe that when "always use private mode" is on, this is not entirely true; I feel that the "non-private" tabs that were open before switch to permanent private browser are STILL open somehow. Sometimes, I see "undeletable data" respawn in the manage data dialogue, i.e., data that will not be cleared when you close FF. Since this data is likely originating from a non-private context, I wonder when firefox would refresh the tabs that should actually be dormant in case of FF-wide private browsing mode.

Those tabs are on disk in a session restore file, and I don't know of any mechanism to resuscitate them other than disabling permanent private browsing mode. I don't believe the content of the file is even read into memory in permanent private browsing mode - we bail out super early here. Please file a separate bug with more information about what you're seeing and we can take a look separately. Please describe there why you think "this data is likely originating from a non-private context". (needinfo flag for this)

Furthermore, please also consider to display "localStorage" and other data in the manage data dialogue.

As far as I can tell this is already happening, as in, it's not some kind of missing feature. I gave a code link regarding this in the other bug you filed. Maybe there are bugs relating to permanent private browsing mode. Either way it's not something that will be considered as part of this bug - please let's stick to one issue per bug.

Comment 11

[Bug]

I'm fine with updating the messaging to be more precise, perhaps something like "Browsing data created in permanent private browsing mode is always cleared when Firefox closes".

I like this one.

Plus maybe add: Websites opened in private mode cannot access browsing data from non-private sessions.

(If this is true - if the opposite is true "cannot" should be "can")

Comment 12

[:Gijs (he/him)]

(In reply to Hannes from comment #11)

Plus maybe add: Websites opened in private mode cannot access browsing data from non-private sessions.

This is the basic guarantee of private browsing - that it's completely separated from non-private browsing. Having explicit text to say this is a bit like adding text that says "water is wet". It shouldn't need to be said - we have long help pages on SUMO explaining what private browsing is. Unfortunately, your specific suggestion adds uncertainty because... what about the reverse? Can non-private mode websites access private data? Of course the answer is "no", but technically your suggested phrasing doesn't say this. To be clear, I'm not pointing this out to be mean or pernickety, but to show that writing this stuff and having it be unambiguous is difficult, especially if people start questioning the nitty-gritty.

(In reply to Hannes from comment #7)

I have reason to believe that when "always use private mode" is on, this is not entirely true; I feel that the "non-private" tabs that were open before switch to permanent private browser are STILL open somehow. Sometimes, I see "undeletable data" respawn in the manage data dialogue, i.e., data that will not be cleared when you close FF. Since this data is likely originating from a non-private context, I wonder when firefox would refresh the tabs that should actually be dormant in case of FF-wide private browsing mode.

As I said before I would like to see a separate bug for this, and that's why I set the needinfo flag.

Please file a separate bug with more information about what you're seeing and we can take a look separately. Please describe there why you think "this data is likely originating from a non-private context". (needinfo flag for this)

Comment 13

[Bug]

It will take a while to reproduce it i think. it might be related to addons (i wondered if addons could iterate over the recently closed tabs even if in always private mode) i will keep an eye on it.

but now that you ask: following phenomenon:

i have installed new FF in linux.
i go to settings and delete all browsing data.
i restart FF and see 5 cookies from mozilla.org
i again remove all data and set FF to always private mode and restart.
i go back to data dialogue and see 5 cookies from mozilla.org
i again delete them all.
i restart FF and again, 5 mozilla.org cookies are displayed.

full of sadness, I open mozilla.org in a new tab, to check if these cookies are all the same.
i open web developer tools and reload mozilla.org
on all 4 storage classes, web developer tools say "no data for the host".

what kind of 5 mozilla.org cookies could respawn or be undeletable and how to inspect them?

Comment 14

[Bug]

oh I think i found it - these cookies are created when telemetry is enabled.
but come on, this again speaks for displaying some sort of context along with the data, so we see where it comes from. could safe so much time.

Comment 15

[:Gijs (he/him)]

I filed bug 1871561 for the mozilla.org cookie bits. (edit: fixed bug link)

Comment 16

[Paul Zühlcke [:pbz]]

As Gijs mentioned we actually show some of the site data from private browsing in the "manage site data" dialog: Bug 1868448. This isn't consistent across storage implementations though, which makes the behavior pretty confusing to users. Ideally we would support clearing private browsing data (during the private browsing session) using our clear data UIs (Bug 1818783). The "manage site data" dialog could be updated to show separate marked entries for private browsing, or could show entries based on which window it's opened from (normal or private browsing).

(In reply to Hannes from comment #14)

oh I think i found it - these cookies are created when telemetry is enabled.
but come on, this again speaks for displaying some sort of context along with the data, so we see where it comes from. could safe so much time.

Perhaps any chrome requests should also be made in the context of the private browsing context, if "always use private browsing" is enabled. I'm surprised that telemetry requests would result in cookies being stored. Are you sure the cookies come from telemetry requests?

I've enabled "always use private browsing", cleared data and restarted the browser. I'm seeing the following cookies in the Browser Console:

Services.cookies.cookies.map(c => ({host: c.rawHost, name: c.name, value: c.value}))
Array(5) [ {…}, {…}, {…}, {…}, {…} ]
​
0: Object { host: "addons.mozilla.org", name: "taarId", value: "e78b66cccb57a017da97631fbd05176d3674a7a68f4181b45751d49fff9245a3" }
​
1: Object { host: "addons.mozilla.org", name: "taarId", value: "e78b66cccb57a017da97631fbd05176d3674a7a68f4181b45751d49fff9245a3" }
​
2: Object { host: "addons.mozilla.org", name: "taarId", value: "e78b66cccb57a017da97631fbd05176d3674a7a68f4181b45751d49fff9245a3" }
​
3: Object { host: "addons.mozilla.org", name: "taarId", value: "e78b66cccb57a017da97631fbd05176d3674a7a68f4181b45751d49fff9245a3" }
​
4: Object { host: "addons.mozilla.org", name: "taarId", value: "e78b66cccb57a017da97631fbd05176d3674a7a68f4181b45751d49fff9245a3" }
​
length: 5

They get added here: https://searchfox.org/mozilla-central/rev/77aeaa184d59944ecb117e452ea43f5bd1556e4c/browser/modules/Discovery.sys.mjs#120,134 . The code is explicitly passing privateBrowsingId: 0 which is normal browsing. The duplication comes from the code adding one cookie per user context (tab container).

Comment 17

[:Gijs (he/him)]

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

Perhaps any chrome requests should also be made in the context of the private browsing context, if "always use private browsing" is enabled. I'm surprised that telemetry requests would result in cookies being stored. Are you sure the cookies come from telemetry requests?

Yeah, I did the same debugging work as you in bug 1871561 - they're not from telemetry but from the containers code, and aren't created by requests.

Comment 18

[Bug]

1.) @Gijs: You wrote:
This is the basic guarantee of private browsing - that it's completely separated from non-private browsing. Having explicit text to say this is a bit like adding text that says "water is wet".

No, I do not think this is "crystal clear".
https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history
This page only says that the data created by the private mode is deleted when the private mode ends.

It does not seem to say that e.g. cache entries that had been created before enabling private mode would become inaccessible.
Where is that stated? thanks

2.) @Paul: The code is explicitly passing privateBrowsingId: 0 which is normal browsing. So indeed, we have the non-private storage containers active even if "always private mode" seems to suggest that these are "switched off" ? And in the UI, we display this data, while actually hiding the tracking data that follows you in the current session... you see the problem...(and I personally think this is especially bad on the Mac because there closing all the windows does not imply that the application shuts down, instead it remains invisibly active. Gijs said mac users are well aware of this - but if I could place a bet - I think the opposite is correct) If the container context would be visible in the data UI, one would not need to read source code in order to find out where the data came from...

Comment 19

[klower]

(In reply to :Gijs (he/him) from comment #5)

Maybe Katie can suggest someone from content design who could come up with a better message here. My suggestion is above, Daniel has one in comment 3, and I've attached a screenshot of the context here, but I can help with questions as needed.

Here is an updated string:

Based on your history settings, { -brand-short-name } deletes cookies and site data from your session when you close the browser.

This addresses the original concern, to clarify that the cookies and site data that are deleted are for the current session only. It also removes reference to “permanent private browsing mode”, as this is not a phrase we use elsewhere in the UI.

Comment 20

[:Gijs (he/him)]

Attachment: Bug 1869734 - update explainer text around deleting data and private browsing, r?pbz

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/65f9a92644bb
update explainer text around deleting data and private browsing, r=pbz,fluent-reviewers,flod

Comment 22

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/65f9a92644bb

Comment 23

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 122.0a1 on Win10.
I can confirm this issue is fixed, I verified using Firefox 124.0b9 on Win10, macOS 12 and Ubuntu 22, the text around deleting data and private browsing was updated.