Closed Bug 1286621 Opened 8 years ago Closed 8 years ago

Private browsing mode leaks info to about:networking

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla51
Tracking Status
firefox51 --- verified

People

(Reporter: dylan.thayer17, Assigned: michal)

References

Details

(Whiteboard: [necko-active])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Open a private browsing tab
Type in www.kmart.com in the url bar
Go back to the regular (non private) window
Type about:networking in the search bar




Actual results:

You will find kmart under the DNS section


Expected results:

I would've expected nothing from my private browsing window to show up in about:networking.
Status: UNCONFIRMED → NEW
Ever confirmed: true
confirm you closed the private browsing window.. ?
no -- the pb window remained open.
try it again after you close the pb window (which has a history in it to inspect, after all).

There are bunch of things that are not particularly PB aware which flush their cache when the last PB window is closed, and it looks like DNS is one of them. So if that did the trick I would at least call it working as designed.

otoh - when you brought this up the other day I feel like I might have seen something in the DNS list that came from PB after closing it.. but I'm not sure, and it went away on me (which might have just been the cache timing out naturally..) so something might be broken.
I tested it and the information remains there after the pb window is closed. There is no action to "last-pb-context-exited" at https://dxr.mozilla.org/mozilla-central/rev/88bebcaca249aeaca9197382e89d35b02be8292e/netwerk/dns/nsDNSService2.cpp#948. I don't understand how the patch in bug 909050 should prevent showing DNS records from pb sessions.
Assignee: nobody → valentin.gosu
Whiteboard: [necko-active]
So, I rechecked, and it still behaves as agreed in bug 909050.
Once the last private browsing window is closed, the DNS cache will be cleared in nsDNSService::Observe()
Note that you must click the Refresh button in about:networking in order to see this change. After this, about:networking should report no DNS cache entries.

Dylan, can you check that this is the behaviour you're seeing?
If you think that there's something more we should do here, please reopen the bug. As noted in bug 909050 comment 0, maybe we should not report anything while a PB window is open, but I still don't think we have a notification for that. Maybe we should add one.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dylan.thayer17)
Resolution: --- → INVALID
It really doesn't work and I finally know why. It's a regression caused by bug 1161558. When the service is re-initialized in nsDNSService::Observe(), nsDNSService::Shutdown() removes observers but nsDNSService::Init() doesn't add them again because mFirstTime == false.
Assignee: valentin.gosu → michal.novotny
Status: RESOLVED → REOPENED
Flags: needinfo?(dylan.thayer17)
Resolution: INVALID → ---
Attached patch fixSplinter Review
Attachment #8779908 - Flags: review?(valentin.gosu)
Comment on attachment 8779908 [details] [diff] [review]
fix

Review of attachment 8779908 [details] [diff] [review]:
-----------------------------------------------------------------

That explains why I wasn't able to reproduce this :)
Thanks for digging into it!
Attachment #8779908 - Flags: review?(valentin.gosu) → review+
thanks! (please check it in too :)
Pushed by mnovotny@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4af8f838049d
Private browsing mode leaks info to about:networking, r=valentin
https://hg.mozilla.org/mozilla-central/rev/4af8f838049d
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Flags: qe-verify+
This issue is VERIFIED FIXED in Firefox 51.0b9 on Mac OS 10.11.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: