Omega Supreme's community posts

Hi Conrad,

Thank you for your answer! I indeed had found the option to uninstall the driver, so everything is working as expected.

Using version: 6.8.0.1

Hi there,

I noticed that on laptops it is not possible anymore to change the brightness of the screen after you've installed the monitor driver. I searched the forum and found 1 reference (6.5 Beta test) of someone experiencing the same issue. I do not use the monitor blank functionality, so for me it is not a big issue to uninstall the driver. So this is just to let you know about this issue.

I also wrote it in the comments about the app in the Play Store. The password to connect to a host is displayed in plain text while typing. To me this seems like unwanted behavior.

My phone: Google Nexus 5
Android: 6.0

Thank you for you reply Conrad, on a Sunday! :-) Really nice.

Ok, I am eagerly awaiting updates in the future. In the meantime I am a happy user of RU, considering to apply for a paid license and spreading the word about RU being a solid alternative for the competition.

Hi Conrad,

Thank you for your answers! It is becoming rare these days for companies to actively take part of a community, so it is very much appreciated.

I think having a certificate check is more in line with the current standard in identification so that is good news. On the other hand, it might make things a little bit more complex for the average user. But of course a lot of stuff can be automated (e.g. generating and signing certificates).

I don't think having a service running under a restricted account is a half-baked or ineffective solution. On the contrary! If done properly it can dramatically reduce the consequences of a security breach. I am more familiar with the Linux domain and there it is very common that a daemon (= service) does not run under an account which has system wide privileges like for example the 'root' account. Granted, a lot of daemons start running under an account with elevated rights, but only for initialization purposes and when they are ready they drop to a restricted account. I come to know that on the Windows platform a lot of services are running under accounts that have system-wide privileges (e.g. Local System) and I think this is bad design from a security point of view. Of course the service must be designed to work under a restricted account, if not then I agree with you that it is a half-baked solution and you might run into problems sooner or later. But I want to stress that having a service running under a restricted account is really an additional security layer and is not something to be taken lightly. Especially when this service is accessible from the outside. Improving security is done by adding robust and tough layers on different levels in the system. I really hope you take this in consideration and have a look at this topic.

Thanks again for your time!

Viewer version: 6.8.0.1
Host version: 6.8.0.1
Server version: 2.6.0.3

I have some security related remarks/requests of which I am not really sure that they have been asked before (the forum doesn't have a search function). Instead of making a topic per item, I will sum them up in here. I am running a self hosted RU Server and this is the focus of my questions.

The pre-shared secret is currently used for weak authorization. I really would like to see that you use it for strong authorization as well. See points 1 and 4 below.

1. When the host doesn't have a pre-shared secret configured but the viewer has, then the connection is prohibited without any information presented to the user. Blocking the connection is ok from a security point of view, but I would like to have a message saying something like: "Connection aborted, because host doesn't have the pre-shared secret". In the current situation I am guessing what is the reason why I cannot connect (e.g. network issue, host down?).

2. I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account. In case of a security breach, severe consequences might be limited in this case. I didn't try for myself if it is possible, thought I would ask here first. So I would like to know if it is possible and if not, please explain further.

3. As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server. This is really unwanted and from a legal point of view I am not really sure if this could lead to problems. If you would work with pre-shared secrets for hosts and server, RU Server could block incoming connections that do not have the pre-shared secret. Of course this could be a bit annoying for hosts that are configured for first time use, but I think there are lot of alternatives outside the RU domain to (manually) provide the hosts system with the pre-shared secret.

4. If the host has a pre-shared configured and the viewer doesn't, the viewer still can access the host. While this might be useful in some cases, I would like to have the option in the host settings to deny the connection when a viewer doesn't have the pre-shared secret.

This week I stumbled upon RU as an alternative (with the self hosting option!!! Great!) to  [censored] and I really like it. I would also like to see RU Server running on Linux, even it just has the basic functionality like the Relay option (which is what I intent to use it for). My whole server park is running on CentOS and I really would like to keep it like that, but for now there is no other way that to add a Windows server to it :-( .

Please consider creating RU Server for Linux.