I'm not sure, if this is the best solution.

@nueckman suggested a better solution:

• Add a parameter to the global configuration (default: yes): Do you want to support Joomla! by sending anonymous datas?
• Make it possible to deactivate this parameter within the installation process
• Move the plugin to a new group "tracking"

The advantage is: then we have an opt-in + we can add additional tracking plugins in the future, if we need one

A very large % of installs are done through hosting control panels (either custom script or softaculaous) that do NOT use the joomla installer or are Quickstarts provided by template shops that do NOT use the joomla installer or are pre-installed images such as Bitnami which also do NOT use the joomla installer.

The advantage is: then we have an opt-in

We explicitely wanted it to be opt-out.

A parameter within installation is also not something we want. If you really want to install it with the plugin deactivated, just edit the SQL and set the state value to 0 for that plugin.

But honestly, the data being sent isn't anything which should concern you at all and it helps us a lot judging if we should drop, keep or even expand support for a given PHP or database version.

The data to my knowledge also isn't kept forever. If you turn off the plugin, your data will be removed by the next day or so.

The data is kept forever. Sorry to burst the bubble

Ah, misinterpreted that from https://github.com/joomla-extensions/jstats-server/blob/master/README.md then where it says most data is dumped every 12 hours. After reading again I got the meaning

It may however be something to look into, as I don't have any interest basing our decisions on data which has been collected a year ago.

We basically keep the last submitted data set. As the plugin runs every 12 hours that means we overwrite the data from 12 hours ago meaning it's technically lost. However if there has been no update in a year we still have that last data piece that was sent from the server

However if there has been no update in a year we still have that last data piece that was sent from the server

Yep, but does that make sense to keep the data that long? The data is useless at that time as the server may have been updated (and the plugin disabled) or the site no longer exists.
OT I know, but something to consider :)

@Bakual what are the arguments against an installation parameter for this? I don't see the issue with that?

Third party installation platforms (Bitnami, Softaculous, etc.) must also implement the installation parameter for it to be a viable option. If you make any code changes that assume the option is always set during installation then your are setting yourselves up for failure.

@Bakual Data is retained with a last updated timestamp (see joomla-extensions/jstats-server#15).

When discussing this, please keep in mind that we do not retrieve any data which is considered secret.

When you want to know that data from a given website, the PHP version (and even OS and webserver) is usually visible in the HTTP response header, the Joomla version can easily be found out as well by looking for specific files. Which leaves the database type/version which I'm not sure if it can be retrieved from outside.

So was thinking about this today, and I think I have a great compromise. During install/update generate some sort of time/date info of when the plugin was installed. In the plugin code we can allow a 24 hour delay before data is allowed to be collected based on that time/date. This gives Joomla the ability to enable the plugin by default, but give enough time for people to make an executive decision based on postinstall messages.

Already proposed with #8346 which would give a 6hrs delay to first sending data.

I'm going to close this PR in have of #8346 - because the majority of users aren't going to see the postinstall message until they go into the cPanel of J (which kinda makes this PR null and void).