https://bugs.kde.org/show_bug.cgi?id=471994
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
--- Comment #1 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
This sounds like it should be multiple separate feature requests, but they are
also not necessarily the best ways to reach the goal mentioned in the
description, so the title is somewhat misleading about what may be needed here.
The current public key comparison by the user during pairing should already
cover identity security as a starter.
Given that many people/entities are afraid of the mentioned overlay networks,
it's likely more palatable to focus on the goal of connectivity when the
devices are either not in the same logical network, or a direct connection
between them is forbidden. This issue can be approached by multiple ways:
- You could probably already do this by using a P2P VPN taking care of most of
the hurdles and connecting the devices by IP address. Unfortunately the current
common FOSS options aren't too great as most of them don't tend to take care of
common P2P needs like peer discovery and NAT, but sacrificing some security and
using proprietary options like ZeroTier or Tailscale could already work as a
solution. This is obviously the easiest approach from the point of view of
developers as there's nothing to change in KDE Connect for this to work.
- Generic SOCKS support would implicitly support some overlay networks too. Not
fully sure about the development effort, but both Qt and Java seems to have
okay support for it. Likely the Java side is the more interesting one, at least
I'd run a Tor service on the desktop side and let the phone connect through it
through Orbot as one possible way. The "Add devices by IP" option deceivingly
implies the restriction of accepting only IP addresses, but then later the
prompt is asking for "Hostname or IP address", so given proxy support an onion
address may work without further work. Do note though that common Tor and I2P
implementations aren't really focusing on what's needed here, so for example I
wouldn't expect proper handling of the primary route failing while another
route is available, at least not before let's say Tor adopts MPTCP, but not
sure if that's even being considered currently.
- A native full-blown P2P implementation with all the bells and whistles like
Syncthing would be the best, but it would also require the most development
effort. I wish there would be a FOSS VPN solution that's as good as Syncthing
to be piggybacked on with the proxy option, although a native implementation
would be always superior mostly on mobile devices with limited battery life.
This could be still combined with the usage of an overlay network if more
privacy or security is desired.
--
You are receiving this mail because:
You are watching all bug changes.
