I just realized that Webroot no longer analyzes my Internet searches no matter the search engine. Previously, a checkmark used to appear next to the results e.g. Green, Red, etc. but now I don't see anything. Has this feature been removed from the program?
--
Robert
Solved
Webroot Internet Safe Search
Best answer by Kit
When SecureAnywhere determines that any factors would prevent the safe modification of the search results, it will automatically turn off attempting to do so in order to avoid causing conflicts. Factors include Proxies (Local or In-Line), Addons that modify or examine search results, SSL searching (the default for Google now), and other software or remnants thereof that examines or modifies the search results. So, there are a lot of things that can turn off that feature automatically as a failsafe.
The important thing to be aware of though is that even when search result annotation is not displayed, as long as the appropriate shields are on, any attempt by the browser to visit a known-malicious search result will be blocked.
View originalThe important thing to be aware of though is that even when search result annotation is not displayed, as long as the appropriate shields are on, any attempt by the browser to visit a known-malicious search result will be blocked.
Hi SkepticRob,
Welcome to the Webroot Community !
In terms of the search annotations, which browser and version are you currently using? This are currently no annotations for Chrome or Safari, but you should see the annotations when searching using IE or Firefox.
Thanks,
Howard
Welcome to the Webroot Community !
In terms of the search annotations, which browser and version are you currently using? This are currently no annotations for Chrome or Safari, but you should see the annotations when searching using IE or Firefox.
Thanks,
Howard
Hi Howard, I use both IE and Firefox. Neither displays the results. Thanks!! Rob
+56Can we have version numbers please and also the version number of WSA that you are using? Also they don't show in IE8 & 9 64bit browsers but they should be fine in IE8 & 9 32bit and FF 10.0.2 here! Check your Web Threat Shield and Identity Shield settings as for myself I have check marks in all boxes under both Shields!@ wrote:
Hi Howard, I use both IE and Firefox. Neither displays the results. Thanks!! Rob
TIA,
TH
Hello!
I am definitely using 32 bit browsers, and I have ensured that all the sheilds are turned on including subsettings. I checked the rest of the computers in the household and they too have lost the feature.
As for the version number of WSA it is currently v8.0.1.146.
Rob
I am definitely using 32 bit browsers, and I have ensured that all the sheilds are turned on including subsettings. I checked the rest of the computers in the household and they too have lost the feature.
As for the version number of WSA it is currently v8.0.1.146.
Rob
- OpenText Employee
- 29 replies
Hi SkepticRob,
What web search service are you using? I would like you to try multiple search engines such as Yahoo, Google, and Bing.
Also, do you have any other security software installed on this computer? Sometimes other software comes with link scanning capabilities and occasionaly they dont like us sharing the same space.
Please reply with your findings.
Thanks
Josh C
What web search service are you using? I would like you to try multiple search engines such as Yahoo, Google, and Bing.
Also, do you have any other security software installed on this computer? Sometimes other software comes with link scanning capabilities and occasionaly they dont like us sharing the same space.
Please reply with your findings.
Thanks
Josh C
I use Yahoo! and Google search.
Regarding other security software, I do not have any other security software installed on my computer—only Webroot.
:D
Robert
Regarding other security software, I do not have any other security software installed on my computer—only Webroot.
:D
Robert
When SecureAnywhere determines that any factors would prevent the safe modification of the search results, it will automatically turn off attempting to do so in order to avoid causing conflicts. Factors include Proxies (Local or In-Line), Addons that modify or examine search results, SSL searching (the default for Google now), and other software or remnants thereof that examines or modifies the search results. So, there are a lot of things that can turn off that feature automatically as a failsafe.
The important thing to be aware of though is that even when search result annotation is not displayed, as long as the appropriate shields are on, any attempt by the browser to visit a known-malicious search result will be blocked.
The important thing to be aware of though is that even when search result annotation is not displayed, as long as the appropriate shields are on, any attempt by the browser to visit a known-malicious search result will be blocked.
Hello Kit!
While I do thanks for thorough explanation I don't see a reason why WSA should step back in favour of other security applications. I rank among others who are missing WSA search engine annotations. In the light of your post I have very little to complain about as I am using NIS2012 with its Norton SafeWeb enabled. Even if I think that WSA's and NIS's annotations could work along well because WSA's check marks are placed in front of search results and NIS's check marks are placed behind search results. Though WSA annotations are missing, in my case only NIS labels search results. What do you think?
Nevertheless I would prefer to choose security application (addon) which should have a prevealance. So how about incorporating into WSA a prompt telling something like that another security addon has been spotted and asking if I want to disable it and let allow WSA to take control over search results instead.
Thanks & regards,
pegas
While I do thanks for thorough explanation I don't see a reason why WSA should step back in favour of other security applications. I rank among others who are missing WSA search engine annotations. In the light of your post I have very little to complain about as I am using NIS2012 with its Norton SafeWeb enabled. Even if I think that WSA's and NIS's annotations could work along well because WSA's check marks are placed in front of search results and NIS's check marks are placed behind search results. Though WSA annotations are missing, in my case only NIS labels search results. What do you think?
Nevertheless I would prefer to choose security application (addon) which should have a prevealance. So how about incorporating into WSA a prompt telling something like that another security addon has been spotted and asking if I want to disable it and let allow WSA to take control over search results instead.
Thanks & regards,
pegas
Pegas,
That's something to consider, but difficult at the same time. While we will definitely look into it, we need to take a few things into consideration...
The first is the methodology by which our search annotation operates. WSA is not working as a browser plug in. It's working as a combination of a DLL injection and kernel-level inspection. The first part of that means that some other security software panics quite thoroughly. The second part means that there are inherent advantages and limitations.
SSL is one of those limitations. Secure from Server to Browser, which means that kernel-level inspection can't view it.
The fact that an Add-On can be disabled, tampered with, and provides a very large attack surface is one of the advantages to not using that method.
The next thing to take into consideration is "The Average Customer" and the premise behind WSA, a main part of which is "Don't get in the way". Even when two annotators are loaded as add-ons, they can conflict with each other quite nicely. With our method of operation, the standard tamper protection that is built into numerous security products will go off in a heartbeat, because in all technicality, we are tampering with the search results. The effect in these cases is a blank white page because the connection is killed after the HTTP headers. We have no control over the other security software's operation, and asking the average customer to properly configure the other security software to not interfere at all was found to be undoable. Heck, asking the average highly-skilled technical user to selectively get the other to not interfere turned out to be undoable, because the other security software frequently doesn't listen.
So due to the very nature of the operation of the software, and the propensity for problems that would drive support calls to us, yet we could do nothing whatsoever about, the decision was made to be submissive in these cases. The full protection is still there. If a detrimental site is visited, it will be blocked. There is just no annotation before the blocking.
We are currently looking into a secure method to annotate SSL connections (Thank you, Google), so if that pans out well, we may be able to stop stepping back from potential conflict categories, since the conflict would potentially be non-existent at that point.
That's something to consider, but difficult at the same time. While we will definitely look into it, we need to take a few things into consideration...
The first is the methodology by which our search annotation operates. WSA is not working as a browser plug in. It's working as a combination of a DLL injection and kernel-level inspection. The first part of that means that some other security software panics quite thoroughly. The second part means that there are inherent advantages and limitations.
SSL is one of those limitations. Secure from Server to Browser, which means that kernel-level inspection can't view it.
The fact that an Add-On can be disabled, tampered with, and provides a very large attack surface is one of the advantages to not using that method.
The next thing to take into consideration is "The Average Customer" and the premise behind WSA, a main part of which is "Don't get in the way". Even when two annotators are loaded as add-ons, they can conflict with each other quite nicely. With our method of operation, the standard tamper protection that is built into numerous security products will go off in a heartbeat, because in all technicality, we are tampering with the search results. The effect in these cases is a blank white page because the connection is killed after the HTTP headers. We have no control over the other security software's operation, and asking the average customer to properly configure the other security software to not interfere at all was found to be undoable. Heck, asking the average highly-skilled technical user to selectively get the other to not interfere turned out to be undoable, because the other security software frequently doesn't listen.
So due to the very nature of the operation of the software, and the propensity for problems that would drive support calls to us, yet we could do nothing whatsoever about, the decision was made to be submissive in these cases. The full protection is still there. If a detrimental site is visited, it will be blocked. There is just no annotation before the blocking.
We are currently looking into a secure method to annotate SSL connections (Thank you, Google), so if that pans out well, we may be able to stop stepping back from potential conflict categories, since the conflict would potentially be non-existent at that point.
Kit - Prior Webroot Quality Assurance / Prior Webroot Escalation Engineer
1 person likes this
Hi Kit,
Many thanks for your in-depth clarification. Perfectly understood. Hope though that it is a sole submission approach from Webroot :D
All is fine as long as protection works. I would rather say it is much better than to have visible smart annotations but failing with protection in the background
Thanks & regards,
pegas
Many thanks for your in-depth clarification. Perfectly understood. Hope though that it is a sole submission approach from Webroot :D
All is fine as long as protection works. I would rather say it is much better than to have visible smart annotations but failing with protection in the background
Thanks & regards,
pegas
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.