ragzilla

As I understand it, in the code you linked (which I'm abstaining from reading to maintain my ability to maintain a clean-room re-implementation) a GUID is generated, which uniquely identifies the KSP install. While I do understand the benefit here (prevents double counting installs), I feel there are better ways it could have been handled (mod hours played, or asking for explicit consent to generate the GUID, or making the whole thing opt-in in the first place and not bundling it with other mods). I'll happily pull down this plugin once it's been demonstrated that modstatistics has been implemented in a way which respects the user's privacy by default. My criteria for that is: - Removing/prohibiting 3rd party distribution, or prominent notification during first KSP load. (to address consent) - Majiir publishes a privacy policy. (to address utilization of data) - Prominent notification during first KSP load to accept the creation and use of the GUID. - Not reporting on every other mod and assembly in the KSP installation. Mods should have to utilize an interface to ModStatistics to report on their mod, it shouldn't collect wholesale information about the KSP installation.

I don't think this is the best thread to have this discussion in (general would seem to be a better place), but you're in favor of APIs being copyrightable, to prevent people from making alternative implementations? This was a fairly major case recently (Oracle v. Google) which I'm personally hoping gets appealed again or we may see some great software (WINE, ReactOS) start to disappear. Sadly due to Oracle v. Google mods like BetterThanSpyware, and StillBetterThanSpyware may be considered copyright violations under US law (since you can copyright an API now apparently). I'm hoping that if Squad is listening they'll side for the users and explicitly disallow copyright of API as it prevents other plugin authors from developing alternative implementations (like BetterThanSpyware and StillBetterThanSpyware) if there's a need.

It queries the assemblies loaded into the current .net application (KSP), and finds any using the name ModStatistics. Then it queries them for their _version attribute (thanks fwb for the interface documentation there) and when StillBetterThanSpyware is queried for it's _version attribute (ModStatistics does this to ensure only one instance is running, since it's crapware shovelled into a half dozen other addons you end up with several instances) it responds with the highest _version + 1 so all the other instances think a newer version of ModStatistics is present and running. This only works if StillBetterThanSpyware starts first, hence the 000_StillBetterThanSpyware folder naming. And editing the .cfg file is a fine workaround for people who are familiar with computers. Many software developers (myself included) fall into this trap of assuming their users are more capable than they are.

The notification was a late night addition after a few beers, and I've committed to revising it once ModStatistics does not resemble Spyware as much as it does in the current implementation. I know Majiir's intentions were good, but he's had plenty of people giving him feedback on how his current plan was a bad idea, and continued down this path anyway. - It gathers information - I do not explicitly consent by installing it, or having an opportunity (without going into a config file) to prevent statistics collection - It asserts control by re-downloading itself. Although this does have explicit consent so I'll give it a pass. 2 out of 3 ain't bad. It provides a mechanism to track a KSP installation as the user changes locations, this was serious enough for the IETF to develop privacy extensions for IPv6, it's a violation of EU Privacy Directives (no opt-in for the GUID), it's serious enough to be concerned about.

The information about my KSP install (and the mods installed therein) is MINE. What right does anyone have to export that data without my explicit permission? I'll summarize how I think ModStatistics should have been implemented (and maybe if Majiir had listened to the dissent leading up to the 0.24 release, would have implemented this way). - ModStatistics should have not been bundled with other mods/plugins. This is the crux of the spyware/crapware allegation- the fact it's shoveled in with other software people do want. - ModStatistics should present an Interface (like blizzy's toolbarmanager interface), and provide an API in the form of a wrapper (again see blizzy's excellent toolbarwrapper) for plugins which use ModStatistics, to register themselves with ModStatistics. - ModStatistics should only collect hardware information after explicit consent of the user (see Steam Hardware Survey and their random sampling, opt-in protocol) - ModStatistics should not generate a GUID for the install, or any other unique identifier for the installation- unless the user consents. This is how people handle 'Mostly Invasive' tracking cookies in the EU at least- Get. Explicit. Consent. I guess going opt-out, bundling with popular addons/mods, and collecting information on every mod the user has installed was easier than implementing something which respects the user's privacy.

A quick question for people who object to the existence of this plugin- how many of you are modders who stand to benefit from the statistics collected? Did a mod sign me up for the KSP forums without my consent? No, I went and clicked 'Register', and read the agreement, and decided that Squad's privacy policy was something I could live with. Where was the consent when I got modstatistics shovelled in with FAR (oh, yeah one or two lines in the OP which I'll posit most people don't read when updating during a KSP update). Add onto the fact that ModStatistics, as it's currently implemented, crashes other mods by making assumptions about their .net version (which I don't think anyone blames Majiir for- can't test everything, but this mod does provide a workaround), it feels right to offer users an easy way to make the choice to not use ModStatistics.

"Instead of installing a mod which blocks the objectionable mod, you should just go through EVERY mod you download, EVERY time you use it, and delete the mod you don't want!" Or you know, use something which blocks the mod you don't want running. I've tried to address Majiir's reasonable request to not start a mod war with the distribution restriction on this plugin. So now you're all arguing that users should not have access to a plugin which prevents what some people feel is questionable behavior. At least with StillBetterThanSpyware you get to choose whether to install it or not.

What about the user who doesn't have the knowledge to go in and edit a config file (because they're confused by the 'Open With' dialog), the ones who only know how to right click > unzip to their KSP folder? They just get their privacy rights violated? Everyone that says "You can edit a config!" has incredible amounts of computer knowledge the AVERAGE user does not have. The fact you can talk intelligently about navigating to the folder, opening the file with a text editor (knowing what program to use in the Open With dialog) puts you head and shoulders above the majority of users on the Internet.

I've checked the source, and it creates a Guid on first run which is used on subsequent runs to identify the installation of KSP. This is an issue with EU Privacy Directives (it's a Mostly Invasive identifier), and has been enough of a privacy issue when encountered in IPv6 to spawn an RFC to _prevent_ this kind of tracking of end users (IPv6 auto address assignment rules embed your MAC address in your IPv6 address, which allowed tracking of a user as they moved between networks). Until it's explicit opt-in and not bundled with other mods, it's crapware.

You know why this is happening now? Right after 0.24.0? Because people are going out and re-downloading their mods to get 0.24 updates, and finding crapware bundled along with it. It's the same sort of public backlash we saw when they started bundling the ask.com toolbar with Java, and Conduit with uTorrent. Except in those cases they ASKED you during the install, they didn't just go ahead and install it. So we're more into Bonzai Buddy and WildTangent territory here.

If the user has StillBetterThanSpyware installed I'm assuming they don't want ModStatistics running. Theoretically that line should never get triggered unless someone creates a 000_ prefixed folder with a lower name than mine (which would be deliberately trying to circumvent this plugin based on the mod folder naming I've seen so far, most people don't need to insert that early in load order). It does seem somewhat alarmist in the light of day- I'll revise it once ModStatistics doesn't resemble spyware as much as it does right now.

Based on some of the things I've been seeing from moderators, I'm not sure that's 100% true, but let's put it to the test! Sorry for the cross thread advertising but it seems relevant at this point to link to the plugin I just posted, StillBetterThanSpyware - a clean-room implementation of the ModStatistics interface, to block ModStatistics. It's also legally dubious in Mexico.

StillBetterThanSpyware 1.1 for KSP 0.24.0 Are you tired of: Your data being collected without your being notified, for someone else's benefit? A mod which just won't go away after you delete it's folder? Being told you should just go through every mod you download to check it for ModStatistics, or to "just write a script to delete it every time you launch KSP" Crashes in your other mods caused by Modstatistics? Maybe StillBetterThanSpyware is for you! This is a clean-room reimplementation (to WINE/ReactOS standards, you know the ones who create reimplementation of Microsoft's APIs) of the ModStatistics API/Interface documented by fwb at GitHub, none of the original IP from fwb or Majiir is used in this implementation. Download | Source | License (MIT) Frequently Asked Questions Q: How do I opt out, and resume sending data to ModStatistics? A: Just delete the 000_BetterThanSpyware directory in your KSP GameData folder. Unlike certain other plugins, we don't self replicate so there'll only be 1 copy of StillBetterThanSpyware in your GameData folder (unless you love it so much you install it twice). Q: I'm a modder, and would like to include this plugin with my mod/addon/plugin. A: Not really a question, but in the interest of preventing a plugin war, I would ask that you don't bundle my plugin with your distribution. Q: Why is this necessary? A: Myself, and several other players, have found it disturbing that someone would write a mod which collects (and uniquely identifies) information about a KSP installation. This seems to us to be a violation of several countries data collection policies (notably EU, Canada, and Mexico), and the manner of distribution (encouraging other software vendors to include the plugin in their bundle) is suspect, and reminiscent of spyware/crapware. Q: I'm convinced, how do I install? A: Simply download the latest release .zip from the download link, and extract to your KSP folder. Q: How would you have implemented ModStatistics? A: I'll summarize how I think ModStatistics should have been implemented (and maybe if Majiir had listened to the dissent leading up to the 0.24 release, would have implemented this way). - ModStatistics should have not been bundled with other mods/plugins. This is the crux of the spyware/crapware allegation- the fact it's shoveled in with other software people do want. - ModStatistics should present an Interface (like blizzy's toolbarmanager interface), and provide an API in the form of a wrapper (again see blizzy's excellent toolbarwrapper) for plugins which use ModStatistics, to register themselves with ModStatistics. - ModStatistics should only collect hardware information after explicit consent of the user (see Steam Hardware Survey and their random sampling, opt-in protocol) - ModStatistics should not generate a GUID for the install, or any other unique identifier for the installation- unless the user consents. This is how people handle 'Mostly Invasive' tracking cookies in the EU at least- Get. Explicit. Consent. Update History v1.1 - Change wording in popup dialog v1.0 - Initial Release

MechJeb and Firespitter user here, no crashes I haven't attributed to something else. People crashing with MechJeb, are you also using blizzy's toolbar?

To solve everyone's fears the plugin needs to not be distributed by 3rd parties. That makes it 100% opt-in and eliminates the need for the self replication code people have objections to (it would presumably still have a self-update capability, but not as pervasive as what's there now).

At this point, your distribution scheme for ModStatistics is fairly close to spyware/crapware, based on the following criteria: - The auto-replication code (which wouldn't be necessary if there was a single instance of ModStatistics, in it's own GameData directory, you know like if it was explicitly installed by a user. - It defaults to opt-in (although you've said you're fixing this), but this wouldn't be an issue if the user had to explicitly opt-in in the first place by downloading the mod separately. - Unique identification of the user (addressed further below). I'm not sure I subscribe to your slippery slope argument of e.g. MechJeb including a ModStatistics disabling plugin, since the point of the ModStatistics disabling plugins are to disable something that was shoved into the user's computer in the first place. That concern could be addressed by re-licensing the disabling plugin using a 'No License'/ARR license, and not granting any 3rd parties distribution rights. Yes but that random number uniquely identifies my installation of KSP. It identifies it at home, it identifies it at work, it identifies it at the coffee shop (fun fact, a whole lot of work went into designing privacy extensions into IPv6 because of this concern with MAC addresses). Hashing it does nothing useful (since the purpose of a hashing function is to produce the same output for a given input every time). I know it seemed like a really good idea at the time, but this, coupled with encouraging mod authors to bundle your DLL in their distributions, really makes this, potentially quite useful, plugin look like spyware/crapware. Oh and this unique identifier would likely be classified under the "Fairly Intrusive" category of the EU Cookie Directive, if someone were to lodge a privacy complaint against you in the EU.

On first start it generates a GUID and saves it to the config file so it can be reused on future runs, so yes that does serve to uniquely identify a KSP install. And it'll even track with the user across multiple networks (remember you're making a web request, so the script on the far end has access to your IP address which is presumably logged).

Getting an intermittent crash in toolbar entering the VAB. Seems to be a race condition almost as it's more likely to happen if I'm clicking quickly through things. Seems related to this thread on the unity forums, the tl;dr is: [MechJeb2] Adding button for Delta-V_Stats (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [MechJeb2] Adding button for Vessel_Info (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in <filename unknown>:0 at UnityEngine.GUILayoutUtility.BeginLayoutArea (UnityEngine.GUIStyle style, System.Type LayoutType) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginArea (Rect screenRect, UnityEngine.GUIContent content, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginArea (Rect screenRect, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 at Toolbar.Toolbar.drawToolbarBorder () [0x00000] in <filename unknown>:0 at Toolbar.Toolbar.draw () [0x00000] in <filename unknown>:0 at Toolbar.ToolbarManager.OnGUI () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Crash!!!