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
Issues 1 and 3 are both assigned to development.
Our lead developer has been working on Item 1, but it appears there is more work to be done.
Item 3 is scheduled to be dealt with, and we haven't forgotten about it. There are changes coming in the future that will ultimately resolve this problem. Rather than expending resources on patching the bug in the short term, resources are being focused on a more robust, permanent solution that, while it takes a little longer to develop, will be worth it.
Issue 2, I believe (correct me please if I'm referencing the wrong issue), is one in which it was explained that, although the way in which WSA logs "Allowed Once" can be somewhat confusing by virtue of it dropping Allowed Once entries into the Allowed column, it's currently working as designed. You had created an idea that suggests creating an "Allowed Once" column to mitigate this confusion. That's a good idea as I see it, but it's unfortunately received very few kudos so far. Part of this, I believe, is that the number of users that make use of "Allowed Once" is small proportionate to the user-base. Of those users, the number that need to go looking for an "Allowed Once" entry to check up on it is also probably small proportionately. And of those users that both make use of the "Allowed Once" feature and who need to go looking for the reference entry, those who believe a separate column is necessitated for proper control are also probably low, since once you get to the point of needing to look for an entry to perform a manual change, you are most likely already committed to either Allow or Block. That's not to say the feature wouldn't be useful or that it's not a good idea (I actually voted for this one myself) - just that the prioritization is in line with the demand at the moment.
Thanks for your comments. I am glad that item 1 and 3 are under progress because I eagerly am awaiting them to be resolved.
As for the missing padlock, it's a century I have seen it on my PC lastly, in fact I saw it in the early versions of WSA (when it transformed from Prevx 4) and since than if I want to see the padlock I have to open the user guide and check how it looks :D
As regards the WebShield, it is annoying and the WebShield clearly fails and thus the shield is definitelly not fulfilling its purposes.
Regarding item 2), you are referring to the wrong issue, however many thanks for your point of view related to my Allow Once idea.
Please see below an extract from my correspondence with Angela via the support system:
"The file named "wsalogs_my email address_2012-10-24-9.09.24.7z" belongs to report where a FW prompt should be shown when checking updates in VLC and Ashampoo."
For more references please track this issue in your support system.
Anyway, should you need something more to resolve my issues like a remote session etc. just drop me a message.
Once you have some further information available please let me know.
Thanks & regards,
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.
EDIT: Just updated Opera to 12.12 and the Web Threat Shield issue still remaims.
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.
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.
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).
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.
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 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.
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?