Conrad Sallian's community posts

By the way, ESET informed us that the issue has been resolved and they removed the block. Closing this topic.

Hi David,

Thank you. Let's keep a single thread for this issue, please.

Hi David,

Thank you for your report. We will submit a false positive to AVG. We also encourage you to do the same from within the program.

Hi Martyn,

Yes, certainly, we'll take a look. Thank you.

Hello Martyn,

Thank you for your message. Is the actual installation successful (i.e., can you run the Viewer and use it), and it's just the log messages that you noticed? Or does this error make the Viewer unusable?

Hi Fatzke,

Ping will not work on id.remoteutilities.com because pinging is disabled for security purposes.

Hello Trent,

Could you please check if simple update works for your Hosts now? Thanks.

Hello Andreas,

Thank you for your message. This button should be clicked on the remote side, just once. For PRO license users, the window can also disappear after a 10-minute timeout.

Or do you mean that the window doesn’t go away even if the remote user clicks the OK button?

Hello Trent,

Thank you for the report.

However, the update has always worked that way, so it's strange that ESET suddenly decided to block that connection for this reason. Perhaps either their settings or policy have changed.

In this case, I would recommend contacting ESET to report the issue. You can reach their lab via email at samples@eset.sk, or, even better, post a message on their community forum: https://forum.eset.com/. If you are their customer, they are obligated to respond promptly and explain their actions.

Please, note that ESET might offer various explanations for not addressing the issue. These often sound like, "This program has been used in malicious activity" (in which case, ask them how a signed vanilla executable/installer is to blame for such activity). After all, there isn't a single remote access tool on the market that hasn't been used maliciously or for fraud activities.

Or they might say, "It was compromised" (compromised how? If the certificate was compromised, it should have been revoked, but it's still active). Lastly, they could claim, "It is used in cyberattacks as part of malware"—but isn’t it their responsibility to combat wrappers, droppers, and all sorts of 'ers,' while leaving legitimate (i.e., digitally signed) software intact?

Another favorite excuse of virtually any antivirus company is: "It violates the CSA guidelines." A simple question like, "Which specific CSA guideline does it violate?" usually results in frustration and an answer along the lines of, "We say it's a threat because we say so."

Hello Brad,

Thank you for your message.

Yes, that makes perfect sense. In fact, we would have implemented this earlier, but there are still some compatibility issues with older Windows HTTPS clients. The most practical solution is to implement HTTPS for newer versions of Windows (8 and later) as well as Windows Server, while still using HTTP on the older Windows versions.