Permissions preserved between Private Browsing sessions (e.g. HTTPS-only mode exceptions)
Categories
(Core :: Permission Manager, defect, P3)
Tracking
()
People
(Reporter: david, Unassigned)
Details
(Keywords: privacy)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
- Enable HTTPS-only mode on all sites
- Open a Private Browsing window
- Go to an HTTP-only site. I use http://slackware.com for this
- You get the warning that HTTPS is not available. Click to confirm that you want to go to the plaintext HTTP site this time.
- Close this Private Browsing window
- Open another Private Browsing window and go to the same site
Actual results:
You get to your site without seeing the plaintext HTTP warning.
Expected results:
When you closed the first Private Browsing window, it should have "forgotten" this exception and given you the plaintext HTTP warning in the second window. Failing to do so is a small information leakage; it disclosed that you viewed that site in a Private Browsing window in the past.
Comment 1•1 year ago
|
||
Looks like these are stored as session only permissions here so they should go away when you quit the browser and reopen it.
I don't imagine this is intentional, and also I wonder why the permissions manager does not clear this data when the last private browsing window closes (I tested, it appears I can reproduce the issue described in comment 0). Freddy/Paul, who works on HTTPS only stuff nowadays?
Comment 2•1 year ago
|
||
Malte, maybe you can take a look at fixing this together with bug 1799708?
Comment 3•1 year ago
|
||
From what I can tell, this is not limited to HTTPS-Only, but the general permission behavior in private windows.
For example with notification permissions:
- Open Firefox
- Open a new private browsing window
- Open https://www.bennish.net/web-notifications.html and click the "Authorize" button to allow notifications
- Close the private browsing window
- Open a new private browsing window
- Open https://www.bennish.net/web-notifications.html again, this time click the "Show" button
That notification will go though because the site still has notifications allowed, the permission will only be revoked once the browser is completely restarted, not only the private browsing window. This example differs a bit from the HTTPS-Only one because the notification permission is not set to EXPIRE_SESSION
, but from what I can tell that should not matter in pbm, because through this all permissions should be handled as EXPIRE_SESSION
in pbm.
Comment 4•1 year ago
|
||
Until the last couple years permissions were not separated between private browsing and normal browsing. Now that we have the separation we could add a last-pb-context-exited
message observer in the permission manager implementation and clear all session PBM permissions when the last private browsing window exits. This should cover HTTPS exceptions which I assume are stored as permissions. Tim, do you agree?
Comment 5•1 year ago
|
||
This sounds right to me. FWIW, we should import default permission after we clear for the private session.
Comment 6•1 year ago
|
||
This is a privacy bug in the permissions manager, but it's not a vulnerability that could be weaponized against someone so it doesn't need to be hidden. Better that people know so they can take steps if this might affect them
Comment 7•1 year ago
|
||
S3, Workaround: Restart Firefox fully instead of just closing the private browsing windows.
Description
•