jamulussoftware
Randomize and adapt ping intervals in connection dialog to reduce correlation
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:
- introduced enum for UserRole data on LVC_NAME.
- cache host and port on first use, no need to resolve it every time (in UserRole data)
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
- [x] I've verified that this Pull Request follows the general code principles
- [x] I tested my code and it does what I want
- [x] My code follows the style guide
- [ ] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
- [ ] I've filled all the content above
Thank you very much. It looks interesting but also seems to add a lot of complexity. Definitely this will rather be a Jamulus 4 feature. I don't have time for a review currently, but I approved the autobuild to allow artifacts for each OS to be built.
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. But that probably also comes with drawbacks
@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 https://github.com/jamulussoftware/jamulus/discussions/3545#discussioncomment-14778543
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.
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.