Closed Bug 412204 Opened 17 years ago Closed 17 years ago

Add a hidden pref to turn off virus scanning on downloads

Categories

(Toolkit :: Downloads API, defect, P2)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta3

People

(Reporter: jonathan_haas, Assigned: sdwilsh)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

Attachments

(1 file)

v1.0
3.55 KB, patch
jimm
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011305 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011305 Minefield/3.0b3pre

Many users report that they don't like the automatic anti virus scanning of downloaded files. 

See for example http://forums.mozillazine.org/viewtopic.php?t=614372 or http://www.firefox-browser.de/forum/viewtopic.php?p=423894#423894 (Firefox forum of german translation)

The most named reasons are that the scanning is unnecessary because the scanner would scan downloaded files anyway and because the scanning is slow because of some poor scanners. Some scanners might also scan the file twice now which probably does not make any sense.

Because similar bugs have been wontfixed I just write a bit more:

- IE does this too, but it looks like as if it does the scanning silently or allows the user to open the file while scanning. I can't test this now, but it should probably be investigated. 
- Imagine there is a problem with a scanner or the scanning just has to be disabled for debugging purposes. Currently it is impossible to disable scannung unless you delete your scanner out of your registry. There should be at least an about:config switch. (browser.download.antivirus.dontclean is not the pref you want!)
- Allowing the user to disable scanning is _not_ dangerous. Most scanners would scan the file anyway as mentioned before. And Firefox 2 does no automatic scanning, too, and is not insecure, is it?

Reproducible: Always




This bug is not a duplicate of Bug 393792, Bug 407657 or Bug 412094. I do not want you to add preferences UI or a cancel button, but you should solve the problems mentioned above.
Flags: blocking-firefox3?
Version: unspecified → Trunk
Keywords: perf
Bug 393305 is checked in, so we are now scanning with all scanners that are available. This will probably generate more negative feedback from these users. 

> Currently it is impossible to disable scanning unless you delete your scanner > out of your registry.

I think adding a pref for the power users would be a really great idea, but I wouldn't suggest disabling it by default.

Agreed - let's just do an about:config pref for power users...
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [needs assignee]
Blocks: 103487
Is it clear that only power users will run into intolerable delays and double-scans? It is not clear to me from reading this bug, prior bugs related to this one, or the forums thread.

/be
(In reply to comment #3)
> Is it clear that only power users will run into intolerable delays and
> double-scans? It is not clear to me from reading this bug, prior bugs related
> to this one, or the forums thread.
> 
> /be
> 

Is it clear that non-power users will understand what's going on?  are you just saying you want something in the pref's panel?
(In reply to comment #4)
> (In reply to comment #3)
> > Is it clear that only power users will run into intolerable delays and
> > double-scans? It is not clear to me from reading this bug, prior bugs related
> > to this one, or the forums thread.
> > 
> > /be
> > 
> 
> Is it clear that non-power users will understand what's going on?  are you just
> saying you want something in the pref's panel?
> 

To answer my own question -I was just suggesting a quick fix.  Given the MZ thread I think we either need to a) work with the AV vendors to not make the scans be so bad or b) make it easier than about:config to turn this off.
I don't know how to be more clear: it seems more than a few users are running into intolerable delays, and double scanning seems bad no matter what. Why would we ship this to any user? Prefs and user expertise have nothing to do with it.

/be
Stephend tested AVG free on it took 8s to scan a 13mb file on his vista box and
that is _very_ slow. This will affect all users and many people like Joe User.
All Users will blame us for the delay not only power users.
You have only a few options:

remove the feature : the files will be still scanned by the AV background 
                     process
hidden pref   : only for power users but this affects all users
UI pref       : again a new pref and grandma will not find that
cancel button : let it scan if you have time but you can cancel it if you 
                want to work with the file.This still sucks a little bit 
                if you want to launch a helper app with that file.
- scan without blocking the file 

(In reply to comment #7)
> Stephend tested AVG free on it took 8s to scan a 13mb file on his vista box and
> that is _very_ slow. This will affect all users and many people like Joe User.
> All Users will blame us for the delay not only power users.
> You have only a few options:
> 

Is that scanning directly or through the FF download manager?  What kind of system?  Perf numbers are not very helpful without full context of where they were run.  

> remove the feature : the files will be still scanned by the AV background 
>                      process

Not always before you run them.  That was the main point of this feature - to ensure, if you have AV installed, that it is run before you actually launch the file.

> hidden pref   : only for power users but this affects all users
> UI pref       : again a new pref and grandma will not find that
> cancel button : let it scan if you have time but you can cancel it if you 
>                 want to work with the file.This still sucks a little bit 
>                 if you want to launch a helper app with that file.
> - scan without blocking the file 

I'd also add that we could timeout and disable scanning if it takes a long time on a particular system.  

It would be great to get a better understanding on why these scans take so long - whether it is how we are calling them, crappy AV implementations, or just that it takes a long time.  Would also be great to understand how widespread this issue is and whether there are other remedies before we change things.




(In reply to comment #8)
> I'd also add that we could timeout and disable scanning if it takes a long time
> on a particular system.  
We have a bug on that, and it's requesting blocking.  See bug 409815.
I just downloaded this morning's nightly build, firefox-3.0b3pre.en-US.win32.zip, 22-Jan-2008 05:35 9.1M. It took 45 seconds to scan the file in fx3's Download manager.

System: Win XP SP2 on a 2.4GHz P4 with 1.25GB RAM. The version of Firefox was the 22-Jan-2008 05:35 nightly. Antivirus: AVG FREE 7.5.516, database released 2008-01-22. No other resident scanners (e.g.--no antispyware surveillance). Fx extensions: MR Tech Local Install, Inspector Widget and Toolbar Extras.

The performance has been consistent since the feature was added.
BTW - when AVG Free scanned the file by itself (from context menu) it took 25 seconds.
(In reply to comment #8)
> > remove the feature : the files will be still scanned by the AV background 
> >                      process
> 
> Not always before you run them.  That was the main point of this feature - to
> ensure, if you have AV installed, that it is run before you actually launch the
> file.

Right - also puts the scan results in the Firefox UI, which is a much better experience than having a download look like it succeeded in the DM only to fail when you try to open the file.
As long as bug 409815 lands, I'm still inclined to WONTFIX this bug (with regards to asking for a pref to disable).  Based on test results, it seems as though small downloads scan quickly, and larger downloads take longer to scan (this makes logical sense too - yay!).  So, a long download takes a while to download - what's another minute or two at most of scanning the file when the download took minutes to download.  The percentage of time spent on actually scanning the file is small compared to the time spent downloading.

As for allowing the ability to cancel a download - I've already WONTFIX'd that bug, with my reasoning in there (I'll leave it to those interested parties to find the bug).

As for removing the feature - that's completely out of the question this late in the game as far as I'm concerned.  Perhaps if this was brought up around beta 1 or 2, I'd be more receptive, but this has been in the tree for some time without much complaint until now.

As for allowing the opening of a file before the scan is complete, I think it's best summed up by Callek on irc:
<Callek> Matti: what is the case for someone to OPEN a file before the virus scan reads it
<Callek> "Ooops, that is a virus, but you've opened it, corrupting your entire OS install... we can delete it, but damage is allready done, please reinstall windows, do not pass go..."
Sorry, the line starting "As for allowing the ability to cancel a download - I've..." should actually read "As for allowing the ability to cancel a scan - I've..."
Download: 4sec.
Scan:    45sec.

I think one way to fix this as an issue is to put a big label on the scanning
process: "Firefox and your anti-virus program are scanning this file in
background. You can go back to browsing and doing other things while this is
happening." That way, people will be less put out by the process.

sdwilsh: comments here document 8-45 second delays, with the 45 second case beat by 20 seconds when the AV software was run directly, for downloads as fast as 4 seconds to complete. That's smoke if not fire. It needs to be dealt with other than by repeating WONTFIX resolutions of other bugs.

The answer is not a disabling advanced pref, or even a timeout to auto-disable the feature. At the least, some investigation of the disparity Ed reported (45 seconds vs. 20) should be done. Also, what about the reports of double scans? Even if that's just an AV software bug, if it's common the stink will attach to Firefox 3.

/be
IMHO, we should not assume double scans in cases where the interface we are latched into is registered by a particular anti-virus vendor. Norton and McAfee have apparently dropped support for this interface (bug 408153) - implying they handle scans transparently without browser involvement. If a vendor still supports the interface, shouldn't the assumption be it's still needed?

Two other issues are timing and unreliable scanners which are different issues - bug 409815 was posted to address timing and bug 412565 currently targets cases where scanners fail in unpredictable ways.

I'd suggest we figure out which vendors are responsible for timing and/or instability issues. From what I'm reading both may be related to a single vendor. If that's the case, we have the time to contact them and get their feedback before moving forward.

IMHO the overall goal here is "average" user security, we should keep that in mind before jumping to any conclusions.

>IMHO the overall goal here is "average" user security, we should keep that in
>mind before jumping to any conclusions.

I should add - while also giving power users the ability to take control of this process through prefs they can set. My opinion would be to expose that through the UI in "advanced" user prefs. 
(In reply to comment #8)
> (In reply to comment #7)
> > Stephend tested AVG free on it took 8s to scan a 13mb file on his vista box and
> > that is _very_ slow. This will affect all users and many people like Joe User.
> > All Users will blame us for the delay not only power users.
> > You have only a few options:
> > 
> 
> Is that scanning directly or through the FF download manager?  What kind of
> system?  Perf numbers are not very helpful without full context of where they
> were run.

Through the Ff download manager; the system is:

Dell Precision 390 X86-Vista-Ultimate, 2.93 GHz, with 4GB of RAM.  I too have seen us scan slower than both IE 7 and native AVG Free individual scans of the same file; in my brief testing, we're about 4-fold more expensive on some files.  Note that we're not always horribly slow; I scanned a 695MB ISO via the DM interface in 2 seconds, the same amount of time it took for AVG Free to scan natively.

> It would be great to get a better understanding on why these scans take so long
> - whether it is how we are calling them, crappy AV implementations, or just
> that it takes a long time.  Would also be great to understand how widespread
> this issue is and whether there are other remedies before we change things.

I've reopened bug 401582, because on two different systems--the Dell box, above, and a VMFusion image of Vista Business, I see that issue; it's a great testcase, which covers at least one facet of the total problem.

I'm up-cycling QA work on this particular issue as well, until we can get it sorted out.
(In reply to comment #17)
> IMHO, we should not assume double scans in cases where the interface we are
> latched into is registered by a particular anti-virus vendor. Norton and McAfee
> have apparently dropped support for this interface (bug 408153) - implying they
> handle scans transparently without browser involvement. If a vendor still
> supports the interface, shouldn't the assumption be it's still needed?

Don't ask me, but remember Samuel L. Jackson's words of wisdom ("The Long Kiss Goodnight"):

'...everyone knows, when you make an assumption, you make an ass out of "u" and "umption".'

Suppose we found only AVG free still used this interface, and it frequently or always double-scanned. We would not just point the finger and ship.

> Two other issues are timing and unreliable scanners which are different issues
> - bug 409815 was posted to address timing and bug 412565 currently targets
> cases where scanners fail in unpredictable ways.

You wrote in bug 412565 comment 5:

"Vista's Defender doesn't seem to experience this. I'm wondering if the virus
stuff we added is worth the risks we take in tieing directly to 3rd party apps
which may have stability issues."

I'm wondering the same thing, given all the smoke.

> I'd suggest we figure out which vendors are responsible for timing and/or
> instability issues. From what I'm reading both may be related to a single
> vendor. If that's the case, we have the time to contact them and get their
> feedback before moving forward.
> 
> IMHO the overall goal here is "average" user security, we should keep that in
> mind before jumping to any conclusions.

I hope you're not suggesting I'm jumping to conclusions. The shoe seems on the other foot, from the complaints I heard on IRC today and then read about in the forum: refusal to reconsider resolved bugs or unaddressed symptoms, until someone with nick Noah was calling my name. Really, I don't want to butt in here. There was smoke, and probably fire.

/be

I've made a call out to the already-active (and way ahead of me!) community for testing/reporting help, here:

http://forums.mozillazine.org/viewtopic.php?p=3228468#3228468
Blacklist AVG Free? Especially if it's already background scanning anyway.
> I hope you're not suggesting I'm jumping to conclusions.

No not at all. I think I'm leaning in the same direction as everyone else wondering 1) if this really provides our users any additional security, 2) even if it does, is it worth all the trouble we might run into with support when unreliable scanners are involved.

I haven't tried to contact any anti-virus vendor, maybe that's good next step. How would we do that, through some sort of official channel or just send them an email?

If the complaints are really mounting in number I think we should definitely consider disabling the code for a while to put out that fire.  
(In reply to comment #23)
> > I hope you're not suggesting I'm jumping to conclusions.
> 
> No not at all. I think I'm leaning in the same direction as everyone else
> wondering 1) if this really provides our users any additional security, 2) even
> if it does, is it worth all the trouble we might run into with support when
> unreliable scanners are involved.
> 
> I haven't tried to contact any anti-virus vendor, maybe that's good next step.
> How would we do that, through some sort of official channel or just send them
> an email?
> 

We have contact info for many of them since every FF update tends to get blocked by old virus signatures (grr) - Basil has them.


Regarding the double scanning issue:
The only argument I've seen about that is a theoretical one with people saying something along the lines of "a virus scanner should scan a file before I open it, so, why is Firefox scanning it as well?".  However, we don't know for a fact that a virus scanner will scan it before you open it (if it's any good, it certainly should).

With that said, any decent scanner will also know that it's already scanned the file when we call off to it as well, so it probably won't double scan.

I'm open to changing this, but I need to see an argument that is backed up with facts instead of speculation.  timeless just posted a great comment on bug 412565 which seems to be *very* helpful and the fix he suggested would probably be beneficial to this bug (short of the being slow).
sdwilsh: the measurements by Ed Hume aren't speculation. The double-scanning word on the street may have been -- I don't know -- but it wasn't getting good words back, and talking to users, even speculating ones, can be as important as trying to stand pat on known facts. End of sermon, I promise to shut up now.

/be
just an fyi, i'm collecting up some emails for vendors and will be sending out emails. I'll post back once I hear something.
Attached patch v1.0 — — Splinter Review 
This adds a preference to disable scanning.  Other issues discussed in this bug will be addressed in other blocking bugs (bug 409815 and bug 408153).
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Attachment #300057 - Flags: review?(jmathies)
Whiteboard: [needs assignee] → [has patch][needs review jimm]
Comment on attachment 300057 [details] [diff] [review]
v1.0

Tested - works fine here.
Attachment #300057 - Flags: review?(jmathies) → review+
Checking in toolkit/components/downloads/src/nsDownloadManager.cpp;
new revision: 1.160; previous revision: 1.159
Checking in browser/app/profile/firefox.js;
new revision: 1.269; previous revision: 1.268
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta3
Summary: anti virus scanning is slow and unnecessary → Add a hidden pref to turn off virus scanning on downloads
Some feedback from one vendor that removed support fro IOfficeAntiVirus - 

"The functionality provided by the API is typically required if you have
an AV product which doesn't have a file system filter driver to scan the
files before they are saved to the system.  Currently, most of the
AV products include the (filter driver) support by default
(except the free versions) and hence duplicate scanning would be done if
we use the interface also."

Hence the reason they dropped support for it. So far the assumption is if a vendor supports the interface we should support it and assume double scans do not occur.

oops - wrong bug.
actually - i need a cup of coffee, correct bug.

>just an fyi, i'm collecting up some emails for vendors and will be sending out
>emails. I'll post back once I hear something.
Whiteboard: [has patch][needs review jimm] → [has patch]
Verified FIXED using:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008020218 Minefield/3.0b3pre

This worked for me even in real-time (didn't have to restart Firefox, which was nice).
Status: RESOLVED → VERIFIED
Whiteboard: [has patch]
Blocks: 443215
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: