Dave Barton: Note that the actual security is not an issue here. The "feature" (or "limitation" if you prefer) is designed to satisfy the requirements of antimalware software. It doesn't matter if these requirements are useful or pointless, smart or stupid - it the application wants to avoid being tagged as malware, it has to comply. Having fought with a similar issue with some of my applications, I can understand the developer's frustration about that, but there is really not much else that can be done - antimalware is in practice a law upon itself.
As far as adding the ability to move to the window - I don't think it's that simple. It seems that the notification window it is not actually a window, so any movement code would have to be implemented from scratch - and any such implementation would create conflicts with the intended "click through" functionality. Given the amount of negative backlash of the feature, I would recommend implementing an option to sel ect fr om a fixed set of possible positions (all four corners plus the center of the top and bottom of the screen), that seems reasonably simple while still achieving the desired effect.
The message is not removed for my reverse (but still direct) connection, even though I am on 18.104.22.168. Doesn't bother me much AND I rather think that reverse connections should display the message (they are as easily exploitable as the Internet-ID-based connections), but it's clearly not true that "We have removed the notification for direct connections" - not for *all* direct connections you didn't.
I would like to ask for a modification to the Portable Viewer. According to the documentation ( https://www.remoteutilities.com/support/docs/portable-viewer/ ), it saves its configuration files in the directory with the .exe file. That is somewhat unfortunate because it encourages the insecure practice of having the program directory writable. While that is a common thing in portable installations, it would still be nice if the configuration files could be saved in a subdirectory (e.g. "Config"), because then the program directory could be kept read only and only the config directory would be made writable.
Or, an optional read-only file could be placed in the .exe directory, containing the path (relative to itself, preferably, unless the user entered an absolute path) to the actual configuration data.
It's not a pressing issue because of the undocumented mitigation factor that if the directory with the .exe file is read-only, then the Portable Viewer will store its configuration in %APPDATA% just like a regular viewer, but a modification would still be preferable - currently, it's not possible to have two Portable Viewers installed at the same time unless at least one of them is installed insecurely (as in, "it's possible to replace the .exe file with a malicious one").
Presumably there are some reasons for this limitation, but I find it very strange. It seems to make screen blanking pretty much unusable. Wasn't it better to use the old implementation with a dedicated driver then?
I did just try to upgrade from Host version 6.10.10 to 6.12 beta 2. Everything went far in that I can still connect fine and remote control works, but for some reason the image quality went way down: It seems that the screen from a 6.12 host is only sent in 256 colors rather than whatever is set in the connection properties (65536 by default on my setup, but as far as I can tell, that setting has no effect now). It seems that the fault lies with the Host (installable) rather than the viewer, because the 6.12 viewer displays fine when connected to 6.10.10, but once I upgrade the host to 6.12, I only get 256 colors.
I would like to add that even though Remote Utilities themselves take care of security, I still like to add another layer using an encrypted tunnel to route the RU traffic through. While this approach takes more setup time and more CPU power (double encryption), it does have distinct advantages:
1) More control over the actual encryption process. RU now uses TLS, but there isn't really much information on how exactly it is done. Every TLS version, including 1.3, can be used in an insecure manner. For example, all it takes to pretty much break the TLS security is to incorrectly implement certificate verification or the reaction to certificate verification messages of the used SSL library. Using a tunnel, I can control this very well, even add features not available in RU (e.g. a smart card may be required to perform the connection).
2) More control over the communication. Specifically, using a tunnel in conjunction with a firewall I can *enforce* that RU does not talk to anyone else than the intended target - all RU communication except for to/from the tunnel is automatically disabled. The documentation says that in a direct communication this is always the case, but with a tunnel+firewall, I can be sure - even taking into account possible errors in the implementation of RU.