Conrad Sallian's community posts

Hi Steven,

I try to keep the client and host versions in sync, but its not easy because the client will prompt for an update regardless of the host versions on the backed.

This can be disabled in Viewer Options -> Update. Besides, the update is never mandatory, the program just notifies you that a new version is available but it's always up to you whether to update or not.

In this case the client got updated first, then the RU server. The connection that got deleted was an older version (6.10.5) of the host software.

The Host version shouldn't be affecting the sync mechanism in any way. An address book record is just a record, its contents doesn't really affect how the sync mechanism works. We tried the same update order but didn't notice any issues.

See the attached screenshots images of the windiff of the files. The left side is the 2.7.6 version of the address book. The right side is the same address book after the 2.7.8 update. It appears the 2.7.8 update made some changes to the address book that may have caused the account I was using to lose access to the connection entry.

Yes, this is interesting. Could you tell me how exactly you set permissions for that book? Did you enable full access to the entire address book at the top level or was it more granular (folder- or even connection-based)? The more details the better - this will help us better reproduce the problem if it's somehow related to permissions.

Looking forward to your reply.

Hello Steven,

We have just quickly tested a scenario where we updated Viewer, then (without doing a sign in on the server) updated server, then signed in on the server and got the address book synced normally. There were no issues.

Now we are testing different scenarios, e.g. updating server first, Viewer second, and with different sign in states. That is why we asked in which sequence you updated the modules. Perhaps, the order was different in your scenario and we could thus try to reproduce it.

Looking forward to your reply.

Hello Alan,

Thank you for the clarification. Still, this requires a centralized system with our service at the center, and this is exactly what we moved away from (due to abuses of the system and antivirus software being angry at us about that as a consequence).

However, we may look closer at this idea when we start implementing an online account.

Hello Alan,

Thank you for purchasing a license!

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.

Let us know if you have any questions. Thanks.

Hi Jorge,

That is good news. Thank you for the update. We'll be looking forward to a confirmation from other participants in this thread.

Hello Jorge,

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.

Hello Jorge,

Thank you for your message.

Did you try contacting the firewall manufacturer?

Hi Richard,

All three modules are important. It's only that we decided based on our user feedback that Viewer will be the first to go.

Hello Richard,

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.

Thanks.

Hello Richard,

Thank you for your questions.

Is a MacOS client currently being developed? (I don't want eta just if it is currently being developed)

Yes, this is what we are currently working on.

Is there anything we (as customers) can do to get the MacOS Client quicker? (As it is one of the only downsides of this software)

Unfortunately, no.  

Is there anyway we can develop our own MacOS client?

Sorry, but there is no way for that either. We do not accept third party code and even volunteer language translations.