Thanks, I do appreciate your extra info on how that works. What I was trying to say is that if all of them sent the email to distribute@RemoteUtilities.com, which contained only the ID number of the user, then on your side that ID could be linked to a delivery address. It would just be a fancy email forwarding system. That way a decompiled application wouldn't even disclose the business that owned it, it just has an ID number.
As your disclosure states, when the destination email address, and SMTP settings are retrievable, then unless someone did what I did, that email account could potentially contain all the ID numbers associated with the account. While I realize that there is some additional protection with the password, this seems like a nice option was all I was trying to convey.
After about a year of being a free customer, and having some trouble with the file transfer portion of the app, I had a great day using RemoteUtilities yesterday with almost no problems at all and decided to become a Pro customer!
While setting up the MSI Installer, I had an idea about the email notification portion that I wanted to share. Paid users could have an online account that links to their installer that allows them to configure some of the extra options such as the authentication and email notifications of a new ID being generated. Then the application rather than sending the notifications through SMTP could relay that info to RemoteUtilities (or other repeater?) where the info could then be emailed to the user.
The difference is that if the host gets decompiled, there is a chance of disclosure of where the emails are being sent, and maybe passwords as well. As it is I created a new gmail account, set it to forward to my normal account and then deletes it, wrote a script that auto flushes the trash every minute on that account so there is no record of it.
If my Viewer was linked to my account here, then I could set my notification options here, and you could even have each new connection randomly generate a 64bit password. I think this would dramatically increase the security for those using the notification system.
I completely understand your position, I myself am a programmer supporting a Windows service deployed in many environments that connects to 4 different types of databases on a schedule. I know it is hard to prioritize your time.
All I can say is that for me, the file transfer and sessions becoming disconnected frequently has been my biggest hangup going from a free customer to a paying customer. There are a LOT of things I really like about Remote Utilities, and I would love to purchase a license, but I get disconnected so often and have file transfers fail so frequently I am having a hard time submitting the order and sometimes just end up using Remote Utilities to help me get connected using something more stable.
Would I love OSX support, yes. But to me, the goal should be to solidify your existing customers experience before chasing a new market.
Thank you for the tip, I just looked at the file and found that it had been set to: <optFTPWidth>2559</optFTPWidth> <optFTPHeight>1309</optFTPHeight> <optFTPLeft>-2325</optFTPLeft> <optFTPTop>-645</optFTPTop>
After a couple minor adjustments it is working much better.
Thanks Conrad, in answer to your question, it doesn't remember my preferences. This is problematic when the client is also constantly getting disconnected, so I have to keep reconnecting, open file transfer, resize window again.
If the connection wasn't broken and I just connect, resize window, close it and reopen - it is a little smaller than the first time, but still shows up too large and spanning across 2 monitors.
I am using 18.104.22.168 viewer and when trying to do any file transfers with remote computers, the file transfer window is MASSIVE. Now on my computer setup I have 2 4K monitors, one is horizontal, one is vertical, and a 1080p monitor as well. The window shows up spanning multiple monitors and much be resized to see the entire window so you can see buttons and such.
Additionally, I have a very hard time navigating to directories, I constantly get errors, then after trying a few times it might work. Sometimes I have to just use Remote Utilities to initiate a VNC session so I can do file transfers it has gotten so bad.
For us updating the ID was easy, but it didn't solve the problem. I was connecting remotely to a client's computer using Visual Studio and the right click wasn't bringing up the menus, or more specifically context menus were not visible during the remote connection. Because of this, I used Remote Utilities to connect to the computer, get the [censored] ID and password and connect using [censored] where I could see the menus.
While using [censored] , my connection was never reset and operated smoothly for hours at a time. Large file transfers were possible without interruption, but the Remote Utilities connection was unstable for more than a few minutes at a time (5-20).
I still use Remote Utilities and like it, but this problem is not a networking issue, or at least it isn't an issue that isn't solvable by better try/catch blocks within Remote Utilities. My office is on a Fiber network which has only gone down 2-3 times within the last 4 years. The problem exists between each location I connect to and is limited to Remote Utilities and not [censored] connections.
I had considered setting up my own Remote Utilities relay host to see if that would help, but have just been too busy. It could be a connectivity issue between Utah and where ever the Remote Utilities server is hosted.