Closed Bug 493151 Opened 16 years ago Closed 7 years ago

Privacy risk when clearing history in combination with private browsing

Categories

(Firefox :: Private Browsing, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: franktanque, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: privacy, uiwanted, Whiteboard: [testday-20121012])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) It is possible for a user to inadvertantly let another person discover a webpage they visited even after clearing the history. Reproducible: Always Steps to Reproduce: 1. Launch Firefox 2. Browse to a page 3. Clear the recent history 4. Enter private browsing mode 5. Close Firefox (note: don't leave private browsing mode) 6. Launch Firefox Actual Results: After launching Firefox in step 6, the page that I was viewing when I cleared the history in step 3 appears, instead of my homepage. Expected Results: I'm just a simple Firefox user, so I don't know if this behavior is by design. However, there are times when I clear my history to remove sensitive information from my computer. If I were to stop at step 5 and another person were to then use the computer and launch Firefox, they would discover (one of) the webpage(s) I was trying to keep private, thus defeating the point of even clearing the history.
Version: unspecified → 3.5 Branch
This is not a remote exploit and doesn't affect the current release: unhiding the bug to reduce roadblocks to getting it looked at. Ignoring private browsing for the moment, step 3 clears *history* -- that is, what happened in the past -- and doesn't change the fact that you are currently on page X. If you crashed now your session would be restored, right? Now you suspend that session and enter private browsing. You then quit without restoring that saved session -- it didn't get a chance to shut down cleanly, effectively it "crashed" and therefore gets restored. CC'ing private browsing folks for input but this behavior sounds more or less correct. Your choices in this scenario are a) surf to a non-sensitive page before step 3 (clear history) you weren't in private mode yet! b) leave private browsing before step 5 (quit) There may be room for UI improvements, and if there's no "bug" maybe this could be turned into an enhancement request (RFE) for those improvements. At step 6 it'd be much clearer what was going on if the browser presented a restore dialog, giving the user the choice of starting fresh or restoring the closed pre-private session (wording could be customized to make it clear it was a suspended session rather than a crash). Of course if it's the roommate who gets that dialog that kind of defeats the point, but if the user sees that once or twice they may learn about the need to do a) or b) above. Probably better would be to interrupt step 5 with a dialog noting the suspended session (kind of like the quitting-with-tabs dialog when closing), giving the user some options. Choices might be cancel shutdown vs. shutdown with session saving save session (as now) vs. forget about it and quit all the way The dialog might be conditional like the quitting-with-tabs: if the user has the "use my tabs from last time" homepage then just quit (as now), but if the home page is set to something else then ask the user what to do.
Group: core-security
Component: Session Restore → Private Browsing
Keywords: privacy
QA Contact: session.restore → private.browsing
This might be a dupe of bug 463553... if not a dupe, then a dependency. The real problem here is that the CRH dialog does not clear open tabs, and as Daniel stated in comment 1 this may cause privacy concerns even without the private browsing mode being involved. CCing Alex for input here, and setting a dependency on bug 463553 for now.
URL: any
Depends on: 463553
Keywords: uiwanted
Whiteboard: [dupe of bug 463553?]
Thank you Ehsan. I've never developed nor debugged Firefox so my Bugzilla searching skills are probably not up to par. It does appear that this bug is a dependency of bug 463553.
Reproducible with Nightly 20121011030552 Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0, though I had to “restore previous session”.
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [dupe of bug 463553?]
Version: 3.5 Branch → Trunk
Whiteboard: [testday-20121012]
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm going thru the PBM bug backlog and closing bugs without reliable Steps to Reproduce. I couldn't reproduce this bug, so it has either been fixed or overcome by other changes. Please re-open with reliable STR if you still experience this.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.