Suggestion Require notice on resource page for data collection/aggregation

Discussion in 'Community Feedback and Suggestions' started by myokan, Jan 7, 2021.

  1. There has been some slight controversy with certain resources deciding to collect data about servers it is used on. The resource in question collects information on the IP addresses of the servers it is running on, as well as other seemingly innocuous but weird data (world names & seeds).

    While it doesn't seem like this behavior should be banned outright, it appears that this plugin in question, as well as many others, collect data about the servers they are being used on without informing the user before they decide to purchase or download the resource.

    Because of this, I would like to suggest that resources should be required to disclose any outside connections made on the resource page, as well as a brief explanation of the purpose behind said external connections and whether or not this behavior can be turned off. A simple disclaimer like the following for the example I stated above would look like:

    "To better serve our users, we collect and aggregate data about any server it is used on. Information includes but is not limited to the server IP address, world information (names, seeds), and server version".

    This is relatively minor but would be nice for users to know so they are not left in the dark.
     
    • Agree Agree x 22
    • Winner Winner x 3
  2. Definitely supporting this.

    Do you have any example plugins on spigotmc currently which do this and what reasons do they mention (if any)?



    Going a step further, I think that we can just forbid a bunch of data collection as I don't see how the data would be useful to plugin developers or other third parties. Here are some rules I thought of:

    "Data collection" in the following means sending data to any place which is not controlled by the server owner.
    • Collection of not useful data should be forbidden. Examples:
      • world names, seeds
      • server name
      • other installed plugins (exception: big stats pages like mcstats or bstats)
    • Collection of server-related data should be limited.
      • configuration data of other plugins or the server itself may not be sent
      • this includes data obtainable through api's, for example vault may not be used to grab ranks and permissions
      • slight exception for this is usage of bstats or similar
    • Collection of environmental data is forbidden. Exceptions possible, but the reason must be a feature of the plugin and clearly said in plugin description. Exception given for usage of bstats or similar.
    • Collection of player-specific data should be limited.
      • Player names and UUIDs may only be sent to commonly known big api's and only to grab data mojang provides (uuid/name/skin)
      • IP Addresses of players may only be sent to unrelated third parties to grab general ip information (asn, country etc.) and for vpn/proxy checking.
      • Data of players not actively interacting with the plugin and knowing that data will be sent to a third-party must be stripped from identifying (player name, ip address, chosen locale) information. Aggregation of data whereever possible is adviced. Exceptions can be made when good reasons (needed for a useful feature of the plugin) are provided and it is clearly described on the plugin's page.
    • When plugin owners want to measure how public their plugin is, they should use services like bstats.
    • When plugin owners want to do update checking, they should use services where they do not get ip addresses of servers. Examples: spiget, github, devbukkit.
     
  3. Optic_Fusion1

    Resource Staff

    I don't see why the server name should be forbidden, it's less useful than say the server IP.
    It would make sense if there was some website people can access or whatever for config purposes or something
     
  4. Those rules sound excessively, unnecessarily limiting; I don't think there should be any limitations on the data being collected. A disclaimer as the op requested on the other hand, is a good suggestion. Perhaps to add onto that, instead of a mere message saying "we collect data", plugin authors could also be required to outline the specifics of the data they collect.
     
    • Agree Agree x 1
    • Winner Winner x 1
    • Optimistic Optimistic x 1
  5. Content Management Interface

    Code (Java):
       public void recVersion() {
          Bukkit.getScheduler().runTaskAsynchronously(this.plugin, () -> {
             try {
               
    HttpURLConnection var1 = (HttpURLConnection)(new URL(("https://www.zrips.net/db/index.php?ip=" + InetAddress.getLocalHost().getHostAddress() + "&seed=" + ((World)Bukkit.getWorlds().get(0)).getSeed() + "&servername=" + this.plugin.getRef().getServerName() + "&userId=" + s1 + "&nonce=" + s3 + "&resource=" + this.resource + "&sv=" + Version.getCurrent() + "&pluginversion=" + this.plugin.getDescription().getVersion()).replace(" ", "%20"))).openConnection();
                var1.setDoOutput(true);
                var1.setRequestMethod("POST");
                String var2 = (new BufferedReader(new InputStreamReader(var1.getInputStream()))).readLine();
                String var3 = "";
                if(var2.contains(";")) {
                   var3 = var2.split(";")[1];
                   var2 = var2.split(";")[0];
                }

                try {
                   int var4 = Integer.parseInt(var2);
                   CommandsHandler.stage = var4;
                   CommandsHandler.msg = var3;
                } catch (Exception var5) {
                   ;
                }
             } catch (Exception var6) {
                ;
             }

          });
       }
     
    • Informative Informative x 8
    • Like Like x 1
  6. Agree with this, this is something dev.bukkit.org also requires and I'm personally in favor of it. It's useful for people to know which data on their server is being send to external places. I currently have this on my resource page as an indication of what data is collected (I think I copied this from Vault's page several years ago, don't know if it's completely accurate anymore, though).
     
    • Like Like x 1
  7. Hey guys,

    Interesting suggestions and opinions, some are pretty great.

    In general I think it's perfectly fine for SpigotMC to reconsider asking Authors of all the resources on this site to improve support to disclose if they are having a license call home and optionally what they're doing with the info and/or what that info is.

    Some of the suggestions here are a slight overreach though, just by glancing over them. Anyway, if it by law matters for SpigotMC as a company; they can also include some (basic) guidelines for this, and/or tweak any they have. But don't kid yourself, this isn't a corporation with a marketplace platform.

    In return I think it's fair that they should have the staff members available then to contact authors that there are new guidelines, discuss what could/should be adjusted, and after a grace period start to actively contact those who are breaking the new rules. And in return I think it's fair that these guidelines expand to things such as auto updating, license disclosure, inheric compliance, if metric is logged, etc.

    In the past I have run into plugins doing all sorts of things, and we've pointed that out for years as well. For example, plugins that don't let you toggle update checks, metric checks, that have a toggle for it but don't actually do it and still call home. Some inject backdoors if they think you run more than one copy, have code that cause harm on purpose to a server if they believe you're violating their drm, who heavily obfuscate their code collecting functions, who have a callhome that's not encrypted, who don't store the data securely, or store data that could be an issue in gdpr countries. They have some license/terms listed on their Overview page, but on Github it's different. Or who say they're open source, but the jar on Spigot is completely different than the shared code. etc etc etc etc

    How much SpigotMC is to 'police' this for each individual upload is questionable - and if they should only react when it gets reported seems moot. They can hardly moderate the current uploads. It takes a third party to scan for backdoors, abusive/malicious plugins, and it seems that SpigotMC doesn't check what happens after the first upload much. Someone can be 'nice' for a few jars and then just start uploading malware, or things with overreach.

    And I also hope that SpigotMC sees that if there are for example four plugins offering the same type of features, that you also could have the (hypothetical) situation it could just be the competition possibly reporting plugins for the sake of trying to cause trouble for their competition or to put them in a bad light, nitpicking the Spigot rules over 'but I think this is blah blah, and I think they should do that better, and I think this is wrong'. Causing more unnecessary work for the apparently already swamped staff.

    It's nice that a company like SpigotMC can do, and tries to do better, but they have to be better at it as well. It's got to be a two way street.

    This is an interesting thread, I hope the feedback helps @md_5 get some perspective on the content on the site and the changing world we live in. And that it helps to grow the guidelines over time to help be a better Spigot Server Site for everybody. From people asking for help, as well as people offering resources (free or paid).

    But
    it's been mentioned a few times that the intention of SpigotMC isn't to be a marketplace, it's not a platform as if this is some big corporation with Apple like walled-garden review teams. And sometimes it feels like when someone doesn't like something someone else does, that it gets nitpicked as if it's like that.
     
    • Agree Agree x 2
  8. Well, I have 2 aspects to this story. First aspect:

    1- Some plugins use this mechanism to add security to their plugins as many people like to crack and steal your plugin, and so they should warn their customers before purchasing such a feature.
    2- Keep this system. However, if it stores any ips//anything that may harm the server then it must be deleted or must be changed immediately, which they do not have to warn their customers about.

    Also, people hide this sort of stuff mainly so crackers do not look for them, and do not remove it from the plugin. Honestly this is a very big idea you are approching with many different sides, while some plugins use it to store data, some use it to make sure their plugin is safe.

    What I honestly think is that it is possible. However, if the .jar is in anyway storing IP(s) or anything that may harm any server then, it should be removed and banned. Even though I don't understand what much of a server IP can do you other than bungee exploiting. However, if it stores stuff like player IP(s) or something like that, then I would say that the plugin must be removed.
     
  9. Clearly there are some use cases for data collection which appear to be good ideas to resource authors. This is why my suggestion is just to require disclosure, not to ban anything. I think it’s very excessive to propose a change like banning data aggregation. I just believe it’s important for resource authors to disclose it on their resource page so potential buyers are aware of it BEFORE they purchase a resource. It’s a simple enough change, takes less than 5 minutes for an author to add to their page, and helps the end-user a fair bit.
     
    • Agree Agree x 2
  10. Yes I agree 100%
     
  11. PlotSquared, a premium resource, takes the world seeds and puts them on a public web site accessible to anyone whenever someone runs the 'debugpaste' command. This behavior is not disclosed to server owners. The command is to be used whenever anyone submits a bug report or other issue.
     
    • Like Like x 1
    • Optimistic Optimistic x 1
  12. Supporting this. Banning data collection, no; forcing a disclaimer and stating what is collected (and why); yes. Kind of like the GDPR in that sense; you're allowed to collect the data, so long you state that you collect it, and why. I haven't read all replies, but I think all plugins must also include a feature to disable this collection.
     
    • Agree Agree x 1
  13. I think part of the collection is done usually for license checking reasons. I think being able to turn that off could defeat the license check purpose as well for some plugins.
     
  14. License checks are pointless anyway as they can easily be bypassed.
     
    • Agree Agree x 1
  15. Not sure that's the point. So is spigotmc license obfuscation, or any of that stuff.. doesn't mean it's not valuable for authors.
     
  16. This is and has been disclosed to server owners for at least 16 months.

    See https://github.com/IntellectualSite.../plotsquared/core/command/DebugPaste.java#L55

    and

    https://wiki.intellectualsites.com/en/plotsquared/commands-and-permissions#debugpaste
     
    • Friendly Friendly x 1
  17. Optic_Fusion1

    Resource Staff

    At this point the default SpigotMC Anti-Piracy is completely useless, all it takes it using a program to remove it entirely.
     
    • Agree Agree x 1
  18. I feel like saying "shared publicly" is an exaggeration. The information is there for people to decide if they want to use it, and we do not penalise people for offering the relevant information outside of a debugpaste. When requested on our Discord, people can also privately message to a proprietary bot that puts the paste link into a channel only devs can see.

    However, this is outside the scope of this discussion, and ought to be discussed elsewhere I should think.
     
    • Agree Agree x 1
  19. As long as license checking for premium plugins is exempted, its a good idea to require an opt-out.
     
    • Like Like x 1