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.
When a Remote Utilities Full Control connection to a computer ends, the computer gets locked. That's as it should be. However, I am encountering an undesirable locking behavior in conjunction with short disconnects:
1) Viewer connects to a Host in Full Control mode and controls the computer for a while. 2) A momentary disconnect occurs. 3) Viewer tries to reconnect in five seconds and succeeds. 4) Viewer can still control the computer for a while. 5) After a short while, the computer gets locked.
This is definitely incorrect. I suspect it is caused by the fact that disconnections can't get detected other than by missing a timeout and when that occurs, the Host doesn't care whether a connection is still available and simply locks the workstation. Unfortunately, it means that a computer may remain unlocked for some time and that someone can connect to a computer and work with it without unlocking. I think these fixes should be considered:
1) Decrease the timeout for "connection lost" on the Host. It might be a good idea to make it user-configurable.
2) Do not lock workstation on "connection lost" if another connection is active.
3) A Host configuration option to *also* lock the workstation on each Viewer connect. Default: Not active.
4) A Host configuration option to mitigate #3 in such a way that if the same host (identified by e.g. a nonce sent by the Host to the Viewer during the previous successful connection) reconnects without being properly disconnected while the workstation is not locked, #3 will be skipped for this Host. Default: Active.