I feel this thread isn't long for this world, but before it gets locked....
From a developer point of view, analytics are really important. Users are almost completely useless at submitting meaningful bug reports and far far worse at reporting about things that they don't even see (obviously!).
Analytics are essential for understanding how your software performs under real world usage. Just submitting crash reports when it completely fails is far from adequate (that's like waiting for a postmortem result before deciding on treatment). Most (half competently built) software shouldn't crash over minor issues, it should error handle and carry on, but the user doesn't know that's happened so they can't report it. But that info can provide devs with an insight into where design flaws are or where the system fails to scale. Knowing how fast users move through a particular part of the interface can help identify unknown bottle necks and shows you how your users actually use the program (which honestly is something that never fails to surprise me), which leads you to know what areas to enhance.
That's info that no amount of QA/testing can ever reveal.
I feel that by saying "No" to all analytics starves the developers of useful info and disconnects them from their project once it's out in the world. In the end blocking all analytics doesn't benefit the community.
We want a well optimised program, well, then we need to allow the developers to collect data.
However, the behaviour of companies in recent years has resulted in a loss of trust, which is understandable.
So do we actually know what data KSP is reporting?
I've been trying to look into what files get touched as a result of running KSP. This is on Linux, so.....it's not windows, it'll be different there (someone else can run traces in windows).
I used strace like this to see what files are hit
strace -f -t -e trace=%file -o ksp.trace ./KSP.x86_64
That returns a lot of info, so to condense it I stripped out all other data apart from file paths and removed duplicate references.
What I was really interested to see was which files where touched in my home directory (excluding those that are inside the KSP directory).
here's what I saw:
Nothing there causes me concern. It's certainly not rampaging around in my home folder trying to "gathering everything [it] can".
What about outside of the home folder?
Well, that's a much longer list (few thousand lines, so not going to post that here) and I gotta admit I'm somewhat out of my depth in understanding what all of it is. But over half of the files touched where all within /usr/share/fonts (it touches everything in there, somewhat wft) and the majority of the rest of the activity was in /sys/devices/ and /usr/lib. well, it's gotta find out how to talk to your computer!
The only place where it does seem to be a bit overzealous is in the /tmp folder, but for all that I know, it's simply listing the files in there.
Again, I don't see anything that causes me alarm.
Now that's just files that are touched. NOT what's being reported. That I don't know, will need to find a way to inspect traffic and I'm not familiar with how to do that.
But from what I can see, it's not doing anything unruly like rummaging around in places it has no business being in.
A couple points raised earlier about consuming bandwidth.
Now I've got a terrible internet connection (I'd bet it's one of the worst in this community; 6mb down, 0.2 up, if I'm lucky). But worrying about bandwidth consumed by analytics, just seems a little over the top. It'll be kbs of data being transmitted, we're talking 10-20ms to make the request. Is that really worth the effort in locking it down? Honestly, there's probably a greater penalty in game as it waits for a response that never returns and has to timeout.
The other point about 'the opt out should be client side'.
consider this; You start playing KSP, all enthusiastic and you just click through the initial dialogs, 'yeah whatever, lemme at them boosters'. But sometime later you come across this thread and think hmm, maybe I'll disable analytics. Now if that's done client side, at best you have to trust that as you hit disable, the last thing it does is send a request to the server saying please delete everything for this unique id, or at worst you are now completely cut off from whatever data has already been collected and now have no reference to ever request it's deletion.
Which ever way it's done, you still have to trust that at the server side your request to be forgotten is honoured.
I 'm not sure about this, but being done server side should mean that once set, all your KSP instances follow that rule, at least on that machine. Done client side, you'd need to remember to set that option in every KSP install you have.
Have a look at the docs for Unity Analytics -https://docs.unity3d.com/Manual/UnityAnalytics.html
The 'core' and 'standard' events are exactly the kind of thing that are of great value to developers looking to understand how their users use the software. They don't include anything unpleasant and it's not marketing data.
KSP's developers can define 'custom' and 'transaction' events; we can't know what those are....however looking at the docs for them, I'd be surprised if KSP makes any use of transaction events (as there are no monetary transactions/ads in game) and there is probably little use for custom events (*speculation).
Overall, I'm happy with what I've found. And because I feel that providing info to the developers is important, I'll be leaving analytics switched on.