Is it possible to exclude certain folders from scanning?
Thank!
Page 1 / 8
Hi ljs199!
Welcome to the Webroot Community!
It is not possible to exclude specific folders from being scanned, but it is possible to run a custom scan.
To run a custom scan, open Webroot and select PC security from the menu on the left.
Under the "scan" tab, select the "cutom scan" link.
This will bring you to a screen where you can choose a quick, full, deep, or custom scan.
You can choose "custom" and it will only scan the files that you select.
I hope this information helps!
Thanks! 🙂
Welcome to the Webroot Community!
It is not possible to exclude specific folders from being scanned, but it is possible to run a custom scan.
To run a custom scan, open Webroot and select PC security from the menu on the left.
Under the "scan" tab, select the "cutom scan" link.
This will bring you to a screen where you can choose a quick, full, deep, or custom scan.
You can choose "custom" and it will only scan the files that you select.
I hope this information helps!
Thanks! 🙂
Hi georgeh,
I know how to run a custom scan, but I would rather not have to tick all boxes for the folders to scan. Ticking a couple of boxes for the folders I don't want to scan would be much more convenient.
I'm very disappointed in the program features.
ljs199
I know how to run a custom scan, but I would rather not have to tick all boxes for the folders to scan. Ticking a couple of boxes for the folders I don't want to scan would be much more convenient.
I'm very disappointed in the program features.
ljs199
Hi!
That makes sense, it would be very convenient to be able to do that. That would be a great idea to post in the ideas exchange! Who knows, maybe they'll consider making that feature available if you suggest that idea.
here's a link to the ideas exchange:
http://community.webroot.com/t5/Ideas-Exchange/idb-p/Ideas
Thanks!
That makes sense, it would be very convenient to be able to do that. That would be a great idea to post in the ideas exchange! Who knows, maybe they'll consider making that feature available if you suggest that idea.
here's a link to the ideas exchange:
http://community.webroot.com/t5/Ideas-Exchange/idb-p/Ideas
Thanks!
As a minor note, the developers and designers of the software explicitly did not include any function to exclude locations from scanning, as this kind of "feature" is similar to having a "front door key under your Welcome mat" feature. Sure, it's convenient, nifty to have, and for people who forget their keys all the time, it's priceless. But the cost to your home security is immense.
Excluded directories or locations are also a security hole, so were not included. We didn't want to allow people to easily and intentionally, but unknowingly create holes in their security.
Your voice will be added to the group who have requested this. After all, letting your requests be known is the only way to have change, right?
Excluded directories or locations are also a security hole, so were not included. We didn't want to allow people to easily and intentionally, but unknowingly create holes in their security.
Your voice will be added to the group who have requested this. After all, letting your requests be known is the only way to have change, right?
Kit wrote: Excluded directories or locations are also a security hole, so were not included. We didn't want to allow people to easily and intentionally, but unknowingly create holes in their security.This is one of the reasons I love running Webroot SecureAnywhere my "Blanket of Security" for my computer. It scans fast and there is no need to exclude any files from a scan. SecureAnywhere runs with other security software without problems and no need to exclude files. Excellent point that Kit wrote above. 😃
As an averagely intelligent adult I'm not overly impressed by the "it's for your own safety"-argument.
@ wrote:
As an averagely intelligent adult I'm not overly impressed by the "it's for your own safety"-argument.
What is the reason you believe the feature is necessary for this specific program?
Please keep in mind that this software does not work in the same manner as other security software, so "everybody else has it" or "Security software should have it" is generally not the best answer in this case. We're not doing things like Other Security Software because honestly, the other security software is losing the fight for security and annoying its customers quite effectively.
In this case, given the way the software works, we have yet to discover any reason that opening the huge security hole of excluded locations is warranted. We are well aware that there are people who either don't like us and never will, or feel that they absolutely need to have things their way, and we won't be able to make these people happy. No program is ever perfect for everybody, that is naught but a fact. After all, for example, we already know that many people who write malware really don't like the fact that we don't allow people to exclude locations from being scanned. We don't expect them to be happy with us anyway. ;)
That being said, again, we do welcome your input into why you would like excluded locations as a feature and why you feel that it would benefit the program and its users. Either it will be a good reason that we will take into consideration, or it will be an opportunity to explain for you why it won't help or how the way we work is different, or we will simply have to agree to disagree on the issue and you will need to decide about the software based on your own feelings and decisions.
Edit: Late night spell-checking.
For one, I have huge archives, ebook collections and other stuff that doesn't need to be scanned over and over again. I also have some password recovery programs that are always mistaken for a virus and then sometimes simply deleted (especially by Bitdefender).
Also, one of the reasons why I will never buy a Mac, an iPhone or an iPad is that Apple will happily sell you one, but they will not let you own it. The same goes for software. I run a tight ship on my PC. It's my livelyhood, so I don't take chances with it. If my computer breaks down or gets infected by a doomsday virus, I'm back were it left off in 10 minutes with a clean, healthy system. I know how it works and I like to be in charge and take decisions. I don't like software telling me what I can and what I can't do. But maybe that's just me ;)
But never mind, my mistake. I should have read the documention more thoroughly before buying. I reinstalled Norton.
Also, one of the reasons why I will never buy a Mac, an iPhone or an iPad is that Apple will happily sell you one, but they will not let you own it. The same goes for software. I run a tight ship on my PC. It's my livelyhood, so I don't take chances with it. If my computer breaks down or gets infected by a doomsday virus, I'm back were it left off in 10 minutes with a clean, healthy system. I know how it works and I like to be in charge and take decisions. I don't like software telling me what I can and what I can't do. But maybe that's just me ;)
But never mind, my mistake. I should have read the documention more thoroughly before buying. I reinstalled Norton.
There we go. Having the reasoning makes it easier to address your concerns. Keep in mind, you're not talking to a Corporate Stooge/Tier 1 tech here. You're talking to a real person with 17 years in the security industry who works here because it's the best solution out there. Yes, I frequent /. and Wilders and various others too. You'll also find a lot of Wilders users on here.
For one, I have huge archives, ebook collections and other stuff that doesn't need to be scanned over and over again.
Not a concern. We don't operate that way anyway, unless you're doing something silly like Full Scans regularly as opposed to the default deep scans. Remember, we're not the Other Security Software. We already know the eBooks can't contain threats, and we don't care about the archives. There's a reason we've been consistently the lightest and fastest since we came out. Simply put, the agent knows what can run, what is likely to run, and what will run. It doesn't worry about data files that cannot contain machine code, and in the event of things such as buffer overflow remote code execution, it uses a realtime system at that time rather than trying to determine which files could possibly cause an issue.
Trust me, my wife used to have to set to exclude her art directories (yay for monolithic high-resolution PSDs), and she doesn't anymore because even she recognizes that the agent doesn't even bother to glance at them.
I also have some password recovery programs that are always mistaken for a virus and then sometimes simply deleted (especially by Bitdefender).
This is a trickier one. No matter what else you use, you're stuck in a situation where "Ignore this file proactively" is a need in those cases. Norton requires you to ignore the file too. That being said, we -never- "simply delete". Will we detect things as "Hacking Tools" if they can be used for nefarious purposes? Yes. However unless you're uninstalling and reinstalling the agent frequently, this is a non-issue. A one-time "Put that back and ignore it" solves that issue without leaving the figurative key beneath your doormat.
Unfortunately, despite my own opinions and everybody else's, we really do have to do what's best for "The majority", so your much-derided "Because it's what's good for you" actions are necessary. While you may be able to recover from a severe infection in minutes, the majority of people can't and it's a catastrophic event.
I know how it works and I like to be in charge and take decisions. I don't like software telling me what I can and what I can't do.
Been there. Still there. Honestly, I get much greater granularity of control from WSA. Even Norton has limitations. Try telling it to use under 6MB of RAM while idle. Try telling it to "ignore the low level utilities in this directory, but please do catch any actual threat that goes in there"... The former is done by an exclude, but the second half of the latter is not-done due to the exclude.
It kind of sounds like you've been doing full scans. Don't. That's not an order, mind you. That's a recommendation. Don't waste your time making the WSA agent pretend to be a slow, old, bloated security client. It's just not necessary, nor does it really help anything. Plus it'll cause you to have more desire for exclusions. Under normal operation with deep scans, it works faster, more efficiently, and there is no need for exclusions.
Anyway, it's all up to you. Every software package will have its own upsides and downsides. On the firewall side, I use the Windows firewall to pre-emptively block software from accessing the internet. Others use the firewall of their choice. The SecureAnywhere firewall is specifically intended to be an anti-threat firewall, not a firewall made for user control decisions. That's why it can run along with any other firewall.
I answered this because even if you went back to Norton, you probably wouldn't have responded if you weren't looking for an answer. Oh, and if you truly decide that ditching the software is the way to go, we give a 70-day Money Back guarantee if you got it through an authorized source.
That being said, if you have low-level questions, please do feel free to continue to ask. I do have answers.
Edit: Spell-Checking again (The original was posted from home with no time to finish completely. *Oops*). Anyway, one of the things I would ask you to keep in mind is that while you can see your desires and actions, we have to take into account the needs and actions of millions of users. I think that when you said "semi-intelligent adult", you grossly underestimated your skill level. We used to see all the people who were infected because they followed instructions on web pages that explained precisely how to exclude a directory from scanning, followed by the saving "this program you want" to that directory and running it. If ever "This is why we can't have nice things" applies, this is an example. And that's just one of the ways exclusions caused problems. So we really are working hard to make all of the classic and other possible reasons for wanting an exclusion function obsolete so that a blanket exclusion is not necessary.
For one, I have huge archives, ebook collections and other stuff that doesn't need to be scanned over and over again.
Not a concern. We don't operate that way anyway, unless you're doing something silly like Full Scans regularly as opposed to the default deep scans. Remember, we're not the Other Security Software. We already know the eBooks can't contain threats, and we don't care about the archives. There's a reason we've been consistently the lightest and fastest since we came out. Simply put, the agent knows what can run, what is likely to run, and what will run. It doesn't worry about data files that cannot contain machine code, and in the event of things such as buffer overflow remote code execution, it uses a realtime system at that time rather than trying to determine which files could possibly cause an issue.
Trust me, my wife used to have to set to exclude her art directories (yay for monolithic high-resolution PSDs), and she doesn't anymore because even she recognizes that the agent doesn't even bother to glance at them.
I also have some password recovery programs that are always mistaken for a virus and then sometimes simply deleted (especially by Bitdefender).
This is a trickier one. No matter what else you use, you're stuck in a situation where "Ignore this file proactively" is a need in those cases. Norton requires you to ignore the file too. That being said, we -never- "simply delete". Will we detect things as "Hacking Tools" if they can be used for nefarious purposes? Yes. However unless you're uninstalling and reinstalling the agent frequently, this is a non-issue. A one-time "Put that back and ignore it" solves that issue without leaving the figurative key beneath your doormat.
Unfortunately, despite my own opinions and everybody else's, we really do have to do what's best for "The majority", so your much-derided "Because it's what's good for you" actions are necessary. While you may be able to recover from a severe infection in minutes, the majority of people can't and it's a catastrophic event.
I know how it works and I like to be in charge and take decisions. I don't like software telling me what I can and what I can't do.
Been there. Still there. Honestly, I get much greater granularity of control from WSA. Even Norton has limitations. Try telling it to use under 6MB of RAM while idle. Try telling it to "ignore the low level utilities in this directory, but please do catch any actual threat that goes in there"... The former is done by an exclude, but the second half of the latter is not-done due to the exclude.
It kind of sounds like you've been doing full scans. Don't. That's not an order, mind you. That's a recommendation. Don't waste your time making the WSA agent pretend to be a slow, old, bloated security client. It's just not necessary, nor does it really help anything. Plus it'll cause you to have more desire for exclusions. Under normal operation with deep scans, it works faster, more efficiently, and there is no need for exclusions.
Anyway, it's all up to you. Every software package will have its own upsides and downsides. On the firewall side, I use the Windows firewall to pre-emptively block software from accessing the internet. Others use the firewall of their choice. The SecureAnywhere firewall is specifically intended to be an anti-threat firewall, not a firewall made for user control decisions. That's why it can run along with any other firewall.
I answered this because even if you went back to Norton, you probably wouldn't have responded if you weren't looking for an answer. Oh, and if you truly decide that ditching the software is the way to go, we give a 70-day Money Back guarantee if you got it through an authorized source.
That being said, if you have low-level questions, please do feel free to continue to ask. I do have answers.
Edit: Spell-Checking again (The original was posted from home with no time to finish completely. *Oops*). Anyway, one of the things I would ask you to keep in mind is that while you can see your desires and actions, we have to take into account the needs and actions of millions of users. I think that when you said "semi-intelligent adult", you grossly underestimated your skill level. We used to see all the people who were infected because they followed instructions on web pages that explained precisely how to exclude a directory from scanning, followed by the saving "this program you want" to that directory and running it. If ever "This is why we can't have nice things" applies, this is an example. And that's just one of the ways exclusions caused problems. So we really are working hard to make all of the classic and other possible reasons for wanting an exclusion function obsolete so that a blanket exclusion is not necessary.
Thank you for your elaborate and thorough reply. All your points are valid. Still, having the option to simply exlude folders of my choice from scanning (and the option to pre-emptively block software from accessing the internet) seems so obvious, that I didn't bother to check before buying.
I will keep an eye on future versions of Webroot, because the light footprint and the high test scores are very appealing. Maybe you'll come to your senses and add these basic features ;)
I will keep an eye on future versions of Webroot, because the light footprint and the high test scores are very appealing. Maybe you'll come to your senses and add these basic features ;)
True, "basic features", but one could, by the same token, say "Why don't you download a huge definition file like everybody else does? That's a basic feature of antivirus."
Location exclusions are unlikely to make it into the product. The cost is far too high. You see your view of things, but we see the whole set of millions of customers and the security industry as a whole. We deal with tens of thousands of threats per day. The security hole opened by exclusion options really is pretty serious. The large archives and photos and data files issue is solved by the simple fact that we don't scan them to begin with. Detections of potentially-hazardous utilities is easily remedied by removing things from quarantine, at which point you have the option to always allow them. That also has the benefit that it recognizes the utility even if you move it, and recognizes it as itself, rather than disregarding a whole definition. If your normal, Deep Scans are taking a long time because of archives or such, then that is actually a bug, not something to be addressed by a feature that causes catastrophic side effects.
The firewall request is a slightly tricky one. The firewall we run is meant to be a network monitor and firewall extender. We found that a lot of people want to run the third party firewall of their choice (there are even a lot of very good free ones out there), and the way we operates allows the firewalls to co-exist without blowing up the network connection. Obviously when running another firewall that has granular control over process connections, there is no good reason for us to duplicate functionality. Considering that even the Windows 7 firewall has very granular control over process and port access, I can see why dev/design made the decision to focus on "actual threats" rather than making "Yet another copy of what something else on the system can do".
At the same time, with the firewall in consideration, the XP firewall doesn't have that granularity or control. Thus, there may be a cause to consider adding preemptive blocking capability. Right now the list is populated with everything that touches the network stack, whether it actually sends communications or not, and regardless of whether it is currently running. Dev/Design wanted to focus on the precept that we take care of threats, as opposed to being a generic network utility. Thus, if it is a threat, we will block it. By that logic, there would never need to be a reason for the user to preemptively block a process from accessing the network. After all, "If you know it's malicious, why are you running it to be blocked to begin with?" and if you aren't sure, you can run it in the sandbox first.
Interestingly enough, if you run something in the sandbox without allowing it to access the network, the firewall is fully aware of it thereafter, so it can be blocked base on that information. That's a moderate workaround. Of course, if you're running an up-to-date OS, you can always add the information to the Windows firewall and not need WSA to duplicate the work.
In the meantime, if you have not yet done so, I recommend you put the firewall request into the Ideas Exchange. You are the first person I know of who has requested such a thing, but who knows, there might be others. For right now, everybody else is quite pleased enough with the operation of the product as a threat handler that they're not generally worried about preemptively blocking processes. (Honestly, the vast majority of customers wouldn't even know to do that, nor have any desire to.)
Location exclusions are unlikely to make it into the product. The cost is far too high. You see your view of things, but we see the whole set of millions of customers and the security industry as a whole. We deal with tens of thousands of threats per day. The security hole opened by exclusion options really is pretty serious. The large archives and photos and data files issue is solved by the simple fact that we don't scan them to begin with. Detections of potentially-hazardous utilities is easily remedied by removing things from quarantine, at which point you have the option to always allow them. That also has the benefit that it recognizes the utility even if you move it, and recognizes it as itself, rather than disregarding a whole definition. If your normal, Deep Scans are taking a long time because of archives or such, then that is actually a bug, not something to be addressed by a feature that causes catastrophic side effects.
The firewall request is a slightly tricky one. The firewall we run is meant to be a network monitor and firewall extender. We found that a lot of people want to run the third party firewall of their choice (there are even a lot of very good free ones out there), and the way we operates allows the firewalls to co-exist without blowing up the network connection. Obviously when running another firewall that has granular control over process connections, there is no good reason for us to duplicate functionality. Considering that even the Windows 7 firewall has very granular control over process and port access, I can see why dev/design made the decision to focus on "actual threats" rather than making "Yet another copy of what something else on the system can do".
At the same time, with the firewall in consideration, the XP firewall doesn't have that granularity or control. Thus, there may be a cause to consider adding preemptive blocking capability. Right now the list is populated with everything that touches the network stack, whether it actually sends communications or not, and regardless of whether it is currently running. Dev/Design wanted to focus on the precept that we take care of threats, as opposed to being a generic network utility. Thus, if it is a threat, we will block it. By that logic, there would never need to be a reason for the user to preemptively block a process from accessing the network. After all, "If you know it's malicious, why are you running it to be blocked to begin with?" and if you aren't sure, you can run it in the sandbox first.
Interestingly enough, if you run something in the sandbox without allowing it to access the network, the firewall is fully aware of it thereafter, so it can be blocked base on that information. That's a moderate workaround. Of course, if you're running an up-to-date OS, you can always add the information to the Windows firewall and not need WSA to duplicate the work.
In the meantime, if you have not yet done so, I recommend you put the firewall request into the Ideas Exchange. You are the first person I know of who has requested such a thing, but who knows, there might be others. For right now, everybody else is quite pleased enough with the operation of the product as a threat handler that they're not generally worried about preemptively blocking processes. (Honestly, the vast majority of customers wouldn't even know to do that, nor have any desire to.)
Just to add on to what Kit said, there is an idea for folder exclusions posted here. Please add your kudos to that idea. While Kit is absolutely correct in terms of the rationale for not having this feature in the product, we still log the number of requests in case we ever revisit this decision.
I do not see one in there yet for "preemptive blocking." I would suggest making an idea topic for that feature. The more kudos it gets, the more likely it is to be implemented.
I do not see one in there yet for "preemptive blocking." I would suggest making an idea topic for that feature. The more kudos it gets, the more likely it is to be implemented.
Again, thanks for explaining. I respect the the philosophy behind your product, but I must conclude that Webroot is not for me.
For all who read this: I was refunded without further ado within 15 minutes of requesting it, wich is quite exceptional.
For all who read this: I was refunded without further ado within 15 minutes of requesting it, wich is quite exceptional.
ljs199 wrote: For all who read this: I was refunded without further ado within 15 minutes of requesting it, wich is quite exceptional.Wow! That's fast. Excellent Customer Service! Thanks for posting ljs199. :D
Sorry to hear that you concluded that Webroot was not for you. 😞
Hi Kit
I purchased WebRoot earlier this year and really like it but I need to clarify something in relation to the exclude "drive" option (or lack of).
I currently have 3 drives mapped (under Windows 😎 to FTP remote locations to access servers I constantly work on.
These servers have local virus protection and I am wondering how WebRoot will deal with this during its realtime and scheduled scans as obviously I dont want to be virus scanning 3 massive servers with lots of files across an ADSL link.
This may be a good reason to provide a very well hidden (maybe only accessible from the registry) option to exclude drives from being scanned by WebRoot or maybe you could recommend a better way to this issue.
I do like you product and it appears to run ok on Windows 8.
Thanks.
Nathan
I purchased WebRoot earlier this year and really like it but I need to clarify something in relation to the exclude "drive" option (or lack of).
I currently have 3 drives mapped (under Windows 😎 to FTP remote locations to access servers I constantly work on.
These servers have local virus protection and I am wondering how WebRoot will deal with this during its realtime and scheduled scans as obviously I dont want to be virus scanning 3 massive servers with lots of files across an ADSL link.
This may be a good reason to provide a very well hidden (maybe only accessible from the registry) option to exclude drives from being scanned by WebRoot or maybe you could recommend a better way to this issue.
I do like you product and it appears to run ok on Windows 8.
Thanks.
Nathan
Hi Nathan, and welcome to the community!
Your question actually delves into some more technical stuff, so you might end up learning more than you ever thought you never wanted to know about file systems. ;) However I will give the short part of the answer first.
Short answer:
SecureAnywhere will not scan the FTP mounted drives unless you explicitly start a full scan or a custom scan to do so, which does warn you before allowing you to start it. Normal scans will not look at the mounted FTP drives unless something on the FTP drive is set to auto-run or is about to execute.
SecureAnywhere also will (technically) never scan anything across the FTP system ever. If you run something from the mounted FTP, it will be scanned prior to execution. However it still generally will not be scanned from the server.
The first one likely covers your needs. That second one is what requires more explanation.
A mounted drive is generally treated as a block device. However FTP is not a block-supporting protocol.* When a file is read of the FTP "drive", it's really moved to a staging area on the local system drive before it can really be read. Generally the mount handler will do this transparently to the view of the program requesting it, so if F:some.txt is on the FTP, the program will see that it is working with F:some.txt. In reality, when the program requests some.txt, the mount handler will download some.txt to a temporary location then read it from the local disk during block handling and upload it back to the FTP server when it is closed if the contents have been changed.
So the good news is that FTP-mounted drives and indeed, any network drives at all are still not good reasons for us to make it possible to exclude anything.
After all, it doesn't matter how "hidden" the exclusion is. A threat doesn't need to see or know the exclusion or how to add one in order to take advantage of exclusions. Make a custom, inert downloader (eg, something that is NOT actually a threat and won't be caught as one. I could do it in five minutes and I guarantee that no AV will catch it as a threat.) Then just write something that it knows should be caught by the AV to every folder out there (or make educated guesses about what may or likely will be excluded, like game folders and such) and see what copies survive because they are in excluded folders. When it sees what survives, snag the real threat and drop it there. Easy as pie and already done by numerous droppers, which is especially fun since no AV detects the droppers**, just the stuff they grab and drop.
(* FTP does have resume capability, which allows it to start a transfer from a specific byte offset, but that's about the closest to block stuff it has.)
(** Some AVs recognize the droppers heuristically based on what they drop being detected, not the dropper code itself.)
Your question actually delves into some more technical stuff, so you might end up learning more than you ever thought you never wanted to know about file systems. ;) However I will give the short part of the answer first.
Short answer:
SecureAnywhere will not scan the FTP mounted drives unless you explicitly start a full scan or a custom scan to do so, which does warn you before allowing you to start it. Normal scans will not look at the mounted FTP drives unless something on the FTP drive is set to auto-run or is about to execute.
SecureAnywhere also will (technically) never scan anything across the FTP system ever. If you run something from the mounted FTP, it will be scanned prior to execution. However it still generally will not be scanned from the server.
The first one likely covers your needs. That second one is what requires more explanation.
A mounted drive is generally treated as a block device. However FTP is not a block-supporting protocol.* When a file is read of the FTP "drive", it's really moved to a staging area on the local system drive before it can really be read. Generally the mount handler will do this transparently to the view of the program requesting it, so if F:some.txt is on the FTP, the program will see that it is working with F:some.txt. In reality, when the program requests some.txt, the mount handler will download some.txt to a temporary location then read it from the local disk during block handling and upload it back to the FTP server when it is closed if the contents have been changed.
So the good news is that FTP-mounted drives and indeed, any network drives at all are still not good reasons for us to make it possible to exclude anything.
After all, it doesn't matter how "hidden" the exclusion is. A threat doesn't need to see or know the exclusion or how to add one in order to take advantage of exclusions. Make a custom, inert downloader (eg, something that is NOT actually a threat and won't be caught as one. I could do it in five minutes and I guarantee that no AV will catch it as a threat.) Then just write something that it knows should be caught by the AV to every folder out there (or make educated guesses about what may or likely will be excluded, like game folders and such) and see what copies survive because they are in excluded folders. When it sees what survives, snag the real threat and drop it there. Easy as pie and already done by numerous droppers, which is especially fun since no AV detects the droppers**, just the stuff they grab and drop.
(* FTP does have resume capability, which allows it to start a transfer from a specific byte offset, but that's about the closest to block stuff it has.)
(** Some AVs recognize the droppers heuristically based on what they drop being detected, not the dropper code itself.)
If you want to run software like iMonitor, you need to exclude a folder from scan on server and on client.
I have been using Webroot 200% satisfied for past few years - but the lack of this fester will force me to change.
I have been using Webroot 200% satisfied for past few years - but the lack of this fester will force me to change.
Or is there a way to "teach" Webroot to let certain applications / files (I.e. iMonitor) be in peace?
You can add the files you want to be allowed in to Detection Configuration under section Quarantine and set the Allow. Also it would be worth to check Control Active Processes under section System Tool and System Control whether your files are not blocked.
Why would you want to exclude folders? Its cloud based and only scans new or changed folders anyway
iMonitor (and others) specifically want to be excluded from scans because theey expect that AV scans will detect things they do as bad and/or impact their necessary performance.
With any other AV, this is a completely valid assumption. Other AVs intercept disk I/O and lock it down until they are finished scanning. This causes the program that needs to have unfettered I/O to be blocked for that time, so it has issues.
Webroot does -NOT- block I/O while scanning and does not redirect disk activity to slow it down. Thus, the need for exlusions that exist for all other AV software does not exist for Webroot.
There is one basic rule:
If something says "You -must- do XYZ with your AV to use us" (Exclude us, turn it off to install us, etc), chances are nearly perfect that it is not the case with Webroot SecureAnywhere.Just try it while ignoring that bad advice from the other program and chances are pretty strongg it will work just fine anyway. If it doesn't, Webroot is absolutely thrilled to look at both programs, figure out where the other one failed, and make workarounds for it explicitly that do not reduce your protection.
After all, that is a HUGE security hole, and I would strongly expect there are threats that explicitly look for iMonitor to be installed because they know they can hang out in its folder and never be caught.
So best to just use it and see if it actually causes a problem. Chances are that it won't, and on the slim possibility that it does, Webroot will just fix it anyway.
With any other AV, this is a completely valid assumption. Other AVs intercept disk I/O and lock it down until they are finished scanning. This causes the program that needs to have unfettered I/O to be blocked for that time, so it has issues.
Webroot does -NOT- block I/O while scanning and does not redirect disk activity to slow it down. Thus, the need for exlusions that exist for all other AV software does not exist for Webroot.
There is one basic rule:
If something says "You -must- do XYZ with your AV to use us" (Exclude us, turn it off to install us, etc), chances are nearly perfect that it is not the case with Webroot SecureAnywhere.Just try it while ignoring that bad advice from the other program and chances are pretty strongg it will work just fine anyway. If it doesn't, Webroot is absolutely thrilled to look at both programs, figure out where the other one failed, and make workarounds for it explicitly that do not reduce your protection.
After all, that is a HUGE security hole, and I would strongly expect there are threats that explicitly look for iMonitor to be installed because they know they can hang out in its folder and never be caught.
So best to just use it and see if it actually causes a problem. Chances are that it won't, and on the slim possibility that it does, Webroot will just fix it anyway.
What you wrote makes fully sense to me. Thank you!
THe only problem was that I had tried to install iMonitor 5 times with WebRoot turned off. Then after turning WebRoot on, it just erased all the components of iMonitor. I seem to have missed the "allow iMontor to run" part of it. How can I access or find that?
Thanx.
THe only problem was that I had tried to install iMonitor 5 times with WebRoot turned off. Then after turning WebRoot on, it just erased all the components of iMonitor. I seem to have missed the "allow iMontor to run" part of it. How can I access or find that?
Thanx.
sndbbbl, if Webroot is quarantining the file, it's a matter of creating an exception. Please check the quarantine in Webroot and restore the iMonitor files. If that doesn't help, we might need to take a look at that for you. In which case, could you please open a support case?
I didn't eeven see this come in.
Now I wonder... Webroot doesn't just randomly delete things. It will...
- Quarantine files that register as threats.
- Delete files that are created by files that register as threats if it sees the "threat" create the file.
- Delete files that are in standard System Cleaner locations or in locations it is told to clean.
The second possibility can't occur if the files that are deleted are created when Webroot is turned off, since it isn't monitoring.
For the first possibility to occur, -every- single file that gets deleted would have to be considered a threat.
The third possibility is definitely there if iMonitor is installed "stealth" or if Webroot is misconfigured, but only applies with Complete.
Notably, iMonitor is a business employee monitoring program, so normally would be paired with Webroot SecureAnywhere Business Endpoint. Silent Audit is the default install, then the WSABE controls would find iMonitor and be told to ignore them via the console. Also should be noted that iMonitor will not be ignored by the program normally because it -can- be used for Nefarious Purposes. And lastly, though it's not likely tto apply in this case, every "free" (cracked) version of iMonitor I found anywhere actually was infected. I only say that to cover more of the possibilities. It could also be a completely different program called iMonitor.
Best bet honestly would be to open a ticket using the link above from Jim and let the folks at support see what happened. Any other action just has us guessing about what happened and not able to direct you precisely.
Now I wonder... Webroot doesn't just randomly delete things. It will...
- Quarantine files that register as threats.
- Delete files that are created by files that register as threats if it sees the "threat" create the file.
- Delete files that are in standard System Cleaner locations or in locations it is told to clean.
The second possibility can't occur if the files that are deleted are created when Webroot is turned off, since it isn't monitoring.
For the first possibility to occur, -every- single file that gets deleted would have to be considered a threat.
The third possibility is definitely there if iMonitor is installed "stealth" or if Webroot is misconfigured, but only applies with Complete.
Notably, iMonitor is a business employee monitoring program, so normally would be paired with Webroot SecureAnywhere Business Endpoint. Silent Audit is the default install, then the WSABE controls would find iMonitor and be told to ignore them via the console. Also should be noted that iMonitor will not be ignored by the program normally because it -can- be used for Nefarious Purposes. And lastly, though it's not likely tto apply in this case, every "free" (cracked) version of iMonitor I found anywhere actually was infected. I only say that to cover more of the possibilities. It could also be a completely different program called iMonitor.
Best bet honestly would be to open a ticket using the link above from Jim and let the folks at support see what happened. Any other action just has us guessing about what happened and not able to direct you precisely.
Thank you for your detailed feedback. I have used the official trial version from the developpers WEB SITE. You are right, it does not delete them but put them in quarrantaine. BUt after moving it back, I cannot run it any more. I will open a case and give feedback here - as suggested by you and the WebRoot service message.
Thank you.
Thank you.
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.