Stats for Update Manager 1.0.0 Release Candidate 2

Here you can download the new version (but RC1 should prompt you for update).

New in this version:

  • Shortcodes to dispay active installations [sfum-installs] [sfum-installs id="my-plugin-folder/my-plugin-file.php"] and total active sites [sfum-domains] by @anon71687268 (thank you very much!)
  • WP-CLI integration with wp statistics
  • Now (was there in RC1 but waiting for Update Manager RC2 or >) when you display the plugin information tab you’ll see the “Active Installations” line.

Hope you like it!
Simone.

6 Likes

I am using this for Classic Commerce and it is a very useful addition to the Update Manager. Thanks for getting this working.

4 Likes

This is a great power-up for the Update Manager plugin…very handy! …and thanks for adding the shortcodes!

2 Likes

The only thing to note is that if you use this additional plugin you may need to comply with privacy declarations/opt-outs, as you will be collecting stats from users.

3 Likes

I’m not a GDPR expert, but the plugin collects just the domain name (which is in same way public) and stores it hashed (really not a big security but better than nothing). It’s not collecting “personal” data or visitors IP.
The data can be collected for just few days, so a minor concern.
This is less invasive than HTTP server logs…

4 Likes

We had a discussion about this re Classic Commerce.

We are going to add an “opt-out” checkbox in the settings.

4 Likes

Regarding the stored data…

The following image depicts the data stored by the Stats for Update Manager extension. This is from my local test server (as if the slugs didn’t make it obvious). The URLs are converted to a non-reversible (sha512) hash before storage and the counts/comparisons are based on these hashes, rather than actual URLs. There’s no record of the requesting URL kept, it’s just the hash, the plugin identifier, and the date.

As @Simone noted, it’s less data than a sever collects in its basic access log, but, as @ozfiddler noted, it can’t hurt to disclose that you are storing the non-identifiable data.

4 Likes

There was also a discussion on Slack where @timkaye confirmed:

I think this is clearly OK under the GDPR as Classic Commerce has a legitimate business interest in collecting the data, is protecting it appropriately, and has minimized the number of people who will have access to it.

So you should inform users that you are collecting the data, and why, but you don’t need their consent.

So the notification is necessary but we’ve done it in a non-intrusive way.

2 Likes

In Stats for Update Manager I’ve added in the readme the notice that it is up to the plugin developer, serving updates using Update Manager and using stats, to do what they want to deal with GDPR (or other privacy law):

This plugin stores data about plugin updates in a table.
You can configure how much time this data is kept using sfum_old_after filter (defaults to 4 weeks).
All the data is removed at plugin uninstall.

  • URL of the site asking for updates, sha512 hashed
  • plugin checked
  • timestamp of the last check

Is up to you to decide if and to inform your plugin users that this data is kept.

In the plugin (mine) using the UpdateClient my idea is to add this notice:

With the only purpose of keeping statistics about active installations of the plugin “Stats for Update Manager”, the server software.gieffeedizioni.it, serving updates for the plugin, store the hashed (pseudononimized) value of your hostname, along with the timestamp of the last check, for a maximum amount of time of 4 weeks.

What do you think about it?
Grammar checks are also welcome :sweat_smile:

1 Like

Users (of the Stats plugin) need to place the disclosure in their Privacy Policy, so, be sure your text goes into the privacy page, rather than using dashboard notices. I’d use something like:

To help us know the number of active installations of our plugin(s), we collect and store anonymized data when the plugin(s) check in for updates. The date and unique plugin identifier are stored as plain text and the requesting URL is stored as a non-reversible hashed value. This data is stored for up to N days.

1 Like

Very nice! Can I copy? :wink:

Here I’ve a different opinion. My idea was to putting this in the readme, that is something that an admin should read before installing a plugin.

Maybe I’m wrong, but I feel that the privacy page is something that deals with the site visitor, not to the site owner. Here plugin authors should help site admins to write and complete their privacy policy (we are using cookies, we use analitycs…), but here we don’t collect anything from the users.

The reason for the privacy text is: you (Stats author) are informing the site owner (Stats installer) that when they install your plugin (to track their plugins,) their site is collecting data (from their end users). In other words, installing your plugin means the site admin should update their Privacy Policy to disclose this.

Yes, of course. :slight_smile:

Thank you!

But I see it different:
you (xxx plugin author that embedded UM in xxx plugin and decided to run UM and collect stats with SFUM) are informing the site owner (xxx installer) that when they install your plugin their site is sending data to xxx author.

This line is for a generic plugin (and even UM using SFUM and SFUM using UM) that uses UM+SFUM, and in this scenario I think the readme is the right place.

I understand your point: only UM and SFUM have to show this in privacy page, because we are considering as end users plugins developers. But in this way aren’t they self-warning?

1 Like

Due to the confusing distinction between users and users of users, I err on the side of caution where legalities are concerned.

3 Likes

Final release will have a privacy policy suggestion… A few effort for a bit more of caution :wink:

5 Likes

Final release will have a filter to disable statistics by plugin, so, if you want to exclude a plugin from being logged, you can do that.

Next week I will release 1.0.0, so if you find something useful to be added or something wrong please open an issue!

3 Likes