Closed Bug 1691546 Opened 3 years ago Closed 3 years ago

Website Login credentials leak from one Private Window to another Private Window

Categories

(Firefox :: Private Browsing, defect)

Firefox 85
defect

Tracking

()

RESOLVED DUPLICATE of bug 117222

People

(Reporter: ccpisme, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Steps to reproduce (observed in Firefox 85, in Linux Mint 20)

  1. Open a Private window, and navigate to a website that requires authenticated login, and login using a valid username and password. Once logged in, leave this 1st Private Window open.
  2. Open a separate 2nd Private window, and navigate to the same website.

Actual results:

Actual result: In the 2nd Private Window, I get automatically logged in, with the credentials that were entered in the 1st Private Window.

Expected results:

Expected result: In the 2nd Private Window, I should be prompted to enter a username and password.
The two Private Windows should be completely isolated from each other, using only their own separate resources, but instead, it seems they are sharing a pooled resource which allows leaking of sensitive information between private windows.

Note - This leak does not occur if testing between a standard window and a private window.

(In reply to Chris Preimesberger from comment #0)

The two Private Windows should be completely isolated from each other

Can you clarify why you believe this should be the case? I don't think any of our documentation or UI suggests it - because it isn't so. I just did a quick test in Chrome and it behaves the same -- e.g. cookie state is shared between private windows. The page that loads when you start a private browsing window explicitly says:

Firefox clears your search and browsing history when you quit the app or close all Private Browsing tabs and windows.

That last part implies exactly what is happening here: data is cleared when all private tabs/windows close, because all those tabs/windows share state.

(Marking non-sec-sensitive because there is no way an outside attacker can exploit this.)

Group: firefox-core-security
Component: Untriaged → Private Browsing
Flags: needinfo?(ccpisme)

Thank you for your quick response and consideration.

Respectfully, I think that should be the case because the Private Browsing feature is named with the word "private". According to the Oxford dictionaries, "isolated" is actually one of the synonyms for the word private. Each of these words are listed as synonyms for private: exclusive, confidential, undisclosed, self-contained, discreet, isolated, hidden, concealed.

Thinking of the meaning of each of these words individually, and then combined as a whole, and about how their meanings can apply to a web browser experience, it's not just reasonable, but logical to expect that information entered into a "Private" window will not be shared behind the scenes with all other private windows.

This is especially jarring for me to observe occurring between private windows, because when testing the same scenario, but between a single standard window and a single private window, the isolative operation between the private and standard windows is as I would expect.

Is there a configuration option that can be set to make Firefox work the way I was expecting?

(In reply to Chris Preimesberger from comment #2)

Thank you for your quick response and consideration.

Respectfully, I think that should be the case because the Private Browsing feature is named with the word "private".

And what you do in private browsing is private -- up to a limit. It can never be completely private - your computer still needs to connect to the network, and to the websites you load, and those can observe (to some degree, depending on the specifics) what is happening. That is also explained on the page that shows up when you open a private window ("While this doesn’t make you anonymous to web sites or your internet service provider..." ) and in more detail on the "Common myths about private browsing" link.

I think we're comfortable with the naming as it is here, and creating what you're asking for is far from trivial, with quite limited benefit.

Thinking of the meaning of each of these words individually, and then combined as a whole, and about how their meanings can apply to a web browser experience, it's not just reasonable, but logical to expect that information entered into a "Private" window will not be shared behind the scenes with all other private windows.

"shared behind the scenes" makes it sound like we're doing work to share things across windows. That's not the case. Rather, this is what happens without deliberately partitioning this information -- we have a cookies database, and we have to somehow indicate which data belongs to private browsing, and which doesn't (and ensure we don't ever write the private data to disk, and that it is deleted from memory once you close all private browsing windows). Originally, before private browsing existed, all website data was stored in single databases/containers. For private browsing, we had to separate this out. To allow unlimited private windows that are all separated, we'd have to allow for the data to be separated even more. That's a lot of work, for questionable benefit. It's also not clear how the UI for it would work - what happens for sites that open popups (do they get "disconnected" from their opener? How do you surface to the user that those popups are in the same private container as the site from which they opened? etc. etc.) and various other edgecases.

Is there a configuration option that can be set to make Firefox work the way I was expecting?

No. You can use containers, and especially add-ons like temporary containers, to get similar behaviour - but unlike for private windows, history etc. will be stored on your machine, so there are also downsides to that approach. It depends why you would want this functionality.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(ccpisme)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.