No one mentioned PI-HOLE? If you all haven't looked into it yet I would strongly recommend it. Cheap and amazingly effective.
I prefer my code to just not try this, but that's certainly a valid option. Hosts file edits work too, due to lazy code.
If wanting to go that route:
127.0.0.1 cdp.cloud.unity3d.com
127.0.0.1 config.uca.cloud.unity3d.com
127.0.0.1 perf-events.cloud.unity3d.com
127.0.0.1 prd-lender.cdp.internal.unity3d.com
127.0.0.1 thind-gke-usc.prd.data.corp.unity3d.com
127.0.0.1 thind-prd-knob.data.ie.unity3d.com
127.0.0.1 remote-config-proxy-prd.uca.cloud.unity3d.com
127.0.0.1 data-optout-service.uca.cloud.unity3d.com
127.0.0.1 redshell.io
127.0.0.1 api.redshell.io
127.0.0.1 treasuredata.com
127.0.0.1 api.treasuredata.com
Add the above to your system hosts file, and watch as Unity gets mad and stops trying.
Anyhow, new release inbound soon. Working on killing the remaining traffic. What's left isn't much, but it's certainly too much.
Crosspost from my post in TPU news about our current 1 "bug":
Here is an opt-out error log still transmitting some limited data, even with my plugin:
After substitution some Unity data is still transmitted in first release (0.1_18 series). See the following log from a kind user report: It isn't much, but it's far TOO much for my goals. Critical ...
github.com
Relevant JSON response from Unity Server in the log:
"connect": {
"enabled": true,
"limit_user_tracking": true,
"player_opted_out": true
},
"performance": {
"enabled": true
}
You will note that though the player has clearly opted out (""player_opted_out": true") it still thinks it's ok to track performance related things (connect is enabled, as well as performance logging).
An example of a transmitted "performance metric" packet that still slips through with my plugin (bug report currently up for this)
Content-Type: application/json
X-Unity-Version: 2019.2.2f1
Content-Length: 365
JSON [m:auto]
{
"common": {
"appid": "39811e89-d29d-4faa-bb01-997f3cda24f0",
"build_guid": "15721da0da695412299517d99c2e4d2a",
"deviceid": "unknown",
"localprojectid": "5be2ef0cdad9b1344ae103b0d475456b",
"platform": "LinuxPlayer",
"platformid": 13,
"sdk_ver": "u2019.2.2f1",
"session_count": 14,
"sessionid": 8372668789457274197,
"t_since_start": 3118069,
"userid": "1ddb05956cce640a48c123610a72c706"
}
}
I believe I can address this by building yet another dummy class for UnityEngine.UnityAnalyticsModule.dll That's a big dll (relatively speaking), but I'm trying. It's slow work. Dan was tired and may have just woken up. That slows me down, too.
EDIT We have new release v0.2, testers wanted:
Binary distributions of my other Unity Telemetry related projects. Basically a custom coded dll stack that replaces Unity methods and kills "analytics" or telemetry of most sorts. Also ...
github.com
Unfortunately it is Unity 2019 and KSP 1.8 only. 2017 support is temporarily on hold due to
this.
EDIT: Also, v0.2 still has some data leaks. Track the issue here:
After substitution some Unity data is still transmitted in first release (0.1_18 series). See the following log from a kind user report: It isn't much, but it's far TOO much for my goals. Critical ...
github.com