-private is effective for one window; not permanent private browsing
Categories
(Firefox :: Private Browsing, defect, P3)
Tracking
()
People
(Reporter: grahamperrin, Unassigned)
References
()
Details
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:56.0; Waterfox) Gecko/20100101 Firefox/56.2.6
Steps to reproduce:
-
firefox -private
-
observe the private window
-
new window
Actual results:
-
no hint that browsing is private (bug 1048286) and truly, it is not private
-
visit a non-historical site
-
the visited site is in history.
Expected results:
- permanent private browsing.
Bug first observed with Firefox 64.0.2 on FreeBSD-CURRENT,
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sun 20 Jan 2019 11:30:14 GMT
FreeBSD 13.0-CURRENT r343023 GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' firefox
www/firefox 64.0.2,1 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %
Reproduced with 63.0 in Lubuntu 18.10.
Reference: https://developer.mozilla.org/docs/Mozilla/Command_Line_Options
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Is this a regression from an earlier version of Firefox? If so, could you use http://mozilla.github.io/mozregression/ to help track down when it regressed?
|
|
Reporter | |
Comment 2•5 years ago
|
||
Is this a regression from an earlier version of Firefox?
Given the 2014-08-04 reopening of bug 1048286 for the indicator, I assume that (yes) permanent private browsing did work, albeit without its indicator, around the time of Firefox 31 (released a little earlier, 2014-07-22).
There's a comparable bug with Waterfox https://github.com/MrAlex94/Waterfox/issues/844, version 56.0 of which was based on Firefox 56.0.2, so (loosely) I guess that the regression occurred somewhere between 31 and 56.
mozregression
I used it only once before, on a very slow Mac. I'll see how I get on with Lubuntu in a virtual machine.
|
|
Reporter | |
Comment 3•5 years ago
|
||
/me hits mozregression bug 1503358
|
||
Comment 4•4 years ago
|
||
-private forces Firefox to enter permanent private browsing mode (same as "Never remember history" - bug 1403181, which is the same as setting browser.privatebrowsing.autostart to true).
This bug is identical to bug 1048286, at least based on my reading of the current source code.
|
|
Reporter | |
Comment 5•3 years ago
|
||
Please, are you certain that this is a duplicate?
With bug 1048286 you can explicitly open a new private window that is truly private but lacks the required chrome.
With this bug 1521372, Control-N produces a window that is not private.
|
|
Reporter | |
Comment 6•3 years ago
|
||
… more specifically:
browser.privatebrowsing.autostarttrueis effective (if we ignore the absence of the chrome that's expected with a private window) – tested with two windows in a new profile- if you revert
browser.privatebrowsing.autostarttofalsethen quit, the next start with option-pis not so effective
– the second window (the window that is opened with Control-N) truly lacks privacy (easily proven by checking history after performing a Google search).
|
|
Reporter | |
Comment 7•3 years ago
|
||
Above, a typo. I meant -private (not -p). Sorry.
|
|
||
Comment 8•3 years ago
|
||
Well according to the frontend the window is private (https://searchfox.org/mozilla-central/rev/ca22dc040c3a6f9257efdaedec848bb48334f8bd/toolkit/modules/PrivateBrowsingUtils.jsm#57,60,70), but the backend only relies on the browser.privatebrowsing.autostart pref to determine whether permanent private browsing mode is enabled: https://searchfox.org/mozilla-central/rev/ca22dc040c3a6f9257efdaedec848bb48334f8bd/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1085-1089
A way to resolve this problem for the Ctrl-N case is to replace the condition at https://searchfox.org/mozilla-central/rev/ca22dc040c3a6f9257efdaedec848bb48334f8bd/browser/base/content/browser.js#4670 to also account for PrivateBrowsingUtils.permanentPrivateBrowsing
Plus a unit test to avoid future regressions.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 9•1 month ago
|
||
Reviewing, with Firefox 124 on FreeBSD 15.0-CURRENT, and an existing test profile.
firefox -private -P test
about:privatebrowsing appears, with:
You are currently not in a private window.
Open a Private Window
Accept the invitation, then visit https://www.freshports.org/.
Control-N for a new window, then visit https://bugzilla.mozilla.org/show_bug.cgi?id=1521372.
Quit.
firefox -P test
History includes this Bugzilla page, but not the FreshPorts page.
tl;dr still bugged; the second new window was not private.
Description
•