KDE Connect mDNS: Nuremberg Megaspring Part 2

-  Simon Redman

Sprints are a great time to talk in real-time to other project developers. One of the things we talked about at the KDE Connect part of the “Nuremberg Megasprint” was the problem that our current discovery protocol often doesn’t work, since many networks block the UDP broadcast we currently use. Additionally, we often get feature requests for more privacy-conscious modes of KDE Connect operation. Fixing either of these problems would require a new Link Provider (as we call it), and maybe we can fix both at once.

A New Backend

First, let’s talk about discovery. The current service discovery mechanism in KDE Connect is we send a multicast UDP packet to the current device’s /24 subnet. This is not ideal, since some networks are not /24, and since many public networks block packets of this sort. Alternatively, you can manually add an IP address which then establishes a direct connection. Manual connections work on many networks with block UDP, but it is a bit of a hassle. Can we find a better way to auto-discover services?

A few months ago, a user named rytilahti posted two patches to our Phabricator for KDE Connect service advertisement over mDNS (aka avahi, aka nsd, aka …). The patches were for advertisement-only (it still doesn’t establish a connection) but they were a good proof of concept to show that mDNS works on many institutional networks which block UDP multicast since mDNS is frequently used for other things like network printer discovery which are desired by those institutional networks.

I would post a screenshot here, but I don’t want to spread details of an internal network too far

At the sprint, we talked about whether we would like to move forward with these and we decided it was useful, so Albert Vaca and I put together two proof of concept patches to start trying to establish a connection using mDNS advertisements:

• Android: https://invent.kde.org/kde/kdeconnect-android/merge_requests/91
• Qt/C++: https://invent.kde.org/kde/kdeconnect-kde/merge_requests/147

The patches are not yet fully working. We can both see each other and attempt to establish a connection but then something goes wrong and one of them crashes. Given that this was less than 8 hours of work, I would call this a success!

There is still plenty to do, but it was very helpful to be able to sit in-person and talk about what we wanted to accomplish and work out the details of the new protocol.

More Privacy

Before we talk about privacy, it helps to have a quick view of how KDE Connect currently establishes a connection:

• As described above, both devices send a multicast UDP packet. This is what we call an “Identity Packet”, where each device send its name, capabilities (enabled plugins), and unique ID
• If your device receives an identity packet from a device it recognizes, it establishes a secure TCP connection (if both devices open a connection, the duplicate connection is handled and closed)

As long as we are talking about a new backend, let’s think about ways to make KDE Connect more privacy-conscious. There are two problems to address:

• Device names often contain personal information. For instances “Simon’s Phone” tells you that “Simon” is around
• Device IDs are unique and unchanging. Even assuming I rename my phone, you can still track a particular device by checking for the same ID to show up again and again

Solving the first problem is easy. We want the user’s device name so we can display it in the list of available devices to pair with. So, instead of sending that information in the identity all the time, have some “discovery mode” switch which otherwise withholds the device name until a connection to an already-trusted device is established.

This leaves the second problem, which quite a bit more tricky. One answer is to have trusted user-selected trusted wifi networks, so KDE Connect doesn’t broadcast on a random wifi that the user connects to. But what if I connect to, say, my university network where I want to use KDE Connect but I don’t want to tell everyone that I’m here?

We don’t have a final answer to this question, but we discussed a few possible solutions. We would like some way of verifying ourselves to the other device which conceals our identity behind some shared secret, so the other device can trust that we are who we say we are, but other devices can’t fingerprint us. It is a tricky problem but not yet one to solve. Step 1 is to get the new mDNS backend working, step 2 is to add advanced features to it!