local

So, what was the point of mentioning "an user with an Arabic name "? Your statement implies that the license was cancelled because was registered to an user with Arabic name. Careful here....

So, ESET cancels a license because was registered to a user with an Arabic name ??? I hope you realize that this statement may have legal implications?

We do not live in a perfect world , but the expectation from a new version it is not to fix 5 bugs from previous version and create 10 new on its own. ESET is growing in complexity beyond the capability of a regular user to handle it, with over 120 possible settings altogether. At the same time some other vendors (Avira for example) can manage with just several setting to get 100% on AV Comparatives.

can you give me one-two examples when ESET acknowledged an issue and did not blame the customer???

Since this is a very important exam, to avoid any possibility, why don't you uninstall ESET for the duration of the exam???? Doesn't matter what settings are you going to change, still you will be in doubt.

No, he doesn't mean that! dpa said : "if I use the amtso.org site, the phishing test will produce a Detection, however that detection does not send out the desired alert." So ESET will produce a detection but doesn't send out by email .

That is true, however what I can see is Bitdefender , Kaspersky even Microsoft which offer free antivirus , did it quite well 99.9%.

I downloaded eicar in a double ZIP and ESET did not react while I downloaded it. Only when I scanned I got the detection. So, is ESET still "unpacking" double zipped files during the download????

If every S.M.A.R.T software returned a healthy SSD , I will not replace it. Do this: create an image with ACRONIS, install another SSD , restore the image and see what you get. ESET has this tendency of blaming something or somebody else , every time you point the finger to them. What would you expect, a statement like " Yes, indeed, our software destroyed your SSD"????

Why replacing SSD when you clearly can see that is ESET related???

Regardless of the rule to block AdobeARMservice, ADOBE X still will connect to update servers using svchost.exe, which typically is allowed for Windows updates TCP 80/443

I just gave you an example of a non-malicious item (Adobe) using svchost.exe to check for updates. The firewall should be able to alert you about this.

some applications are using svchost.exe to connect to the internet. A benign example is Adobe X pro, which will check for updates, even though you block the updater of Adobe. Similarly, a malware can use svchost.exe to communicate outside. The purpose of a firewall is to monitor everything; why use a firewall if you ignore the alerts or blindly select "allow" ????

But, when I review the firewall rules, 1month from now, how I am suppose to remember that I allowed this svchost.exe because was related to Windows update , if in the rule is just an IP ????

So, you are saying that the alert may not be accurate?