Question re: Add-on Posting Rules [July 24th 2014] - going into effect August 21st 20

[TriggerAu]

I have a reasonably specific use case for someone from Squad re: section 5 of the new posting rules which is pasted here for simplicity:

5. Data Gathering

If your plugin gathers data on the user or sends data to another network or computer system an opt-in design is required and the user must unambiguously agree to participating before any data is sent. You must clearly disclose the extent and goal of the data gathering; it is further required you provide the users with an opt-out setting in the KSP Main Menu and you must provide the users with a way to access and permanently delete the personally identifiable data collected from them.

In the case of a couple of my plugins I have an update checker that will run once a day when the game is in flight mode. It sends a GET request to a page that I put on a Google Site (as that's free) and receives a version number code back, thats all the network traffic.

My Question is - Does this constitute Data Gathering from this section as it sends data (ie a GET request) to another computer?

I ask as the Google Server will see the IP Address of the computer, or is that not sufficient to trigger the requirements listed, must there be some actual data in there.

The second part is that if I do need to comply with that I need to:

1. Disable it by default
   
2. add functionality at the Main Menu scene for users to change this setting - is there a plan to expose some way for us to integrate with the Main menu to facilitate this
   
3. provide a way for users to see and delete data collected from them - in my case this is probably trying to find some other method of hosting the version file as I cant see that from Google either
   

Just to qualify, I dont want to start a discussion about the points in the post (or other posts), just some clarity about what this means practically - from someone with the authority at Squad to give guidance on this

[blizzy78]

As it is, the whole "sending data" is ambigious. What exactly constitutes "sending data"? Is an empty HTTP request to some remote server "sending data," although the actual payload is empty? In order to get information from the outside, there has to be some request.

I'd like for this to be clarified in the mod posting rules.

Edit: Also, is it "opt-out" or "opt-in"? The rule mentions both. I'm confused.

Edited July 24, 2014 by blizzy78

[RSF77]

My opinion doesn't really matter, but I absolutely despise update checks in mods for any game. Minecraft mods, for example, are extremely agitating as far as this goes. Depending on your firewall, security programs and other things it can wreak havoc on simply trying to play the game and enjoy yourself.

Anyways, not trying to be offensive, I just really hate update checks.

[blizzy78]

Okay, everyone has their opinion, I guess. But let's not turn this into yet another discussion thread

[Guest]

I ask as the Google Server will see the IP Address of the computer, or is that not sufficient to trigger the requirements listed, must there be some actual data in there.

Your server logs the IP address of the request and it is personally identifiable information so that would, in fact, fall under a very strict interpretation of the rule. OTOH, I don't think that really falls under the intent of the rule which is to set a standard by which usage data may be gathered. If intent were to be strict the rule would have read something like "If your plugin makes a connection to the internet for any purpose" or something. To be safe, though, any sort of update checking scheme should be opt-in. You don't really have access to Google's logs so I don't possibly see how you could provide a method for the user to delete their transaction log; in fact, that's a really bad thing to let the user have access to anyway.

Also, is it "opt-out" or "opt-in"? The rule mentions both. I'm confused.

I think the intent of the rule is that, if the software sends data to a server (a POST request with fields, for instance), the user must be given a clear choice whether to opt-in when the plugin is initially installed and must also have a clear method to opt-out at any time, from the Main Menu of KSP. An update checker that simply asks for the current version never sends data and thus would not fall under the intent of the rule.

I do, however, completely agree that the wording is somewhat ambiguous. This may be by design but there was talking the other night that changed the wording to indicate "personally identifiable data" rather than "data" because otherwise any data gathering scheme would have had to identify the data with a user (as opposed to simply gathering anonymous usage stats) and that leads to all sorts of strange cases and privacy concerns.

[blizzy78]

I do, however, completely agree that the wording is somewhat ambiguous. This may be by design

Which, of course, is really bad when it comes to rules. If you want everyone be treated equally, you can't have ambiguous rules.

I think the intent of the rule is that, if the software sends data to a server (a POST request with fields, for instance), the user must be given a clear choice whether to opt-in when the plugin is initially installed and must also have a clear method to opt-out at any time, from the Main Menu of KSP.

How would that look like? Always open a window at the main menu so that you can revoke your opted-in permission?

-----

Back to the rule in question - I'd also like some clarification on whether it is required for mods to function unchanged if the user opts out of sending data.

Edited July 24, 2014 by blizzy78

[Guest]

How would that look like? Always open a window at the main menu so that you can revoke your opted-in permission?

No idea. Maybe SQUAD has some sort of menu dock in mind that they'll add? Is it required to annoy your users?

[blizzy78]

Maybe SQUAD has some sort of menu dock in mind that they'll add? Is it required to annoy your users?

I think so, at least the rule says something like that:

it is further required you provide the users with an opt-out setting in the KSP Main Menu

I don't see how that would work without a window of some sort that is always visible.

[Xaiier]

The discussion in the #KSPmodders IRC yesterday came to the conclusion that the intent of the rules was such that a simple update check which did not send any data did not fall under these rules.

20:34:25 if all you do it read data (eg the most recent version number) then there is no issue

(this may be subject to change)

[cpast]

Back to the rule in question - I'd also like some clarification on whether it is required for mods to function unchanged if the user opts out of sending data.

Especially for things like multiplayer mods, which literally cannot function properly without sending data to other computers?

[blizzy78]

The discussion in the #KSPmodders IRC yesterday came to the conclusion that the intent of the rules was such that a simple update check which did not send any data did not fall under these rules.

Then the rule must explicitly state that.

[KasperVld]

I can confirm that simply retrieving data from a server (such as a version number) is not the thing we're trying to regulate here. The fact that a mod uses a TCP/IP protocol or an HTTP request which sends data like your IP address in itself does not change that. I'll have another look at the exact wording of the rule but it's a really sensitive issue where a misplaced comma or period can cause issues. Once and if we change the line in the rules I'll notify you guys about it

[TriggerAu]

I guess some discussion was unavoidable, but good to see its all on track.

KasperVld, I guessed that wasnt the intent and understand the heat around this from other threads and difficulties with getting the language 100%. For people who come along later and/or have not been involved in the IRC chats the clearer that post is the better it will be for Squad, Modders and Moderators. Examples in that post after the points would make it much easier for people without the knowledge of any other chats - like me

Personally I'm OK to work stuff however is necessary according to the rules, but a couple of example use cases in the rules would go a long way to making the intent understandable, and more importantly what modders need to provide to comply. I do worry however that without some form of Squad provided hooks on the Main menu the screen is gonna be somewhat of a mess.

[DuoDex]

My worthless opinion on the effect of the new rules on multiplayer addons is simply that the addons will add a dialog box if you click on their buttons in the main menu.

...opt-in design is required and the user must unambiguously agree to participating before any data is sent...

I'm thinking of DMP here. DMP is not bundled with any other mods, and a simple dialog box after clicking the DMP button in the main menu stating "You are now connecting to an outside network. The status of vessels you build while connected to the network, your IP, and information about mods you have installed will be collected." should cover that.

...further required you provide the users with an opt-out setting in the KSP Main Menu and you must provide the users with a way to access and permanently delete the personally identifiable data collected from them...

Opt-out seems to be not clicking the DMP button. I'm worried about the "access and delete personally identifiable data collected from them" though.

[KerbMav]

Opt-out seems to be not clicking the DMP button. I'm worried about the "access and delete personally identifiable data collected from them" though.

That could mean, that whatever the application sends anywhere should be logged on the users computer for him to access and inspect.

If it also means for the user to be able to delete this data on the receiving end ... ?

[blizzy78]

If it also means for the user to be able to delete this data on the receiving end ... ?

It would be quite silly to just delete the local copy

But I agree, the rule is not specific which data has to be deleted on request.

[IceBadger]

I think there is some more information that should be included to comply with various laws, better to be safe than sorry right?

The list below are just things missing from the original that could be considered necessary.

• How long will the information be stored? (Retention is varied, but usually states that when data loses its use it must be deleted)
  
• Who will have access to the data (private person/company/public)?
  
• Where is the data stored (country)?
  
• Is the transfer of data encrypted and secure (SSL)?
  
• When and how often is data sent?
  
• It is not legal to collect information on an American citizen as an American or to an American located server if the citizen is below 13 years unless they have parental consent. (A tick box to confirm your age or that you have consent would be required) See COPPA
  
• Users should be able to log their own data being sent locally, so they can review it in a sensible format. (A check box for "logging")
  
• A version check, containing only a version number (and due to how the internet works an IP address) with no retention and is private (not visible to public) does not constitute as data storage or collection, but should be mentioned in text on the download page that the plugin does a version check.
  

On the note of the users being able to delete their own data from the collection servers, this would require quite a lot of work, considering IP addresses change, hardware IDs change when HDDs get replaced and so on, I would think Squad might have to supply an ID based on the game copy that is unique to every copy of the game, so that mod developers can use that to ID the data and users won't lose their ability to delete their possibly personal data if their IP happened to change or their computer stopped working.

I could probably write up a new text if wanted, and if anyone has suggestions to the above, well here is the best place to post such things.

Edited July 25, 2014 by IceBadger

[KasperVld]

The new add-on rules have been updated to clarify the data gathering aspects

[TriggerAu]

Thanks KasperVld, certainly answers my question.

I wont guarantee other questions wont arise

[DuoDex]

The new add-on rules have been updated to clarify the data gathering aspects

Multiplayer add-on rules are still not clear. Multiplayer works by gathering data and storing it, especially IP addresses for bans. If personally identifiable data must be deleted, what's to prevent IP bans from being completely ineffective.

[Galacticruler]

Multiplayer add-on rules are still not clear. Multiplayer works by gathering data and storing it, especially IP addresses for bans. If personally identifiable data must be deleted, what's to prevent IP bans from being completely ineffective.

Dynamic IP adresses already do make them ineffective.

[cpast]

Dynamic IP adresses already do make them ineffective.

Depends on rate of turnover of dynamic IPs. In my experience, dynamic IPs don't change terribly often.

[blizzy78]

Depends on rate of turnover of dynamic IPs. In my experience, dynamic IPs don't change terribly often.

Here in Germany, they usually change every 24h. I'd consider that quite often if you think about bans or statistics.

[Greys]

In USA.comcast, they change basically when you vacate the IP for long enough for it to be given to somebody else; so you may have the same IP for months if your network is stable

[DasValdez]

Your server logs the IP address of the request and it is personally identifiable information so that would, in fact, fall under a very strict interpretation of the rule.

For clarity's sake, IP address is generally only considered personally identifiable when it's combined with some other data point which would help identify a person. An IP address by itself is not generally considered personally identifiable... last I worked on this professionally (under US law).

To make the argument that IP becomes PI (heh) because it's linked to the data that a person "plays KSP" or "uses a specific KSP mod" would be a very very long stretch. Generally you're talking about an IP address being linked to account data (name, address, billing info) with an ISP, which could then make it personally identifiable.

If I'm not mistaken (and it's been a few years) a mod that issues a request with only a version number and an IP address is not dealing with PII.