438905 - Option to disable background-downloading while waiting for user confirmation

Status: REOPENED

(Toolkit :: Downloads API, enhancement)

Description

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre

I noticed Firefox starts the download of a file in background even if the Save dialogue is not confirmed. I think it's better to add an option to disable this, for security. This could be a big problem with viruses.

Reproducible: Always

Steps to Reproduce:
1. Go to a page with a big file to be downloaded, for example the page reported in URL section
2. Click the download link. When the Save dialogue appears, do not confirm it for some minutes.
3. Confirm the download
Actual Results:  
File was downloaded in background and the download is already finished, or a part of the file is already downloaded.

Comment 1

[Daniel Veditz [:dveditz]]

Confirming because this is a reasonable enhancement request. Even if Firefox prefers the current method other Gecko-based products may want to change the behavior (but then what component would this be in?).

Users who pay for their connection based on amount consumed also have a need for this kind of option.

Clearing the "security-sensitive" flag though: this is known behavior (and collects a fair number of complaints). It's primarily done to improve perceived performance: most of the time the download is wanted by the user, and this gives them a head start while they figure out where they want to save it; if the user doesn't want the file we throw away the downloaded part.

Although it isn't the reason we do this, you could even argue that the current behavior enhances security: if the user has an active anti-virus program the file could be scanned and any evilness detected before the user chooses to officially save it (if the file is small enough).

Comment 2

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #1)
> Users who pay for their connection based on amount consumed also have a need
> for this kind of option.

This is true. I think if an option will be created, it could be asked at the first start of Fx if you want to turn it out (in an advanced first config). It could be added also some options for high/low performance machine and fast/slow connection. I know is out of the scope of this bug, it's just an idea.

> Although it isn't the reason we do this, you could even argue that the current
> behavior enhances security: if the user has an active anti-virus program the
> file could be scanned and any evilness detected before the user chooses to
> officially save it (if the file is small enough).

Mh. I don't know very much about, but even if the file has not an executable extension, it can't be executed by Java code, for example?

Comment 4

[Matthias Versen [:Matti]]

The reason why we do this is different:
Gecko must ask the server for the file before it can display the save as dialog because it needs the content type of the requested URL.
Requesting the URL and you get already the file, gecko can abort it (cancel the TCP/IP connection) and wait for the user to accept and select a destination but that could mean that the server sends you a different response which could result in a failed download. The best solution would be to throttle the download to a minimum download speed (0.01k/s) and I think we added throttling support already in Gecko but I'm not sure.
biesi should know more about that.


It can not be executed unless you start your finished download which should be in your temp directory.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

We do not have throttling in Necko at the moment.

What we could do is stop reading from the socket. I don't think that that's a good idea - if you take too long to select a directory the download would fail.

I don't see the problem with the current behaviour. Viruses are not harmful when they're not executed.

Comment 6

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #4)
> Gecko must ask the server for the file before it can display the save as 
> dialog because it needs the content type of the requested URL. [...] The best 
> solution would be to throttle the download to a minimum download speed 
> (0.01k/s)

A virus is very small usually, so it's not a solution. I think the best solution is to pause the download if this is supported by the server, or stop it otherwise.

> It can not be executed unless you start your finished download which should be
> in your temp directory.

But what if I'm executing some web application in languages like Java or Flash? Or some script in Javascript? They can't execute files on my pc?

Comment 7

[Matthias Versen [:Matti]]

>A virus is very small usually, so it's not a solution. I think the best
>solution is to pause the download if this is supported by the server, or stop
>it otherwise.

We don't discuss this because of security. We would mark such a bug invalid because because security is no problem.
The only reason why this bug is still open is that some people pay for their transferred data and that could be a problem.
Stopping can lead to other problems because the server answer can be different on each request, but I explained that already.
What do you do for example if the content-type for the second request sends a different content-type ? 
You have to ask the user again what to do with the file...

>But what if I'm executing some web application in languages like Java or Flash?
>Or some script in Javascript? They can't execute files on my pc?
Of course not. You can grant Java additional right but you get a big security warning where you have to accept that (example:online-Virus check utility). But in this case the applet can write a file on it's own and execute it.

The whole story is not new, we had this dicussions 6 years ago because this is core:File Handling and that's the same as in Mozilla1.0 (not Firefox) and Netscape6.

Comment 9

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Well, this bug is not a dup of bug 69938. See in particular bug 69938 comment #304

Comment 10

[matthieu.vergne]

Another issue with this background downloading: if one want to use a different downloader (e.g. Down them all! in my case), in the case of a download from websites like rapidgator, uploaded, eazyshare and others (which is quite frequent), as they allow only one free download at a time, with a restricted bandwidth and so on, if Firefox starts the download, it is not possible anymore for the other downloader to manage it.

For instance, click the download button on the webpage, the confimation dialog appear to confirm what to do with the link (while Firefox is already downloading it in background), then select the other downloader and confirm, which then starts the download in the other downloader while firefox cancel its own. Finally, the other downloader starts and make an error, because it was not allowed to download.

My suggestion is that, if Firefox have to start the download, for whatever reason, then what should be done is not to cancel and let restart, but to provide the necessary information to resume the download from the other downloader. Of course, this means that the other downloader should manage that. For that I see several ways:
- it could be possible to exploit the transfer protocol in a given way to switch completely to the other downloader without having the target (from which we download) noticing it
- firefox should play as a proxy, so that the download still pass through Firefox, but the one which rules the download is the other downloader

Anyway, for that to happen the other downloader should be able to manage requests for already started downloads (not only requests to start from scratch). For that, an API (standard or Firefox-specific) should be used, thus available to Firefox extensions and other external downloaders.

Comment 11

[Jan Henning [:JanH]]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> Confirming because this is a reasonable enhancement request. Even if Firefox
> prefers the current method other Gecko-based products may want to change the
> behavior [...]

Such as Firefox on Android. By default, we'd very much like being able to turn this while on metered connections for example.

Comment 12

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #11)
> [...] we'd very much like being able to turn this while on metered connections [...]

Turn this *on*, that is.

Comment 13

[Jan Henning [:JanH]]

As far as I can tell, we actually have some throttling capabilities now. If so, it would be nice if this could be leveraged to optionally (for Android we might want to turn this on by default) start downloads throttled and only unthrottle them when it's clear that we actually want to download the file, i.e. for those cases where we're showing the helper app dialogue not until the user has confirmed that they want to continue the download with Firefox (on Desktop, "Open with" seems to mean "Download a temp file and then open that in the chosen external app", so "download" or "open" wouldn't make a difference, but on Android we abort the download completely and only pass the URL to the chosen app to handle).