Turn each private browsing window into a separate session
Categories
(Firefox :: Private Browsing, enhancement, P3)
Tracking
()
People
(Reporter: anabigmind, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
- Open a firefox mozilla browser window in private browsing mode (New Private Window).
- Login into gmail service
- Open one more "New Private window" browser and if we go to gmail it takes us inside the gmail session opened in step 2 without login.
Actual results:
From one private window browser we are able to get the sessions created in another private window browser. I am able to go to the same gmail session of one private window browser in another private window browser. There is no privacy among the private windows of the browser.
Expected results:
The session information from one private window of the Firefox browser should not be visible to the other private window of the Firefox browser. So If I am opening a gmail account in one private window, it should not be visible in another private browser window.
|
||
Comment 1•5 years ago
|
||
Not an exploitable security issue.
|
Reporter | |
Comment 2•5 years ago
|
||
Will it not be a security issue if somebody opens a private window and opens an important website (say for e.g. bank account). Thinking that this window is a private window, he may open another private window which may download some mailicious content which might be able to view/download the personal information (like banking information in this case) from the first private window.
Is this not a security issue then?
|
||
Comment 3•5 years ago
|
||
Turning this into an enhancement request...
Maybe not strictly related to the issue in comment 0, but I was surprised by the following behavior (and I think it's relevant to this bug) :
- Make sure there are no private windows yet.
- Open new private window.
- Go to godbolt.org, notice the website privacy policy notice is displayed, click "Close".
- Type something in the editor (just to modify the initial text, it doesn't need to work).
- Open a 2nd private window.
- Close the 1st private window (with godbolt).
- You can optionally repeat 5&6 any number of times, as long as there is always a private window open at any time.
- Go to godbolt.org again.
Expected:
New godbolt session, starting with the privacy notice and initial code.
Actual:
No privacy notice, the modified code from step 4 is visible.
So this means that as long as there is at least one private window, the private "session" never ends!
I initially thought there was a bug when I opened a window to godbolt.org and saw some old code in there; there must have been a private window still open elsewhere out of view. 🤔
If having a private session per window is technically challenging, I would suggest opening a separate bug to make it more obvious when opening a new private window, that there are already other private windows, so you're not really starting a new private session.
Maybe there could be a noticeable number of windows next to the purple mask icon, and/or the new window tab could be named "Private Browsing [2/2]", and/or something else on the screen that makes it clear that you're not starting from a blank slate.
Other browsers (e.g. Brave) properly implement private windows.
The Firefox implementation is just dumb.
On Brave:
Login to webmail in non-private window
Open Private Window
Login prompt appears again (i.e. as expected, no session tokens shared across non-private <-> private boundary)
Meanwhile, due to some Firefox thinks its perfectly ok to share accross non-private <-> private boundary ?!?!
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 10•6 months ago
|
||
(In reply to :Gijs (he/him) from comment #1)
Not an exploitable security issue.
Hi, would you mind adding some insight on why you consider this issue is not representing a security or data security exposure? The selected problem type "enhancement" seems rather random too. Why do you consider this an enhancement?
Given that this is problem popping up for a while now according to the history of this bug report but has not been fixed leaves somewhat the impression of an intentional implementation - works as designed or probably categorized and rated incorrectly?
Thank you for some additional hints.
R
|
|
||
Comment 11•6 months ago
|
||
(In reply to rabbithole from comment #10)
(In reply to :Gijs (he/him) from comment #1)
Not an exploitable security issue.
Hi, would you mind adding some insight on why you consider this issue is not representing a security or data security exposure?
I didn't say that it was not related to (data) security, but that it was not an exploitable security issue. The user makes their own choices about where to open a given site. This isn't a case where a malicious 3rd party actor is somehow exploiting a flaw or bug in a particular bit of the browser, that then leads to the user being insecure, without them having any control or remedy. It's instead a design decision that was made a long time ago, when the world was different, and any risk is purely down to how the user decides to use the browser.
The selected problem type "enhancement" seems rather random too. Why do you consider this an enhancement?
I didn't change the type, though I don't think it's wrong either. It also doesn't really make a difference to how the bug is treated, so frankly it's just not important. Anyway, the browser works the way it was designed to work. Changing the design is non-trivial. This is different from a 'defect' where the design says one thing and the browser behaves differently because the code is imperfect.
Given that this is problem popping up for a while now according to the history of this bug report but has not been fixed leaves somewhat the impression of an intentional implementation - works as designed
It works as it was designed originally. We can always change the design. It's not trivial but it is possible, and given what other browsers do this may be desirable.
or probably categorized and rated incorrectly?
I don't think so. Firefox is nearly 20 years old and some of the codebase is older. The fact that some bugs are old and/or have not been fixed does not mean that they won't be or are invalid or "rated incorrectly". We do not fix bugs in the order they were filed.
|
|
||
Comment 12•6 months ago
|
||
Thank you for your swift reply and I appreciate your clarification.
Unforatunately, I can't follow your arguments completely. Pershaps we don't understand each other correctly.
Of course, architectural adjustments are complex and have far-reaching implications. However, a privat browser session that allows data access doesn't make sense to me given my expecation that every privat session should function independendly, similar to a sandbox environement.
Certainly, people avoid opening a malicious pages intententionally, but it happens. I consider it beneficial that exposures or exploitations remain locked within that particular session rather supporting free access across all sessions.
If this is not a bug as you suggested but an architectural decision and a desired feature, the purposes or benefits elude me. I still consider this somewhat a security issue not only data security problem because the logic on that malicious page can access data of all other privat session hence gain data that can further be eploited in various types of attack.
Apart from that. Who would employ a privat session for data leakage or why would one introduce a privat session feature but than leaving data flow freely among the sessions. as both can be achieved easily outside of a privat session.
I'd like to mention that isolated sessions where made available before. The decision to have this gone was not taken decades ago but more recently which is why I thought this might be a bug.
Thank you for considerations.
|
||
Comment 13•6 months ago
|
||
(In reply to rabbithole from comment #12)
I'd like to mention that isolated sessions where made available before. The decision to have this gone was not taken decades ago but more recently which is why I thought this might be a bug.
I'm not aware of any recent changes to private browsing behavior. There was never per-window separation AFAIC.
Description
•