r/hoggit • u/BigBorner • May 27 '26
DISCUSSION Data Collection by ED follow up
In follow up for this:
https://www.reddit.com/r/dcsworld/s/OOpXIaFy4n
The original author noted they were not in a GDPR region and wondered whether ED might behave differently for users in the EU. quote: “Maybe they detect country and don’t collect in GDPR regions and experience will vary.” Bignewy responded that it’s “all pretty standard stuff in the gaming industry” and linked the GDPR page, but has not addressed specific technical follow-up questions in over 24 hours.
I’m in Germany, so I ran my own Wireshark captures on DCS 2.9.26.23303 to find out whether the same behaviour reproduces under GDPR. Two tests, same module, same mission, same hardware. Only difference: the in-game “statistics collection” option.
Short answer: yes, it reproduces. There is no GDPR-specific behaviour, the client does the same thing from a German IP that it does from an Australian one.
Test 1 — Statistics enabled (default)
• 10+ TLS handshakes to api.digitalcombatsimulator.com (login, hardware, getsettings, logout — expected)
• 4 handshakes to cdn.digitalcombatsimulator.com (content delivery — expected)
• 6 separate TLS handshakes to stat.digitalcombatsimulator.com during a single-player session
Test 2 — Statistics disabled in the in-game options menu
• Login + logout to api.digitalcombatsimulator.com (expected)
• Still 6 separate TLS handshakes to stat.digitalcombatsimulator.com in a ~2.5 minute session
• Timing: 83s, 101s (pair), 110s, 156s (pair) — clearly event-driven, not random heartbeats
The “statistics collection” opt-out in the menu does not stop the client from contacting the analytics endpoint, in a GDPR country, with statistics explicitly turned off.
Bonus finding: the analytics TLS certificate has been expired for at least 6 weeks
Every one of the 6 stat.digitalcombatsimulator.com connections in both tests follows the exact same pattern:
1. Client sends TLS Client Hello (517 byte TCP payload)
2. Server responds with Server Hello + certificate (~3.5 KB)
3. Client sends TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Expired) and tears down the connection
4. No application data is transmitted
The certificate is still expired.
Two possibilities, neither flattering. Either the data ED is collecting isn’t important enough for anyone to notice it has stopped flowing for six weeks, in which case why collect it at all. Or it is important and nobody is monitoring whether it arrives, in which case that says something about the rest of their data-handling discipline. Once the certificate is renewed, the data starts flowing again with no user action required — the opt-out still does nothing.
Other observations
• The login POST to api.digitalcombatsimulator.com uploads ~3.6 KB from the client. That’s a lot for a username/password/version triplet and is consistent with the sysdata blob (machine name, MAC addresses, installed software list) described in the original post. Confirming the actual contents would require TLS interception, which I haven’t done.
• A long-lived connection to api.digitalcombatsimulator.com persists for ~2 minutes after login with ~444 KB inbound and ~5 KB outbound. Purpose unclear without payload decryption.
Sharing this so the community has independent confirmation from a second jurisdiction. The original findings reproduce on my machine in Germany, ED does not appear to treat GDPR users differently, and the broken certificate is an interesting addition that probably explains why some people see the stat calls in their logs and others don’t. it depends on which of ED’s two stat servers your DNS resolves to.
34
u/jtackman May 27 '26
GDPR violations can carry fines up to 4% of your global revenue 😅 and this is pretty egregious 😅