1692567 - Accessing a site in Private Browsing can cause that site's non-private session to be logged out in 24 hours

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[Robby S]

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

Steps to reproduce:

Step 1: Open a Firefox window. Log into and interact (e.g. click or scroll up and down) with a known tracking site - I'm using twitter.com in my example, but you can replace this with any site that is eligible for purging by the purge_trackers functionality. Check the storageAccessAPI entry for twitter.com in the permissions.sqlite database for your Firefox profile to make sure that the expireTime is correctly getting set to 45 days in the future. Close the window (and any other Firefox windows) once this has been confirmed.

Step 2: Open a new Firefox window. Do not interact with twitter.com in this window. You may have twitter.com open in a tab, but don't interact with it. (see Note below)

Step 3: Open a Private Browsing window. Access twitter.com in that Private Browsing window, and interact with it (click/scroll/etc, no need to login in the private window).

Step 4: Check the permissions.sqlite database for your Firefox profile. The storageAccessAPI entry for twitter.com will be gone, and with it the 45-day expire time. The deletion of this entry is the bug in question - the next two steps simply reproduce the user-visible effects.

Step 5: Close the Private Browsing window and the main Firefox window. Don't interact with twitter.com in a non-private window again until the tracking purge occurs (i.e. within 24 hours).

Step 6: Open a new Firefox window once the tracking purge has occurred. Navigate to twitter.com. You will have been logged out (i.e. site data has been purged), despite 45 days not having passed since your last interaction.

Note: If you don't interact with twitter.com in Step 2, then interacting with twitter.com in the main Firefox window in Step 5 will re-add the storageAccessAPI entry, as expected. However, if you do interact with twitter.com in Step 2, then interacting with twitter.com in the main Firefox window in Step 5 will NOT re-add the storageAccessAPI entry - even if you click on a link to another twitter.com page and interact with that new page - unless you refresh the tab first or interact with twitter.com in a new tab. The logout described in Step 6 will occur in any scenario in which the storageAccessAPI entry is missing when the tracking purge occurs.

Actual results:

I've found myself frequently getting logged out of certain sites between browser sessions. Normally, there's supposed to be a 45 day grace period for inactivity before purging site data, but I'm seeing it happen as quickly as 24 hours - it seems to happen when I access the site in question via private browsing, then attempt to access the site a few days later in non-private browsing. Steps to reproduce are described above: it appears that accessing a site via private browsing is wiping out the already-existing storageAccessAPI expire time entries for that site.

I do not have Firefox set to clear history or cookies on shutdown, so my issue is not caused by this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1672394

Expected results:

I would not expect interacting with a site in a Private Browsing window to eliminate my 45-day expiration date for that site's session activity. I'd expect the storageAccessAPI expire time for non-private sessions to be maintained or restored after accessing a site in a Private Window.

Turning off privacy.purge_trackers is a temporary workaround to avoid having my session data deleted, but I would like to be able to have this setting enabled and purge trackers for genuinely inactive sites, without being logged out of my active accounts.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Johann Hofmann [:johannh]]

Wow, great find, thanks for filing this bug. I’ll look into this.

Comment 3

[Emma Zühlcke [:emz]]

I think the issue is that the private browsing window overwrites the storageAccessAPI permission with a new permission of EXPIRE_SESSION. That means it will be removed once the browser is closed. This is done for all permissions set from private browsing principals: https://searchfox.org/mozilla-central/rev/002023eb262be9db3479142355e1675645d52d52/extensions/permissions/PermissionManager.cpp#1601-1611

The issue only occurs in release (and probably also late-beta), since those are the only channels that don't have their private browsing permissions isolated from normal browsing, which allows the private window to overwrite normal window permissions. Pref here: https://searchfox.org/mozilla-central/rev/66df971f6f38d42bf4e0b77aa2895fe8380a817e/modules/libpref/init/StaticPrefList.yaml#9090
Bug 1680237 enabled the permission isolation in release for 88, and we should probably uplift it to 87.