1546969 - Privacy leak in private browsing mode via downloading data

Status: NEW

(Toolkit :: Downloads API, defect, P3)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

1. Firefox is configured to always ask where to store a downloaded file and also permanent private browsing mode is enabled.
2. On a website I started a download (either automatically or manually) and did not decide where to store it and just left the dialog open.

Actual results:

In %USERPROFILE%\AppData\Local\Temp a file with the content of the download was stored.

Expected results:

The downloaded data should never touch a permanent storage in private browsing mode (to go into an extreme but probably common example: Most people would probably not be amused if they surf on lewd sites and a download popup would leak now their sexual preferences to other people). There are a few potential solutions:

• When the download dialog pops up to ask where to store the file no pre-downloading should happen.

• The pre-downloading could be done in memory (probably with a hardcap).

Additional information:

On the other hand it leaves the question about the evaluation of the default option for the download location where all data is just stored into Downloads. Since downloading any data is not a guaranteed very explicit operation (as downloads can be triggered automatically by websites or you can't go easily sure that a link will trigger a download) the default option would leak data in private browsing mode too.

Comment 1

[Luciana queirolo]

Hi sworddragon2;

Was this behaviour always like this for you? or is it something that changed recently.

Set the component to Downloads Panel.

Thanks

Comment 2

[sworddragon2]

I think the download manager did pre-download files even years ago. But I don't know if this information was stored on the disk too at this time - but I would guess so. But since I use permanent private browsing mode recently I noticed this might be an issue here.

Comment 3

[Marco Bonardo [:mak]]

A download indeed starts in background on the network stack, before the file picker dialog is shown, then the file is moved to the chosen destination. This happens in DownloadLegacy.jsm, and it's due to the way nsITransfer works. Basically the download API "imherits" the download from the underlying code and wraps it.
It should be possible to change this, but it looks like a non-trivial amount of work, for which maybe it could be possible to implement a workaround removing data when the PB session ends. I'm not sure whether the current code does any special handling of these temp entities when the PB session ends, at least it should remove them.

Comment 4

[sworddragon2]

(In reply to Marco Bonardo [::mak] from comment #3)

for which maybe it could be possible to implement a workaround removing data when the PB session ends. I'm not sure whether the current code does any special handling of these temp entities when the PB session ends, at least it should remove them.

On my test the temporary data in %USERPROFILE%\AppData\Local\Temp is removed once I cancel the download or if I do choose an explicit destination so cleaning up those temporary files seems to be already implemented.

Out of curiosity a few days ago I checked if the files are actually encrypted in private browsing mode and thus making this report probably bogus. But it appears this is not the case and thus I'm just throwing the additional idea in to encrypt the data with a key that is generated/kept in memory for the private browsing session just in case this could make solving this issue less trivial (but I guess the opposite is the case).

Comment 5

[dannon.wassim]

This is a pretty severe leak for private browsing mode, especially for the Tor Browser Bundle. See the ticket that breaks one of the core design goals of TBB here: https://trac.torproject.org/projects/tor/ticket/7449

Could the severity of this bug be confirmed for the private browsing mode of Firefox itself? Please note that the temporary file is already saved before the user chooses an option in the "What should Firefox do with this file?" dialog. This means that any clicking of an ordinary link can cause something to be (temporarily) stored on the hard-drive of an unsuspecting user.

Comment 7

[sworddragon2]

A slight note: With the new default download behavior the location in the "Actual results" changed from %USERPROFILE%\AppData\Local\Temp to %USERPROFILE%\Downloads (or possibly any other location the user set in Firefox as default download location) since the file picker window is opened immediately and during that the content of the download is stored in the Downloads folder as *.part.filename_extension .