@ wrote:

The smiley was to show that I do have a sense of humor when I was comparing the requests.

OK, I could have exaggerated but in the context I felt it was quite sarcastic. Anyway, I do apologize.

 

@ wrote:

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.

OK, that's needed to be said and you're right. Accepted.

 

@ wrote:

There is no programmatic manner by which to accurately detect all or even most cases where the software may not fully operate.

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.

@ wrote:

... most other AVs actively work to hide operational failures ... 

That's a scandal! And I have a faith in Webroot they keep out of such practices.

@ wrote:

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.

Hmmm, interesting. Thx for the explanation. BTW, is this valid also for the Czech OS? 

---

@ wrote:

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.

Appreciated and as I already said a coin has two sides ;)

 

@ wrote:

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? 

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,

pegas

---

I apologize as well, it was not intended to be sarcastic.

 

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.

---

Thx Kit for your time you been spending with thorough explanations to my points/requests/views which I admit now some of them were silly. Please accept my cordial apologies. I never intended to offend you or Webroot. Now I know that if I had known all things you had patiently explained me, I wouldn't demand such thing. We have the same aim ... the best AV product ever and I will always think twice before I ask for issues which are time consuming to reply and impossible to implement.



Wishing you quiet X-mas holidays.

---