Conrad Sallian's community posts

Hello Yaek,

Please, note that it's only McAffee that detects our software as "artemis" (a virus) and this is a false positive. We currently have a response from McAfee that they are considering our false positive report.

As for other detections, these are "riskware", "not-a-virus", "potentially dangerous" etc. It means that the program by its nature is dangerous (remote access software) if misused. Although we usually ask a/v software vendors to also remove that classification, but it's up to them whether to mark a certain program as such or not.

Hope that helps. Don't hesitate to ask me if you have other questions.

Hello Mike,

You need to upgrade first before we can tell what is happening. Please, upgrade to version 6.3.0.4.

However, I can tell that if you can't connect to any computer , then the problem is probably on the Viewer side. Make sure that no antivirus /firewall is blocking the program's network connections.

Hello Allan,

We received a response from them just now. They say that's it's still "malware". Funny thing is - they call the threat "Undetermined malware" and they don't even give any details as for what type/class of "malware" it is.

We will keep sending the requests though.

Allan Knox wrote:
By way of an update, I have just successfully downloaded the zip file on Internet Explorer and it not only downloaded without a qualm, but also passed an inbound file security scan.

The last time when Google/Chrome detected our zip archive as "malware" , a couple of months ago, they responded to our request very quickly and removed the false positive within hours. So we hope they will be as quick this time.

Strangely enough, they don't detect Viewer and Host as such , although the zip archive is nothing more than just the same Viewer and Host msi files zipped.  It seems like they don't even look at the contents, and simply "detect by name".

Allan,

Yes, this is a so-called "not-a-virus" category. The file is not necessarily deleted, Kaspersky is only warning the user that the software is "potentially dangerous" meaning that it can be dangerous if misused.

Hello Allan,

Yes, thank you for reporting this. It's all the more strange to see such a false positive given the fact that we removed the "hide tray icon" feature in the last version just because antivirus programs used to frown upon that.

Anyway, we have just submitted a request to Google to reconsider their "detection".

Hi Michael,

I can only say that I tried to explain our point as best as I could, specifically the reason behind this feature update.

Thank you for your input!

Hello Mike,

It looks like connectivity issues. Can you connect to the remote computer at all? That is, using a certain connection mode like Full Control or Terminal etc.

Also, what is the old version you are upgrading?

Hi Michael,

because the user may not own the computer (as you mention below) they may be an employee. or in my specific case they are my children. do you have any idea how mischievous and curious children are? they can also be very smart when it comes to technology when they want to be. at this time due to the many issues I've seen in version 6 I can not and would not use it in a business environment nor would I feel comfortable recommending it to my customers.

This is what Windows standard user accounts are for. A regular user, an employee is not supposed to be an administrator on their machine where they can do anything , including messing with the Host.

And by the way, even before we disabled the "Hide tray icon" feature anyone with the administrator account could simply open the processes tab and end/kill rutserv and rfusclient processes, thus stopping the Host.

So showing the icon or not showing the icon doesn't really make any difference in regards with the user's ability to stop/uninstall the Host if their system privileges allow them doing so.  

many reasons.. for 1 perhaps they use the computer for non business activity and "think" RUT is used to spy on them?? when in fact it's used to connect when necessary to resolve issues.

Remote Utilities is remote administration software, not employee surveillance software. These are two different markets/niches.

I am a computer consultant. a huge amount of our customers are SMB. many of my customers do not have the resources to manage and secure their network properly, when we recommend GP, strict firewall policies, block local admin access etc. it ultimately requires more administrative resources, knowledge and money.. they do not have the time to deal with user requests like installing basic software on the users pc etc etc) they also don't have the money to call me every time something like this happens. unfortunately this is reality. especially in the SMB market. I can recommend and preach a high security environment until I'm blue in the face but it is ultimately their decision,

That is true, no doubt. But hiding the Host icon in the hope that the user will not know about it and hence won't be able to stop it means fighting the effects, not the causes. The true cause is incorrectly set security policies. There is always a user or two who know what remote access software is and how it manifests itself in the system. So they'll be able to easily stop it regardless of its icon status. :)

I need to add that I absolutely understand your concern and that hiding tray icon is really a convenient feature, well, at least in certain situations. But Remote Utilities is used in an environment where antivirus/security software is king. We need to play by their rules if we want our program to be accepted and trusted by larger audiences. We cannot just send false positive requests demanding a/v vendors to stop treating us badly. Instead, we need to find a common ground and understand what can be done in order to resolve this issue for good.

Michael,

It sounds like your breaking/bending at the behest of 1 user. (not good if you ask me..) and by the sound of it not a very experienced user at that, especially if he trusts any software that has antivirus or antimalware in its title.

I'm sorry, but you misunderstood my message. That was just an example, an anecdote as I'm trying to sound as human rather than as a corporate bot and explain our position rather than speaking like a pr person :)

Our decision regarding removing the "hide tray icon" couldn't be more serious and well-thought. The same is true just about any other feature that we are planning to add or remove. You can only see the end result of it, i.e. the actual addition or removal, but there a long process of discussing and thinking a few months or even years prior to that where we weigh all pros and cons.

how do I prevent a user from stopping the host? I reviewed the information in your blog post. however it does not seem to prevent a user from stopping the host via the start menu/all programs. it can also be done via services.msc

There is a broader question - why would the technician want to prohibit the user from stopping the Host when they wish to do so? Provided that they know what the Host is about.

If the user wants to stop the Host running on their PC using services.msc, then:

- they are an advanced user, apparently, if they know about services.msc and use it to stop the Host at all costs
- they don't want the Host running on their computer, so they are perfectly in their own right stopping it

So we are getting back to the question implicitly posed in the blog post/news about this update: if the software use is perfectly legitimate and the user knows they have a remote access software installed on their PC, why would they want to stop it? But if they want to stop it, why would anyone prohibit them from doing so? Except only in a business setting where computers do not belong to employees - but it should be handled by policies on the network/Active Directory level.    

Yes, you can hide the Host menu or protect the Host settings, but that's mostly to prevent the user from messing with the settings inadvertently. These features have nothing to do with truly prohibiting the user from being the ultimate master of their own PC  :) If it's not their PC, they are not supposed to be an administrator on it, and hence they won't be able to stop the service if they have insufficient privileges.