Closed Bug 556958 Opened 12 years ago Closed 12 years ago
Private Browsing Leak: Beginning a download causes data to be written to hard disk without consent
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:184.108.40.206) Gecko/20100401 Firefox/3.6.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:220.127.116.11) Gecko/20100401 Firefox/3.6.3 Normally, when you begin a download in firefox, it begins downloading before you confirm the prompt (a file with a .part extension is created, and data downloaded to there until the download is confirmed or aborted). This can be demonstrated by downloading a file, and waiting a short time to confirm - when you check the download's status immediately after, a portion of the download will be already complete. This behaviour continues through to private browsing. This opens the user up to being tracked by other users of the same machine, as Firefox does not (to my knowledge) securely delete the .part file, making it trivially easy to recover. In the event of firefox being terminated improperly, the .part file will be retained, regardless of whether the user confirmed the download or not. It is also possible that the user may not have even requested the download, and that it triggered automatically. Reproducible: Always Steps to Reproduce: 1. Enter private browsing 2. Trigger a download, but do not confirm it Actual Results: The download is being written to the hard disk, regardless of confirmation. Expected Results: Firefox while in private browsing should not, if at all avoidable, write data to the hard disk without the consent of the user. Possible resolutions: Do not actually begin the download until the user confirms the action. Securely delete .part files for aborted downloads when in private browsing. Store the downloaded data in RAM until the user confirms the download.
I don't see the .part being created until the user clicks "Save" and chooses a download location.
What platform? Windows my create it as a hidden file.
Also, you can confirm the issue by checking the %age progress of the download after clicking confirm. If it doesn't start at 0%, it's being written to disk somewhere.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100402 Minefield/3.7a4pre ID:20100402051154. Not seeing this at all. Please create a new profile. http://support.mozilla.com/en-US/kb/Managing+profiles. All downloads I do start at 0%, unless they are so fast that it just zips right on by.
A quick adventure with process explorer tells me that on windows the .part file is first created in %temp% then moved or copied to the download directory on confirmation. Just checked on the latest minefield 3.7a4pre (dated Apr. 2) and was able to reproduce. Not sure why you're not seeing this behaviour. Maybe a security-enhancing addon?
Kicking over to DM. No, no addons. Even safe mode.
Component: Private Browsing → Download Manager
Product: Firefox → Toolkit
QA Contact: private.browsing → download.manager
Yeah, this will happen, but we aren't recording history of where you've been. I think this is WONTFIX.
The reason why the download is started in the background is that the connection can not be closed. Closing the current connection and opening a new connection, requesting the file again after the user agreed to download it, would be bad because the file could be different or already gone.
If it can't/won't be fixed because of technical limitations, then it should be documented, preferably somewhere like about:privatebrowsing so the user is aware.
(In reply to comment #9) > If it can't/won't be fixed because of technical limitations, then it should be > documented, preferably somewhere like about:privatebrowsing so the user is > aware. I'm not convinced it violates our current rules about private browsing, but ehsan knows best, so we should wait for him to chime in.
The downloaded file being written to the temporary folder is not a privacy risk, because we're not saving the file's URL on disk, therefore we're not revealing users' browsing history. Resolving as INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.