Check how many people use my plugin

I found the two sides of this topic amusing . But I have to agree with the privacy concerns. If there was a plugin that tracked usage data, I would want my IP to not be listed. My public server isn't the problem as much as my private-in home one. I wouldn't want some malicious plugin developer (And I'm not calling you malicious, but some can be and just copy/paste your code for their own use) DDoS'ing my home connection.

And MD5 Alone isn't the best solution. While it may be one way, there are two problems with MD5. One, (and this is a problem with a lot of hashing algorithms) is that someone could use a list of pre-computed rainbow tables to reverse the hash, and get the IP's. The other is that it has been proven that it is possible to have two different sets of data that cause the same hash (http://en.wikipedia.org/wiki/MD5#Security).

Because of the nature of PHP, you can't see the backend code, so we wouldn't know if you are collecting IP's, or if you hash them or not.

Maybe you should generate some sort of unique code for the server within the plugin and send that to the server, but then again, there is the problem of Apache, lighttp, NGINX, and Cherokee webservers being able to log all of the IP's for the GETS and POSTS for files.

OR, you could have the plugin directly contact your Database server and just post when it is online, and remove the entry when it goes offline. To solve the problem with if servers get killed without the onDisable(), have the plugin check-in every so often with the same unique code to show it is still "live". When a the plugin doesn't "check -in" to the server, you could have a server-side script remove the entry from the database.

Just my 2 cents. I'm not a Java developer by any stretch, but I still would like to give input as a sysadmin.

 

@Tylerjd The MD5 hash can be done within the sourcecode of the plugin, so everyone can easily see that the IP is getting hashed.

As for your problem of tracking IPs directly with server-side code, you could make the plugin go through a proxy or even better, get it to hook into the TOR network. (If you have never heard of TOR, its The Onion Router and it basically sends your data through multiple "proxies" before spitting it out at your final destination). TOR is pretty popular nowadays and I can almost guarentee that sample, working Java code for using it is readily available. Honestly, if I knew you were collecting my IP, but sending it through the TOR network, I really wouldn't care.

 

Salt it and/or use sha1.

 

I don't know how to salt it in Java...but it must be possible. An alternative to that is to hash your hash multiple times, say 10 times. If your looking for performance, I think you should use SHA1 instead. I believe the number is roughly 100k hashes will take an average server roughly a second!

On a side and very needed note, does the OP really think it is still worth all of this time and trouble just to find out how many people actively use his plugin compared to the amount of downloads the plugin will receive?

 

Using my Extras library you can do a MD5, SHA-1, SHA2-256bit, SHA2-386bit and SHA2-512bit hash

 

Hmm...

 

@NuclearW What was the point of that reply?

 

To post boost perhaps

 

To me, having it make a connection to your server STRICTLY for stat-tracking is stupid. If you were to add an update checker, that's one thing, but to just say "Hi, I'm running your plugin" is a waste of a connection.

 

It was a reply simply stating my interest in the conversation at hand, a reply that also permitted me to follow the thread, and a reply that would bump the thread back up such that others could reply had they not seen it before.

 

@NuclearW I respect that

As for the rest of the thread, @Drakia brought up a really good point. You should at least make the plugin check for updates when it "phones home". However, without even thinking about it, he also brought up the fact that all self-updating plugins actually can track how many people use their plugin. The real question is, how many of them actually do?

 

As @Drakia said...I really don't think this is worth it just to see how many servers run the plugin. I know that its always nice to see how many people actually use the plugin, but just try to guage it from the amount of people posting in your thread (or at the very least, the amount of views).

Having the plugin start taking down info from servers just for your own curiosity...? That's just silly, IMO.
And as others have stated, most server-owners (myself included) wouldn't want some random back-end PHP connection, as I have no idea what the person intends to do with it. Not that I'm implying that you have any bad intentions, its just my personal view on the subject.

 

Personally I use my unique download counts to track approximate usage, and if you don't host your own download on your own server, then you don't really deserve to have stats.

iChat: 58517
Warpz0r: 24003
InvTools: 2745
Stargate: 22457
Tombstone: 8297
Stargate-DHD: 2601
KickSpace: 4
iChat-p3: 6348

Total Unique Hits To .Jar Files: 101097

 

I think most of the people worried in this thread are grossly overreacting.

In case you aren't aware, BukkitContrib uses some extensive data mining (I make the results public on the thread page, so can see them)

I use bit.ly links internally and ping the bit.ly servers, which counts as a (click), and that gives me country and usage statistics.

If privacy on the internet (for publically available data, no less), bothers you, you could always opt out.

 

Thank you, I needed a good laugh.

 

Haha

 

After reading through arguments on Youtube/Bukkit, I needed a laugh.
Now if only internet trolls could opt out...

 

whatever hash method you will use, the ipv4 range is way to small to generate a unreverseable hash-code
the randomly generated unique id is better for this

 

I had made a separate plugin for this, to let server administrators opt-in to usage data collection for any plugin that used mine.

Never released it though, could if people want it?

 

Instead of a hash, you could always generate a GUID/UUID the first startup to use every time.