IP is leaked by CLM_EMPTY_MESSAGE sent by the Directory to all Servers in its list

[dingodoppelt]

Alternatively we could simply ask any directory to not leak our IP. If that means we miss out on a few servers, so be it.
We could have a setting to enable it in the GUI which clearly explains the security implications of enabling the feature. It should be on by default though. Unless you have already blocked some IPs the pings will still reveal your IP so it is only useful if you have taken counter measures (of which there are none at the moment)

Originally posted by @dingodoppelt in #3545 (reply in thread)

[dingodoppelt]

My proposal is to create a new protocol message which requests the server list from the Directory but tells it to not send a CLM_EMTPY_MESSAGE to all servers so the user's IP stays hidden.
That will probably make a few servers unreachable so this option must be disabled by default. We could make it an advanced setting in the GUI or CLI argument. Servers reachable by --connect should still be visible in the list. It needs to be tested how many actually disappear.

[mcfnord]

About 35% need the punch.

You'd lose the ping durations that drive coloring and sorting, but this could be replaced with geolocation distance between client and each server. Slow to collect at first but cache would work. Maybe each server should reveal its lat-lon somehow.

[dingodoppelt]

About 35% need the punch.

Would be interesting to know if those are mostly servers on residential ISPs or in data centers.

You'd lose the ping durations that drive coloring and sorting, but this could be replaced with geolocation distance between client and each server. Slow to collect at first but cache would work. Maybe each server should reveal its lat-lon somehow.

I think with the current implementation the servers just wouldn't appear at all (except for --showallservers). We don't care because there would be no way to reach those servers anyway.

[mcfnord]

🤖 AI: Of the 34 Any Genre 1 servers needing punch: 18 are hosting/cloud (AWS, OCI, DigitalOcean, Linode, Hetzner, Vultr, Timeweb) and 16 are residential (Verizon, Spectrum, Shaw, Deutsche Telekom, Mega Cable) — roughly even.

[dingodoppelt]

I'm still thinking about not leaking the IP by default. The documentation should explain that ports need to be open in order for the server to be reachable, alternatively -e localhost and enabling hole-punching should do the trick at least for private servers.
Besides "KISS" and "Do one thing and do it well" we might want to add "Datensparsamkeit" (PbD) to our design principles as this gets more important every day.

[dcorson-ticino-com]

-- this could be replaced with geolocation distance between client and each server.

Please note that geolocation distance is pretty useless as a ping replacement.
I see a factor of about 2 between the best and worst servers from here to NYC.
That is, from useful to useless.

[mcfnord]

The documentation should explain that ports need to be open in order for the server to be reachable...

I agree.

[dingodoppelt]

Maybe the ping isn't as important as the server being shown on the list. On a connection attempt we could query the Directory to only provide hole punching assistance with that particular server the user wants to connect to. I'm still not a friend of the server list being designed "ping first" and therefore not sortable. If users could see all server and sort them by location they could find their preferred server more easily.

[mcfnord]

🤖 AI: I infer identity to provide geolocation at the state / province / region level — seems about 70% accurate, and kept that coarse on purpose. But any joker can run the same correlation, pin someone far more precisely, and harass them — which is exactly what the Privacy Statement's "not ... available to third parties" denies. The honest wording was already written and closed without merging in jamuluswebsite#1092: one edit, no protocol change. Honesty in the privacy statement has to come first — no charades.

Then the real fix, in two steps. Step one: separate identity inference from the IP, so a leaked address ties to no name — the direction of #3550. Step two: stop leaking client IP:PORTs to every server on the directory. The punch message is part of that — the directory hands your IP to every listed server whether you ping it or not. --connect should punch for parity — people expect it to "just work" like the dialog's connect — but that's convenience, not privacy: a punch followed by a join correlates as well as the dialog's ping-stop. A new flag, --connect-pingless, could take on the existing behavior of --connect.

[mcfnord]

Please note that geolocation distance is pretty useless as a ping replacement.
I see a factor of about 2 between the best and worst servers from here to NYC.
That is, from useful to useless.

So it's partly useful? I really like the idea of a server publishing its own lat-lon, because I think a lot of the geolocation failure is due to IPs changing their geolocation recently. But if servers self-identified locaiton (collaborating with the operator and a service, presumably), that'd limit the error opportunity to the client, and there the user could again confirm or modify the claimed lat-lon.

[dingodoppelt]

--connect should punch for parity — people expect it to "just work" like the dialog's connect

Nonetheless we should introduce a new protocol message for that. This message would only assist in hole-punching for that particular server and not every server in the list.
Down the road we could have the connect dialogue do something similar if we can figure out how to display servers that can't be pinged without hole-punching.

Edit: something like --connect [DirectoryAddr]:<IP>:<Port>