It is not a secret that I have the long lasting problems with:
1) the missing padlock
2) the firewall strangely dealing with some applications on my PC
3) the malfunctions of WebShield in Opera and IE9.
It's a quarter of a year when I started to communicate with Webroot staff via the support inbox. I have sent detailed informations and have exchanged a lot of things with the support, I have collected and have sent a few logs and so on. In the beginning and middle of November I have been informed that the issues I have reported are in queue to be addressed but they can't give me a timeline for any fixes right now.
OK, I can understand that if I am experiencing any problems alone and are not hundreds of other users reporting them, I have to give way to more important issues and I don't have a problem with this. It's worth noting, though, item 3) is reproducible and confirmed by other users and by the support as well!
Therefore I am asking how long I have to wait yet? Don't be fooled, I don't think it ironically, indeed. I just want to know when all my issues will be resolved.
Thanks & regards,
Best answer by KitView original
Wishing you quiet X-mas holidays.
I agree, I do wish a lot of things were more possible. AV is one of the most frustrarting industries to work in and has been for over a decade. We've got the bad guys fighting against us but we've also got customer demands and frequent misunderstandings - think about hwo many customers get utterly mad when their AV lets one thing through at all because they don't understand that it can't be perfect.
A good example of "Hiding things" comes historically from another AV back in the 90s. If it couldn't scan something, it would put that information in a log hidden deep in the installation directories without an obvious filename and then give up and claim the scan was successful. If we can't scan something, we take that into account in our operations and use that as part of the determination of what's going on. Then we dig deeper because of it.
Another example is how many things will pass "tests" but be bypassed trivially by real malware. We focus on what the real threats are doing, because no matter how good something looks on a test, protecting a real computer against real threats in real situations is more important.
But yes, in any cases where the keyboard scan codes are not a supported keyboard configuration, or cases where non-"supported" characters are entered, they do not go through the filter and thus are not protected. This is also frustrating because there is no good way to fix this. If we are forced to use the computationally-expensive hook, each extra character we check for makes it take longer and longer per each keystroke. If Windows and all the other programs we want to protect would be coded correctly, it would be simple, but we have to operate with them, and they aren't always going to work properly, so we have to take workarounds (the slow hook) that have costs in other places, such as being slow.
So between technology limitations and odd third party code and legalities in countries and such, it's honestly frustrating. We do as much as we can though, so please do keep up the ideas and let us know if you have any issues. Just sometimes our hands are tied.
Definitely not. You, Joe and all development team have my full belief and admiration for the work you have been doing.
OK I should conclude that I accept your explanations given in your posts in this thread ;)
Thanks & regards,
OK, that's needed to be said and you're right. Accepted.
It's a pity and should this be possible, it would definitely be of users benefit to have the feedback that something is wrong or not fully working.
That's a scandal! And I have a faith in Webroot they keep out of such practices.
Hmmm, interesting. Thx for the explanation. BTW, is this valid also for the Czech OS?
Now, the first thing is the wording:
they should make a general statement or incorporate to WSA a warning which should jump out during installation that the features of WSA might be limited on unsupported systems.
Taken literally, you are requesting that we do something like display a message to all users stating:
"Some features of WSA may be limited or inoperative on unsupported systems."
My observation is that this should not be necessary because that's defining the basic definition. We are disinclined to join the ranks of companies that put things like "The hot coffee in this cup is hot" on a cup of hot coffee or "Warning: Contains Peanuts" on a package of salted peanuts. Amongst other things, it would be duplicating the information given in the EULA and it would not apply to the vast majority of the customers, thus would cause unnecessary concern amongst them.
Alternately, you could be requesting that we display such a message in cases where it's an unsupported system. There is no programmatic manner by which to accurately detect all or even most cases where the software may not fully operate.
Thirdly, I would like to know what other AV company displays such a message. The fact that you are concerned about holds true on every AV and even if not set and forgotten about, most other AVs actively work to hide operational failures. We do specifically make the information about system support for our software available and we are up front about it with customers. We explicitly do not have any authorized resellers in locations that do not support our software, but the nature of the internet means that people can still get ahold of it. Even locations and countries that we cannot legally sell in due to trade restrictions have gotten the software.
In the case of the Polish OS and hardware, it's the keyboard scan codes combined with character input. On US hardware, for example, people will notice that when working properly, the ID shield will still allow non-alphanumeric characters through. Somebody typing the average URL would still see ://../. get captured. In certain cases where the OS to Process link does not provide certain hooks, we hook a different location that's relatively expensive. In that location, we do a lookup against a-z, A-Z, 0-9 and protect those. Previously we just protected EVERYTHING, but that resulted in human-observable keyboard lag and dropped characters due to how expensive the function is programmatically.
The thing that always stands: We, like every company, will work towards what is best for the majority of customers. We are always happy to consider ideas that will benefit our customers and their security, however we need to take feasibility and possibility into account. Nothing comes without side effects of some kind.
Like I frequently have to consider, I often have what I think are good ideas for the company, but I can't see what's going on across the full system. When taken into the larger context, that idea isn't necessarily as good. I can't always find out why, or be privy to the reason. But really, consider this: Given how powerfully we and Joe (You know him as PrevxHelp from WIlders) work to have everything working perfectly and given that security is our number one focus, do you really believe that this is not being changed because we just don't care or are not being honest?
So once again, I don't have a problem that WSA might or might not work fully or partially on unsupported systems (as regards languages). That's fine and you can't be held responsible for this.
Nevertheless the point is that users on unsupported systems are paying for your product and believing WSA fully works. Average users have an approach "install & forget" and WSA will do its work. They are not testing WSA against test files, against test threats etc. If they don't do this how they can know that for instance Identity Shield doesn't work on their systems. WSA looks like that everything is fine but in fact it is a fake assumption and in this respect similes you wrote in your post sounds like mockery and the last article about the trials and refunds is not applicable.
Therefore if Webroot wants to keep a honest approach, they should make a general statement or incorporate to WSA a warning which should jump out during installation that the features of WSA might be limited on unsupported systems. It's fair and users deserve to know it.
The very definition of "unsupported" in English terms is that the item might or might not work. Unsupported does not mean "Will definitely not work", but it also explicitly means that it was not designed to work for that situation. Thus getting it to work completely or partially is potentially possible, but not a guarantee, and assumptions should be made in all cases that it will not work. Just saying "unsupported" is effectively defined as: "While you may be able to get it to partially or fully work, we expect that it won't work completely if it works at all and we will not attempt to assist (support) you in getting it to work partially or fully in those cases."
We can make a general statement, but as it gets into more and more precise supported vs unsupported cases, there comes a limit as to what is reasonable to expect from statements. There is a potential benefit to more clearly stating what languages we support. Beyond that, it's up to individuals to make educated and reasonable decisions. On the silly (but sadly true) extremes, for example, we've had to point out to more than one customer that Webroot can't scan their computer when it's not plugged in or turned on. At the same time, we don't list "Computers that have no electrical power are not supported at the time they have no electrical power." ;)
Since we can't list every single possible unsupported case, we give 14 or more days of free trial, full support, a community to ask questions and get answers, and a 70-day refund policy on purchases through authorized channels.
So in all honesty and in the interest of objectivity Webroot should make a clear announcement on its Web and here on the Community that WSA functions can be limited on unsupported systems. Users should be aware of this before they spend their resources and before they start to rely on your product.
Don't be fooled, I am not upset, I just want so that Webroot has been giving important information about WSA to all current and potentional users (of unsupported systems). They are your customers and they have the right to have the correct information about limitation of WSA on their systems.
Yes, you are right WSA fails on Zemana keylogger test app!!!
However it need not necessarily mean that Identity Shiled is not working because the test file could be whitelisted in the Webroot cloud as they are known test files and don't pose real threats.
I hope JimM or somebody else of Webroot will shed more light and confirm, otherwise a one can think that Identity Shiled is indeed going wrong and the missing padlock isn't just a cosmetic thing!
Anyhow, I have to admit my disappointment that WSA doesn't work fully properly unless localised. I have tested many AV solutions during past decade and have never had any issues stemming from different language versions. I also have not had any issues with the padlock with Prevx3 and Prevx4 (the later have transformed in to WSA).
Anyway, thanks for your feedback. As for the Identity Shield can you confirm that the shield on Czech localised OS itself works correctly and the missing padlock is rather an aesthetic issue? It is very important to know.
Thanks in advance.
Item 2 does not reproduce even with the suggested restart on any of my test systems, and this is most likely another localization issue in light of the facts that we are now certain that at least some localization issues exist on Czech systems and that you are the only person reporting the problem.
EDIT: Just updated Opera to 12.12 and the Web Threat Shield issue still remaims.
A clean install of the latest .92 build gives the following replies to my issues:
ad 1) the padlock is still missing
ad 2) the firewall gave me correct prompts for VLC and Ashampoo Burning Studio Free when checking updates UNTIL reboot. Upon reboot the both applications check for updates without the firewall prompt to choose to Block, Allow or Allow Once. It's obvious that a reboot makes difference.
ad 3) no improvement, WebShield is still failing
I take into account your replies in this thread that item 1) and 3) are scheduled to be dealt with. I only hope it won't last long. As for the item 2) as I said until reboot all was fine. However because only the two said applications are affected and I don't use them to connect to the internet often, we can leave this issue. Please just report to Joe that a reboot is the culprit. It could give him a direction.
My priorities are item 1), then 3) and lastly item 2). I understand that you don't need anything to resolve item 3), you know what to do to solve this problem. Anyhow, for item 1) I am ready to assist you as much as possible in order to resolve this long lasting problem which I really hate.