556958 - Private Browsing Leak: Beginning a download causes data to be written to hard disk without consent

Status: VERIFIED INVALID

(Toolkit :: Downloads API, defect)

Description

[Adam Bishop]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.3) 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.

Comment 1

[Tyler Downer [He/Him]]

I don't see the .part being created until the user clicks "Save" and chooses a download location.

Comment 2

[Adam Bishop]

What platform?  Windows my create it as a hidden file.

Comment 3

[Adam Bishop]

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.

Comment 4

[Tyler Downer [He/Him]]

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.

Comment 5

[Adam Bishop]

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?

Comment 6

[Tyler Downer [He/Him]]

Kicking over to DM.

No, no addons. Even safe mode.

Comment 7

[Shawn Wilsher :sdwilsh]

Yeah, this will happen, but we aren't recording history of where you've been.  I think this is WONTFIX.

Comment 8

[Matthias Versen [:Matti]]

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.

Comment 9

[Adam Bishop]

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.

Comment 10

[Shawn Wilsher :sdwilsh]

(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.

Comment 11

[(no longer active)]

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.