Open Bug 1839479 Opened 1 year ago Updated 1 year ago

Permissions preserved between Private Browsing sessions (e.g. HTTPS-only mode exceptions)

Categories

(Core :: Permission Manager, defect, P3)

Firefox 102
defect

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:

  1. Enable HTTPS-only mode on all sites
  2. Open a Private Browsing window
  3. Go to an HTTP-only site. I use http://slackware.com for this
  4. You get the warning that HTTPS is not available. Click to confirm that you want to go to the plaintext HTTP site this time.
  5. Close this Private Browsing window
  6. 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.

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?

Component: Untriaged → Private Browsing
Flags: needinfo?(pbz)
Flags: needinfo?(fbraun)

Malte, maybe you can take a look at fixing this together with bug 1799708?

Flags: needinfo?(fbraun) → needinfo?(mjurgens)

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:

  1. Open Firefox
  2. Open a new private browsing window
  3. Open https://www.bennish.net/web-notifications.html and click the "Authorize" button to allow notifications
  4. Close the private browsing window
  5. Open a new private browsing window
  6. 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.

Flags: needinfo?(mjurgens)

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?

Flags: needinfo?(pbz) → needinfo?(tihuang)

This sounds right to me. FWIW, we should import default permission after we clear for the private session.

Flags: needinfo?(tihuang)

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

Group: firefox-core-security
Status: UNCONFIRMED → NEW
Component: Private Browsing → Permission Manager
Ever confirmed: true
Keywords: privacy
Product: Firefox → Core
Summary: HTTPS-only mode exceptions preserved between Private Browsing sessions → Permissions preserved between Private Browsing sessions (e.g. HTTPS-only mode exceptions)

S3, Workaround: Restart Firefox fully instead of just closing the private browsing windows.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.