and having some trouble with the file transfer portion of the app
Sorry for that, we will be re-writing the File Transfer module some time soon.
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.
Implementing an online account is indeed in our plans for the future. However, making the installer send emails via our company-hosted script would be a step back to the mechanism which we have abandoned in favor of the "SMTP method".
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 you mean Host access passwords, they are not disclosed. When you choose "Automatically generate Host password" the password is encrypted with a public key on the Host side. In order to decrypt it one needs the private key which only resides on the Viewer side, initially in the Viewer where you actually built the installer although you can also copy the key to another Viewer.
If you mean the SMTP password though, it's indeed can be extracted from the installer but that's "by design". There is simply no other way to simultaneously protect the SMTP password and use it on the same Host. We explicitly warn the user about this:
Also, we do suggest that the user avoid entering their primary email account credentials and instead use a "disposable" email account for that single purpose of receiving Host notifications. Even if someone gets access to those emails they won't be able to connect to Hosts because of the above mentioned reasons - they won't be able to find out the password because it is never sent plain in an email. Besides, there is also two-factor authentication which can be enabled for added security.
Yes, but you can not ask them why they were totally blocked? ... so that it does not happen again
If only they would even respond to our messages. They never bothered to answer to our direct twitter messages, and their technical support is only available after you log in as their customer. We called them on the phone and asked for a contact person with whom we could figure out how to resolve the issue but the call was forwarded to an automated voice response system and was never answered by technical support.
Why should we care about WatchGuard customers more than WatchGuard does? We are eager to help you - you can see that we respond almost immediately. But there is little we can do if some third party "security" company decides to block our software all of a sudden. We could ask for a reasons for such blocking if other firewall manufacturers did as well, but this is obviously not the case.
What parts are you currently developing for MacOS?
We are currently working on Viewer for Mac. Host and Agent will be made available some time later after that. As for Linux versions - since the code base is almost the same for Mac and Linux there is a good chance that Linux versions will see the light at the same time as Mac versions.
May I also ask how many developers the company has? (I understand if you would rather not let us know)
Sorry, we do not disclose such information. We are a privately owned company, not a publicly traded one.
Will beta versions be publicly released or internal only?
Yes, of course we will provide a beta version for open testing and maybe even show the alpha too.
We do our best to help as fast as we possibly can. However, this specific issue isn't a fault of Remote Utilities. It is an issue with WatchGuard Firewall/Firebox erroneously blocking our legitimate service (as reported by several different users/customers already).
Moreover, judging by a yesterday's tweet addressed to WatchGuard Remote Utilities isn't the only service that was affected.
We recommend that you as WatchGuard customers contact them too and ask for this issue to be resolved as quickly as possible.
We have hundreds of thousands of users that utilize the Internet-ID connection. 3-4 reports do not make the problem systemic - otherwise this community forum would have been flooded by tens and hundreds of messages and that we cannot observe. There are numerous external reasons why an Internet-ID connection may not properly work at a given time and place.
Only logs can tell for sure what is happening. Therefore we kindly ask you send us your Host logs to firstname.lastname@example.org for our examination.