Carl here (Obscura CEO, one of Mullvad's partners)
This was an interesting finding, though as kfreds mentioned it would have been better to notify the vendor before publishing.
The main finding (IP-position-in-pool correlation between servers) seems to include genuinely unintended behaviour. Given our great experience with the Mullvad team, I'm sure this will be addressed soon.
In general, if you want different "identities", you should make sure to rotate or use different WireGuard keys.
One small thing from the article I'll comment on:
> Surprisingly, the exit IP you are given is not randomized each time you connect to the server, but deterministically picked based on your WireGuard key, which rotates every 1 to 30 days (unless you use a third-party client, in which case it never rotates).
Context: WireGuard is by design[1] a "Connection-less Protocol", there's no concept of a connection, there's only a "re-keying handshake" (key here refers to the ephemeral Diffie-Hellman key, not the WireGuard key) every 2-3 minutes ONLY IF there's traffic flowing.
The above statement is not too surprising if you consider the counterfactual: What would happen if, even with the same WireGuard key, the exit IP were randomized each time you "connect" to the server (say each time there is a "re-keying handshake" or at more frequent cadence (e.g. every 15 minutes) than the WireGuard key rotation).
In this scenario, ~every 15 minutes:
- At the Transport layer, all your in-tunnel connections that are on non-roaming protocols (basically everything except QUIC) would be disrupted, and the connections would have to be re-established.
- At the Application layer, many application-level sessions that treat "same cookie, new IP" as suspicious would trigger logouts, CAPTCHAs, or risk scoring.
Both are terrible UX, and what's worse would also make users much more uniquely fingerprintable ("this person keeps reconnecting from a different IP, they must be using Mullvad").
[1]: https://www.wireguard.com/protocol/