Currently, without authentication this would appear to allow any user on the local network to control a machine as soon as someone installs deskconn? And so the only difference with avahi-control is that it can be advertised - so someone passively connected to the same network could become aware there is now another machine which they could easily control (whereas previously they would have had to actively scan for such a machine via nmap or similar).
I agree with @jdstrand this appears too much of a security risk for the user (in either case but especially in the case with avahi-control) so I also vote -1 on auto-connect until an authorisation & authentication mechanism is implemented so that only trusted devices on the same network can control deskconn.
The authentication mechanism is in place now, a non-authenticated client on the network is no longer able to access/control the computer.
Below is how the mechanism works
the desktop computer calls the command deskconn.pair
==> that prints an OTP (valid only for 30 seconds)
The client (could be an Android phone) then generates a SigningKey and sends its newly generated public key and the otp to the computer
==> If the OTP is found to be “correct”, then the public key is saved in a database
==> That completes the pairing
Now that authentication is added, we can revisit auto-connection.
@om26er - I understand that announcing the service is desirable as a feature, but it isn’t clear to me why it should be autoconnected. This is certainly a convenience, but perhaps the deskconn user doesn’t want to advertise its existence on the network but instead have clients put in a hostname/ip address directly?
Does the deskconn snap allow turning off announcing? Is it on or off by default?
The service is similar to KDE Connect (or GSConnect, which is for GNOME Shell). The discovery on the local network is indeed a convenience but something that I want this project to have to make the user experience as seamless as possible.
FWIW, I was previously using https://pypi.org/project/zeroconf/ in my project, it works just fine with the network/network-bind interfaces since zerconf is just a tcp based protocol. However the great thing about avahi is that it “announces” on all interfaces and I don’t need to provide the IP address of my wifi/ethernet interface.
@jdstrand I want to mention that this request was previously made for my snap named deskconn but now I want this request to be for deskconnd (note the extra ‘d’ at the end).
I have split my project into two snaps: deskconnd is the router/server that handles authentication and discovery and RPC/PubSub deskconn is one of the client that exposes screen brightness/locking.
That change was done to make the router usable for other projects, aka plugins.
PS: I will be showing that project at UbuConEU in October.
Is this planned? I’m inclined to allow auto-connection, but know that personally I like to be in control of what is announced on the local network and suspect other users would be too.
2 votes for, 0 against for auto-connection of avahi-control and avahi’s ‘services-content’ content interface (note, you must use ‘content: avahi-services’) of the ‘avahi’ snap to the deskconnd snap.
