Document Correlation Attack

[rdica]

Short description of changes
Provides knowledge base entry to document current correlation attack in progress, and provides mitigations for clients and servers.

Context: Fixes an issue? Related issues

Relates to https://github.com/orgs/jamulussoftware/discussions/3545

Status of this Pull Request

What is missing until this pull request can be merged?

Does this need translation?

Checklist

• I've verified that this Pull Request follows the general code principles
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I'm sure that this Pull Request goes to the correct branch

[ann0see]

I'd frame it more neutral as some users might want to be tracked to use the service.

I'd like to have a neutral review by @mcfnord

[mcfnord]

I believe this is technically called a side-channel attack rather than a correlation attack.

[mcfnord]

The FAQ at https://jamulus.live now says:

Q: Does this web page collect data? What happens to the data?
A: This web page collects details about users on public Jamulus servers, including IP addresses. The IP addresses are never shared, and are erased after 15 days. As a public service, this web page associates a geographic region with each IP address. This web page complies with GDPR, Europe's privacy law.

• To prevent details about servers you join from being shared with this web page, block outgoing UDP traffic to 24.199.107.192 using your router or computer firewall.
• To prevent details about musicians that join your server from being shared, block incoming UDP traffic from 137.184.43.255. If you do this, your server will not appear on this web page.

[mcfnord]

134.199.209.51 is not an explorer instance, and correlation only occurs on 137.184.43.255. I see how they probably look similar, and one might think there are two explorer instances involved. In harvest.cs, client metadata is collected immediately before level nibbles, and I refresh server cards with this signal, but all correlation occurs in the 137.x.x.x instance and nowhere else.

[pljones]

There are explorer instances collecting lists of Servers and users running from 137.184.43.255, and 134.199.209.51. They are hosted on DigitalOcean instances.

Maybe

There are explorer instances collecting lists of Servers and users running from 137.184.43.255, and 134.199.209.51. They hosted by DigitalOcean.

[mcfnord]

There is no explorer instance collecting lists of Servers and users on 134.199.209.51. That instance uses UDP as a quick refresh of visible names. Not collected!

Ping IP addresses come in to 24.199.107.192 (where the Trio servers are), and are paired with pseudonyms gathered at 137.184.43.255 by a servers.php replacement.

So why also harvest them at 134.199.209.51? To assure the visual list is most current, especially because I pair that UDP request with one for audio nibbles, but also just as a currency refresh of the UI as compared to the cached list. The servers.php replacement is more responsive during prime time for a server, but less responsive during quiet hours.