good discussion guys.
Heres a scenario… IF a novice user installs cavs and does not tinker with the settings at all, scheduled scanning wouldn’t be needed would it? since real time is actively scanning.
Indeed I agree with you and I support those willing to take this approach and acknowledge that defaults are meant for them to change at runtime.
IMHO is reasonable to encourage anyone to own the application they are willing to use rather than inducing them to believe they are owned by defaults.
So I guess the question would be:
Is it really unneeded and time-consuming a weekly scheduled scan to the point of asking to change the defaults provided by the installer instead of changing them once after installation?
That would also be a wise choice, Endymion. It brings the user into the role of deciding his own protection standards over letting someone else decide what they should be.
This point is slightly misleading, as the real time scanner will scan the .zip when you open it. It just isn’t scanned when the .zip is written to disk.
Please then tell me how should I rewrite it and I’ll edit my post 
although just few lines before that I already pointed out that the realtime scanner will detect new uncompressed files written on the HD. 
Whenever zipped files are automatically extracted(uncompressed) when you open them only to see a list of their contents it is something I was unable to assume.
In cases that opening a zip will cause samples to be extracted the realtime scan will obviously detect those newly created files long before execution .
But it is not that opening a zip file will always cause the samples contained therein to be extracted and thus detected (nor that I clam to know all zip applications out there).
I don’t think you need to rewrite it. I was merely pointing out that the realtime scanner doesn’t overlook .zip files when it comes to execution. Your point made it sound like .zips were unsafe.
Sorry, poor terminology on my part. If all you are doing is exploring the .zip file (Context menu Open merely to see what the .zip contains) a scan isn’t instituted. Accessing any of the files within (While exploring) or extracting the contents will trigger a scan.
Interesting discussion…
Any malware “on the way” to execution will be caught by realtime scanner.
so its fair to say that only the idle malware will be caught by on demand scanners. (idle malware is not executing hence can’t cause damage until it gets executed, in which case realtime will catch it)
Of course assuming that AVs treat the scanning process of realtime scanners same as on demand scanners.
Melih
I don’t think it’s needed, and i always disable scheduled scans if they are on by default.
I don’t even do manual scans very often, actually i only do manual scans if the real-time-protection have detected something.
And i only do use the right-click scan if i have downloaded something, or connected an USB-stick, that have been connected to another computer.
We could be asked doing installation. But i really don’t care, if it’s Opt-In or Opt-Out by default.
And if it’s Opt-Out by default, it’s not hard to stop the scan, and disable the scheduled scans.
For novice users, i do think it rather should be Opt-Out by default, then Opt-In.
Exactly my point–an idle piece of malware can be detected and removed by a scheduled scan before it even gets a chance to try to execute. Since there always exists the possibility for a new malware package with a timed release payload to slip through real time scanning before the database has been updated to detect it, I feel that scheduled scans are a good thing to do. As I have stated, exactly the scenario I present did happen to me with the Navidad virus back when it was new. Only a scheduled scan saved me from getting the payload which as I recall was rather nasty and difficult to remove if it did trigger. From that time forward I have always allowed scheduled scans. You can say all you want that the realtime scanner will detect it when it tries to execute but I’d rather not have it even get the chance if possible.
Creating mirror options for the setup with the consequence of creating corresponding defaults is not going solve anything.
Users assuming that defaults should be preset to they own individual preferences rather than meant for them to change will raise a paradoxical scenario where users with opposite preferences ought to be addressed by the same presets without anyone willing to change the options but rather demanding those presets to be changed.