Randomize and adapt ping intervals in connection dialog to reduce correlation #3550
Conversation
- make sure that after the dialog is hidden all server get a ping soon, also distant ones, but still in a way that it is not regular pattern - use randomized timer interval of 1000-1250ms since the real interval is calculated internally by skipping, also changed this to be smooth scaled - cleanup the map stuff, just store this in the Qt::UserRole data - network address is costly, cache it in Qt::UserRole - renamed things a bit and cleanup
…e normal 2500ms ping interval otherwise the longer delay will be treated as a stop of ping, fPingMaxMultiplier is now 3.0 instead of 9.0, could be increased in the future...
- store all data in UserRole of first column, no need to have an invisible column, - added enum for userrole fields - detailed stats only in debug - some minor adjustments on timings
src/connectdlg.cpp
Outdated
| qDebug() << "\nPattern analysis:"; | ||
| qDebug() << " Average pings/sec:" << QString::number ( avgPingsPerSecond, 'f', 2 ); | ||
| qDebug() << " Spikes detected (>2x avg):" << iSpikesDetected << "seconds"; | ||
| qDebug() << " Distribution: " << ( iSpikesDetected > 10 ? "IRREGULAR (many spikes)" : "SMOOTH (good stealth)" ); |
There was a problem hiding this comment.
I set up a time-out when a burst of pings arrive from one IP:PORT, because I thought these were non-clients. Then my own client triggered the time-out for bursting pings. Seems odd for the client to do this.
|
Thank you very much. It looks interesting but also seems to add a lot of complexity. |
|
I had some more thoughts about the goal of this. I don't think that we're going to fix the root cause with this. Alternatively we could probably have some IP block such that the directory doesn't forward client IPs if the clients request not to for specific client selected IPs. |
|
@ann0see thanks for taking a look. regarding complexity: IMHO the change is not that complex, everything is done inside the dialog class, and when removing the debug/statistics code (which I can if requested) the change is very compact. IP blocking: maybe I dont get it, the directory does not forward the client IPs, they are derived by detecting regular patterns and correlate them with the users joining and leaving. see the discussion in https://github.com/orgs/jamulussoftware/discussions/3545 The root cause cannot be "fixed" without big impact to the user experience (seeing who is online on which server, getting info on latency for each server...). What is possible is that we can randomize the usage pattern so that it is very hard to do this kind of "fingerprinting". Its a common approach to randomize or"fuzz key fingerprinting surfaces, e.g. browsers do this on the order of TLS extensions, add noise to the canvas rendering, or even add some noise to the audio so that this cannot be used to identify the client. For jamulus one leak is the ping pattern. |
|
I am a bit confused. I thought the problem is getting the client IP by correlation. As far as I understand It's possible to block a server and then it would not get the respective IP. As far as I know the directories must tell the servers the client IP to allow hole punching. And that's where the IP leaks. If the client tells the directory to not forward its IP to server X we should be fine, no? |
|
no, I dont think so: if you have the connection dialog open the client will ping each server in the list to get the ping time, constantly every 2500ms. To record those messages you just need to register a jamulus server at the directory, and since you control the server you can capture all ping messages with their timestamp and IP. In addition, log the active users on each server via the explorer php or via your own tooling. When a user connects to a server the connection dialog will close and stop the pinging, and a new user name appears on a server. With some interval heuristics you can then correlate those events (user name with client IP). AFAIK CLSendEmptyMes used for hole-punch is only sent once when the client requests the server list from the directory, its probably too coarse to do a correlation. |
|
But still the monitoring server will receive the client IP. This should not happen. |
Of course it will, otherwise it could not reply to the ping. The capturing of the IP address by the correlator is happening at the pcap level by a separate program, not within Jamulus. |
|
@softins Yes. But if the user does not wish its IP to be sent to some server he can also not expect to use it in any way -> no ping and no connection |
|
I disagree with this reasoning. When my client sends a ping to measure round-trip time, that doesn't constitute consent for unlimited logging, processing, or analysis. The 'you sent it to my server' argument doesn't justify unrestricted data collection and processing beyond the protocol's intended purpose. With this change the processing gets way harder, since there is much more "ping noise" on the wire. End users dont know which servers are the ones collecting data, so there is no easy way to block them. |
4 participants
Short description of changes
To avoid correlation on client behaviour this change will randomize the ping intervals, adaptive to the ping time, nearer servers get pinged more often, distant ones less.
To avoid correlation of "hide connect dialog" (ping immediately stops) and "connected to a server" (user appears on a server) it will keep pinging for approx. 60 seconds after the dialog gets hidden.
In addition:
CHANGELOG: Randomized and adaptive ping intervals in connection dialog, keep ping running after some time after dialog gets closed.
Context: Fixes an issue?
See https://github.com/orgs/jamulussoftware/discussions/3545
Does this change need documentation? What needs to be documented and how?
No.
Status of this Pull Request
What is missing until this pull request can be merged?
Unsure if the diagnostic code (currently only in debug builds) can/should be kept in.
Checklist