Conrad Sallian's community posts

Hi Márcio ,

I understand allright, so I hope you understand too - that notice will likely make you loose potentially paying customers that would gladly pay for your software in other situations. Just not this one.

This message is not visible for a commercial license owners. And it's not because we want to squeeze money from our free license users, as we explained earlier. We just wanted to put another obstacle to abuse of the 'out-of-the-box' free RU version. It was just too easy to abuse it - and as a consequence we had a lot of headache with antivirus software.

What truly made us losing our customers and getting refund requests was antivirus software blocking the program for our corporate clients, just because yet another "mom's hacker" used the free RU to remote into his ex-girlfriend's computere to steal some photos. Well, that is what kills customer trust, and not extra security measures.

Hello Márcio,

Thank you for your feedback.

I often use Remote Utilities to access my own computer from work, and there is nobody near my computer to click on the message to turn it off (if its clicklable from the host).

It is not removable even from the Host side. The idea of this message is to be shown permanently during a remote session.

Besides, the message content is absolutely useless. If I saw an authorized remote session to my computer while I was using it, I would simply unplug the network cable instead of typing or clicking a web adress with information regarding this situation. The whole message itself is rather nonsense. "oh no, my computer is being controlled by whoever knows and I'm going to open a site with information about it, nice". And this, while the other person is watching. And controlling my computer. Seriously? lol...

Without such a message the remote user might not even know that someone is being connected to their computer. This is because the Host icon may be removed under the expandable arrow in Windows system tray and may not be immediately visible. And even if it's visible in the system tray - not everyone knows what that icon means and they might not even know that such category of programs - remote access software - even exists.

If you are worried about that "someone" having access to the host options, then let them be set only on the host side, so that "someone" on the remote side can't change them. Simple, and only the user can set these options.

You are considering a scenario when the remote user knows about Host and willingly installed it or at least authorized someone to install it. However, this message is about a totally different situation, when a bad guy lures an unsuspecting victim to install this software on their computer - NOT when a remote user willingly installs it and knows what this software is about.

Of course, in most cases users and sessions are legit and this message can be annoying. But we did not invent the wheel here :) What is the percentage of thieves and burglars among the population? Rarely more than a few percent. And yet, we all HAVE to use locks and passwords, and safes and strong boxes and lock our cars just to protect against that small percentage of not-so-perfect citizens.

Ever thought why the society spends trilliions of dollars a year on security, including IT security? Yes, all because of them - 1-2% of the population not willing to follow the rules.

Hope you understand.

Hi John,

Connection types:

1. Direct connection. No intermediate server is used, Viewer and Host communication directly.
2. Internet-ID connection. An intermediate server is always used. This can be either our hosted server, or a self-hosted server, your choice.

Authentication methods (are enabled on the Host when you configure it):

1. Single password. No separate users, no logins, just a password.
2. Remote Utilities security (login and password pair and permissions can be set per user).
3. Windows security. Piggyback on Windows security model and use Windows accounts for authenticating on a remote Host  (or Active Directory accounts if on AD network).
4. Custom (self-hosted) server security. Using a self-hosted server for authentication. Somewhat similar to what a domain controller does in an AD network, i.e. acts as a gatekeeper and keeps all user authentication information.

Now connection types and authentication methods are not directly related. There can be any mix of them.

For example, you may use direct connection as your connection type, and use custom server security for authentication. In this case your Viewer and Hosts will only use your self-hosted server for that purpose (i.e. authentication) and not as a relay server for Internet-ID connection.

Another example, you may use Internet-ID connection through our hosted servers with Windows security authentication. That is, you can connect to a remote PC over the Internet and authenticate on the remote Host using the credentials of a Windows account on that remote machine (e.g. the local Administrator account). Of course, you must first add permissions for that account in Windows Security authentication settings on the Host.

While it's true that any combinations may be used, typically certain authentication methods are more often used with a specific connection type. For instance, using Windows security with direct connection makes sense because - as a rule - direct connection is used in a LAN or even a domain network and it's perfectly natural to use Windows accounts for authentication than to create accounts anew in Host settings (e.g. for Remote Utilities security).

Custom server security is a middle ground. It tries to bring the benefits of centralized account management to a scenario with Internet-ID connection used across remote machines scattered across the internet, i.e. not on the same LAN/AD.

To sum it up, you shouldn't bother with the self-hosted server (RU Server) unless it's absolutely necessary for your scenario.

Hope that helps.

Hi,

I notice that the new server update has a note saying "Minor improvements to RU Server license registration mechanism." - I thought this might be a fix to the issue however it doesn't seem to have changed anything..?

Do you mean the issue of not being able to add a license key to server without Desktop Experience installed on the machine?

Hi Bill,

Unfortunately, no. In Remote Utilities paradigm the update process is always "human-initiated" and is under control. If Hosts start to update on their own this may lead to VIewer-Host version mismatch issues in case Viewer is outdated.

We understand that nowadays many apps update automatically but Remote Utilities isn't a single app, it's a dual app. And it dictates some caution when it comes to updating. Especially when a remote computer is many hundreds of miles from the user.

Hi Peter,

Yes, we fixed that in the current release :)

Thanks.

Hello Andreas,

I will add your suggestion to our wish list. We will discuss this with the team and see what we can do.

Thanks.

Hi Greg,

I understand what you mean. Unfortunately, there is no feature that would do exactly what you describe.

However, somewhere close to it would be to enable the notification panel on the Host and simply click the X button on it whenever you want the remote session to terminate.

Hope that helps.

Hello Greg,

Thank you for your message.

Do both connections point to the same remote computer (e.g. one by Internet-ID and the other by an IP address)? Or are those completely different remote Hosts?

snk-nick wrote:

In the meantime is there a way to add the key some other way? I installed it on a local machine, added the key, but can't find where it's stored so not sure where I'd go to move it to the server.

Server keeps its configuration here:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities\MiniInternetId