Download scanning performance

Paolo Amadini paolo.02.prg at
Fri Aug 23 10:18:28 UTC 2013

Hi all,

while designing the new Downloads API, we've been thinking a lot about
how to approach the performance issues we have on Windows that are
related to IAttachmentExecute, that is the Windows API that handles the
Security Zone Policy and one method of download scanning integration.

This is a complex topic and I feel it's due time for a firefox-dev
thread, to evaluate the trade-offs between performance and operating
system integration, and to see if there are any requirements we're not
aware of.

The issues we have are related to scanning integration (some of them
are listed at the end of this message), not specifically to the Security
Zone Policy. Notably, we often experience complete hangs on scanning.
However, the API that assigns a Security Zone to a downloaded file is
the same that triggers the scan, so one problem can't be solved without
thinking about the other.

Our current integration code, "nsDownloadScanner.cpp", is complex and
tied to the old Download Manager. The bugs we have on file are difficult
to address, because they depend on third-party antivirus software and
operating system behavior.

So, we would like to avoid porting the scanning integration to the
new Downloads API, in Firefox for Desktop. Metro Firefox is already
planning not to implement scanning integration now (bug 801094).

Our motivating assumption is that the on-access scan that all modern
antivirus software already does continues to guarantee security. We have
probably already solved hangs with on-access scan (like bug 444467) by
moving file handling off the main thread.

The issue with that is that we would not be able to assign a Security
Zone to the file based on the operating system policies. We could still
use the OS.File API to assign the Internet zone to all downloaded
files, without blocking the main thread. This would instruct the
operating system to show a prompt before opening downloaded executables.

The Application Reputation API (bug 662819) would still provide
blacklisting of untrusted sites, while the trusted sites whitelist
and the Intranet zone would not be applied to downloaded files.

The other alternative we see is to reimplement the scanning integration
code, with significant more development effort and with a higher chance
of keeping the same performance issues we had at the end of downloads.


List of some of the scanning issues, found with a very quick search:
"Whole browser should not hang while download file is built/scanned"
"Sometimes after the download completes it scans for viruses and it
doesn't stop ever"
"Download manager never finishes 'Scanning for viruses...'"
"Downloaded file disappears after scanning for viruses"
These are 7 more bugs, marked as dependencies of 443215.

More information about the firefox-dev mailing list