I can confirm Items 1 and 3 on Win 7 x64 #2 I don't know as I use Look'n'Stop Firewall with WSA-C.

 

TH

---

Hi Pegas,

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.

---

Hello Jim!

 

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,

pegas

---

I may have actually been a little behind the times concerning Item 1. Based on the most recent reports, that may have been fixed for most users as of 8.0.2.79 just a few days ago. TripleHelix, are you still missing the padlock? Pegas, if the issue is still affecting you specifically, it could be a localization issue with your Czech OS (Czech being unsupported). I followed up via private message concerning Item 2 (another issue for which you are the only person reporting it) with some additional troubleshooting suggestions.

---

I will keep a close eye on it for the next day and report back! But definitely issue #3 as I just tested a few bad URL's but FireFox is fine just Opera and IE9.

 

TH

---

@ wrote:

I may have actually been a little behind the times concerning Item 1. Based on the most recent reports, that may have been fixed for most users as of 8.0.2.79 just a few days ago. TripleHelix, are you still missing the padlock? Pegas, if the issue is still affecting you specifically, it could be a localization issue with your Czech OS (Czech being unsupported). I followed up via private message concerning Item 2 (another issue for which you are the only person reporting it) with some additional troubleshooting suggestions.

Hi Jim,

 

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.

---

For me the Lock on the Tray Icon seems to be stable so far but the Web Threat Shield works fine on Firefox, IE9 but still not Blocked in Opera with Build v8.0.2.92

 

TH

 

EDIT: Just updated Opera to 12.12 and the Web Threat Shield issue still remaims.

---

We checked Item 1 against a stock Vista Business Sp2 32bit Czech localised OS with IE9, Firefox17, and Chrome23 this morning, and the Identity Shield  padlock did not appear.  We can conclusively say the issue is due to the localization.  Sadly, Czech is currently an unsupported localization, and until Webroot starts to support Czech systems, this problem will most likely persist.  With the localization being the known issue, we will provide this information to development and allow them to take the lead with any possible improvements.

 

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.

---

@ wrote:

We checked Item 1 against a stock Vista Business Sp2 32bit Czech localised OS with IE9, Firefox17, and Chrome23 this morning, and the Identity Shield  padlock did not appear.  We can conclusively say the issue is due to the localization.  Sadly, Czech is currently an https:///t5/Webroot-SecureAnywhere-Antivirus/Supported-Languages-Localized-Operating-Systems/ta-p/15166, and until Webroot starts to support Czech systems, this problem will most likely persist.  With the localization being the known issue, we will provide this information to development and allow them to take the lead with any possible improvements.

 

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.

:( all is bad :@

 

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.

---

We were able to verify the identity shield was still working last time you brought up this issue, so there is no reason to think that has changed.  This is ultimately just a cosmetic problem.

---

@ wrote:

We were able to verify the identity shield was still working https:///t5/Webroot-SecureAnywhere-Complete/Missing-padlock/m-p/4029#M1333 you brought up this issue, so there is no reason to think that has changed.  This is ultimately just a cosmetic problem.

OK, let's consider this as a cosmetic hitch.

---

@pegas i have a Polish Windows 7 OS and also suffer with missing padlock problem 😞 Can you do a Identity Shield test with Zemana ?  I run Zeman test app minimized to background and test app can get intercept all entered keys on visited https site ;/

---

@ wrote:

@ i have a Polish Windows 7 OS and also suffer with missing padlock problem 😞 Can you do a Identity Shield test with Zemana ?  I run Zeman test app minimized to background and test app can get intercept all entered keys on visited https site ;/

Hello hassasin, almost my neighbour ;)

 

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).

---

Pegas is right about having intentionally left it marked as Unknown because it's used for testing.  There are two ways to be protected from a keylogger.  One is the Identity Shield that would deal with a running Unknown threat.  Another is that a Bad file would be picked up as soon as it drops on your system by the Realtime Shield.  In fact, not too long ago, the Zemana keylogger was listed as Bad until we received notifications from users that they could not use it for testing the Identity Shield as long it was being picked up before it had a chance to run.  We made a point of setting it to Unknown from then on so it could test the Identity Shield. 

---

@ wrote:

Pegas is right about having intentionally left it marked as Unknown because it's used for testing.  There are two ways to be protected from a keylogger.  One is the Identity Shield that would deal with a running Unknown threat.  Another is that a Bad file would be picked up as soon as it drops on your system by the Realtime Shield.  In fact, not too long ago, the Zemana keylogger was listed as Bad until we received notifications from users that they could not use it for testing the Identity Shield as long it was being picked up before it had a chance to run.  We made a point of setting it to Unknown from then on so it could test the Identity Shield. 

Setting it to Unknown in other words mean that Identity Shield fails in the Zemana keylogger test file because all keystrokes are recorded. Please try it yourself, download the test file, run it and type something in a browser, all your keystrokes will be recorded. So I have to ask what benefits of testing of Identity Shield against Zemana then users have?

---

It is failing for you and hassasin in particular because you are on unsupported localized operating systems. If it's failing for anyone who is not on an unsupported operating system, we can certainly look into that. However, we cannot research your own case of this any further than we already have, because we have been able to conclusively identify that the unsupported localization is a defining factor in the problem.

---

@ wrote:

It is failing for you and hassasin in particular because you are on unsupported localized operating systems. If it's failing for anyone who is not on an unsupported operating system, we can certainly look into that. However, we cannot research your own case of this any further than we already have, because we have been able to conclusively identify that the unsupported localization is a defining factor in the problem.

Ok Jim, understood. However is any other way to verify that Identity Shiled is working correctly? Please understand that we, unsupported users, want to know that we are secured by Identity Shield in the real environment.

---

Are you sure you're using the testing tool properly? Remember, Identity Shield works by protecting programs that are listed in the Protected Applications list and are set to Protect. If you merely download the test keylogger, hit start, and start typing, yes you will see text appear in that box. However, if you change focus to a browser that is set to Protect and type into a field, it will not log the keystrokes in the testing tool. That would be normal function of the Identity Shield.

---

Sure Jim, I know how Identity Shield works. I am not a WSA newbee 😉 and you can be sure that I type in Opera and IE which are the both protected. Moreover I tried on encrypted PayPal web and others and I saw all keystrokes in the test file.

---

I'm sorry to hear that, and I'm sorry to say I don't have any good advice for you on this one.  If a feature works at all in an unsupported environment for which it was never specifically designed to work, that's a bonus.  If it's not working on an operating system it was never designed for, that's not a bug.  It just means the code to support that feature was never developed.  This goes back to the Localized Czech Support Idea in the Ideas Exchange again.  If Webroot decides to start supporting Czech, this feature can be coded.  Otherwise, for a feature to not work on a platform for which it was never designed to work to begin with is to be expected.

---

i must confirm what wrote Pegas, on my polish OS test keylogger has same behavior on chrome browser 😞

---

@ wrote:

I'm sorry to hear that, and I'm sorry to say I don't have any good advice for you on this one.  If a feature works at all in an unsupported environment for which it was never specifically designed to work, that's a bonus.  If it's not working on an operating system it was never designed for, that's not a bug.  It just means the code to support that feature was never developed.  This goes back to the Localized Czech Support Idea in the Ideas Exchange again.  If Webroot decides to start supporting Czech, this feature can be coded.  Otherwise, for a feature to not work on a platform for which it was never designed to work to begin with is to be expected.

Well, in other words your standpoint can be understood that all users who are using WSA on unsupported systems are mistakenly believing that WSA works correctly with just some aesthetic and minor issues like missing padlock, firewall failing on some applications etc. It's very serious affair and Webroot shouldn't downplay it. In fact you said that all Czech, Slovak, Polish, Romanian, Bulgarian etc. users have paid for a product that isn't working in its full scale. Be careful, someone could consider such acting as a fraud.

 

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.

---

There may be a misunderstanding or miscommunication here.

 

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.

---

@ wrote:

There may be a misunderstanding or miscommunication here.

 

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.

Thanks for the input. However I can't agree and it's a shame you didn't understand my point.

 

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.

---

In most cases, programmatically, it is nearly if not completely impossible to determine whether a given part is working properly or whether the operating system is just telling it that it's working properly.  The smiley was to show that I do have a sense of humor when I was comparing the requests.  What you are requesting is literally as possible as making it work and scan when the computer has no electrical power.

 

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? 

---