Hi there. Our guys frequently need to turn off WebRoot when patching Exchange Servers and the like.
We dont have that feature enabled on our Servers Policy.
We would like to ]make the following susggestion.
That to turn off WebRoot using the right click on the icon will require entering your or the Site WebRoot GSM credentials and not just a captcha.
Thanks, regards Peter.
There should be a setting so that if you know that a website isn't reputable but it's marked as reputable, you can change it. Although you can do this on this website, sometimes the reputation change requests aren't accepted, even if they're reasonable. You should be able to change it just for you so that you can remember not to go to a site if it's dangerous.
Also, unrelated, check out the Youtube channel, Ben Hertzman, and subscribe. Thanks!
On the GSM Sites list the filter resets to show everything each time the page loads.
It would be great if we could set a default filter or have it remember the last used filter.
Then we could do things like hide suspended sites by default to reduce clutter.
I am an MSP and wouid like to have Webroot automatically remove endpoints from the console when they havent checked in for a predetermined time eg 30 or 60 days. If I am charging on a monthly basis and a endpoint has been retired or crashed or is no longer in use, it is currently very difficult to check every site to remove these endpoints from being billed.
How about rewarding loyal customers by making auto-renewals cheaper, or at least the same price, as new purchases?
Existing customers are effectively charged a "lazy tax" if they auto-renew, especially SecureAnywhere Plus and Complete customers, who cannot purchase cheaper subscriptions without being forced to jump through hoops to retain their passwords/backups.
I know 3rd party offers can be even cheaper again, but surely auto-renewals could at least match Webroot's own discounted prices?
I have just discovered that the UK is the only country where you are charged to contact Support (0870 141 7070) — and charged quite steeply at that.
This can't be right !!??!!???
It was the following post that drew my attention to this:
.....My issue was dealt with while I waited, it took an hour or two all told, but AFAIK the call was free (it had better be).
Are Webroot actively trying to lose UK customers??? When @squarehead666 sees his phone bill at the end of the month, I imagine he will be an extremely unhappy customer to see that he is being charged (and very steeply at that if I am not mistaken) for the privilege of having Webroot correct problems being caused on his machine by Webroot's software !!! What is more, being in contact through games forums with other Battlefront games customers using Webroot and encountering the same problem, I can well imagine that this will have ripple effects.
C'mon Webroot!! Why should Webroot customers from the UK, the country from whence hails the cybersecurity firm Webroot can thank for the entire architecture of its antimalware products, have to pay to get technical support by phone? Step up your game, and offer UK customers a free phone number like all the other countries you offer a Support phoneline to: https://www.webroot.com/us/en/support/contact !
On github there is an experimental project "Beamgun" which adds a defense layer to the Windows USB driver subsystem to block all new USB device attachments, for devices which haven't already been recognized and approved, even when the new device would not normally require a driver installation or any user interaction, e.g. devices which (claim to be) "Network adapter" or "Keyboard (HID device)", etc.
These "Evil Maid" or "Rubber Ducky" USB attacks have been demonstrated where, if a person has physical access to a computer, and the computer is on, the USB device acts like a keyboard or a network adapter or some other USB device types, which allows it to start locally trying to exploit vulnerabilities. Locked screens don't help because the device is talking directly "on the local network" or as an additional keyboard or mouse, etc. Full Disk Encryption doesn't help because the computer is already running and if the USB attack can gain any kind of access (underneath the lock screen) then the files are already accessible decrypted. (File based encryption would help, unless the attack gives the attacker a foothold which then sits and watchs and waits until the legitimate user unlocks the encrypted files).
I would like to see this "beamgun" defense added to endpoint security solutions, especially non-signature based ones like Webroot SecureAnywhere.
There is no way to remove deactivated sites in GSM. This, despite the warning that deactivation is permanent.
We need a way to do two things:
1) Hide a deactivated site from the GSM site listing (if we still need information about its settings)
2) Remove a deactivated site from the GSM if it is no longer needed.
It is distracting to go through multiple sites when some have been deactivated, and I'd like to clean the clutter.
Respectfully, may I request a Padlock re-think.
Webroot Community & Webroot Support have assured me that I'm protected with Padlock & I'm protected without Padlock.
Respectfully, why Padlock.
Why distract from my Webroot experience with a toggling Padlock.
At this moment Padlock is Off presumably because I made an extraneous mouse click.
For me, toggling Padlock for every extraneous mouse click is a distraction.
Padlock remains Off at this moment. Presumably as before if I make a trigger mouse click, Padlock will resume On.
Yes, I clicked on my active browser taskbar shortcut triggering, Padlock to resume On.
Click on taskbar lose Padlock.
Click on browser shortcut gain Padlock.
Respectfully, why Padlock.
Respectfully, why toggling Padlock.
Support advises that W means I'm protected.
Respectfully, how & why does a Padlock, albeit a Padlock that likes to toggle enhance my Webroot experience.
Please re-think Padlock.
It would be nice if you could include Company and Site names as "Data Inputs" / available fields to insert into alerts.
This is a more natural way to make sure that the systems receiving alerts can parse the alert correctly, rather than relying on the creation / customization of Group name.s
Webroot Filtering Extension button at Firefox address bar similiar to Webroor button at Chrome address bar.
Clearly no product or service can claim they can prevent 100% of ransomware from getting onto a machine.
Adding the ability for WEBROOT to stop a service based upon the detection of specific file types being creating on a machine would be an extremely useful step in the right direction to prevent the spread of ransonware across unmapped or discovered drives. So many of the ransomware tools create a number of specific file name extensions and these could be easily detected. IF detected, do some things like STOP and disable the networking services, create a few unique entries in the registry so that other tools can detected this too...
WEBROOT needs to have easy to use options that effectively do what large and sophisticated IT companies do with group policies and years of experience..