Updates and Stats

[Chris Meller]

I was playing around with USVN (a web-based Subversion management GUI), and one of the installer steps [1] was whether or not to check for updates and submit server stats.

I know we've talked previously about asking during install whether or not we should check for updates (for paranoia reasons), but I'd like to bring up discussion about adding a second option for submitting stats. Often there are many things that projects have trouble judging the availability of on the average host (versions, extensions, etc.), and having some centralized collection mechanism would greatly improve our ability to judge the extent we could reliably anticipate such things. Ideally, I would also love to see us publish these statistics in some manner so that the larger community could benefit from our efforts.

A few examples of things this could help with:

- Our mbstring vs. iconv discussion largely centered around which extension was more widely available

- A question came up just the other day on IRC involving a problem with the value of $_SERVER['SCRIPT_NAME']. No one really knew if that was valid or not - it was set, but not to a value we'd have predicted. The reliability of other _SERVER variables is also suspect at times.

- Knowing which PHP versions are in use has a wealth of advantages (duh)

- Database driver and translation usage could help us target resources more accurately

Some basic information about your environment could be bottled up locally and submitted at the same time as update checks are performed (or at any other interval, via cron - it really wouldn't matter) and it could always be turned off in the options at any time if you'd opted-in during install. For bonus points, I suppose we could add the ability to turn on and off the individual data points we were collecting if, for example, the admin didn't want us collecting $_SERVER['REQUEST_URI'] from its users.

We would need a clear and firm privacy policy, but we were going to do that for updates anyway. Most of the data would be pretty harmless, certainly nothing I would worry about, and could potentially also be scrubbed before being sent (knowing simply that SCRIPT_NAME is set but not what it contains is somewhat less useful, but still helpful, for example).

This is one of those things that could really turn out to be as simple or as complex as we care to make it, I simply wanted to throw out an idea and get some basic feedback on it. Opinions?

[1] http://chrismeller.com/dump/1a0b5268efd464c19258455b2bea3cb8.png

[Chris J. Davis]

I am very much in favor of this being an opt-in option at the end of the installer. I don't think we need to have this be more than a one time occurrence. 

Chris

[Arthus Erea]

This seems to be very useful information.

I am very much in favor of including this as and opt-in option during the installer.

I disagree with Chris – one should be able to opt-out of this later on in the options page.

The polling frequency should be relatively infrequent (once a month?).

[Chris Meller]

On Thu, Sep 4, 2008 at 10:57 AM, Arthus Erea <arthu...@gmail.com> wrote:

This seems to be very useful information.

I am very much in favor of including this as and opt-in option during the installer.

I disagree with Chris – one should be able to opt-out of this later on in the options page.

The polling frequency should be relatively infrequent (once a month?).

One point to make here is that useful things like several of the request-related / script-related $_SERVER variables would change from user-to-user. Half the value here would also be the ability to isolate odd cases such as proxies in this data. That's where we really get into paranoia land - when we start sending info about visitors to a blog too. In any event, that's the kind of thing that would make this a regular event, rather than a one-time phpinfo() dump type thing.

If nothing else, I'd like to see the server stats option make it in - that's definitely the most useful. The malformed proxy data and such is more difficult not only to collect but to detect problems with, and that's really where I expect some debate.

[Arthus Erea]

On Sep 4, 2008, at 11:11 AM, Chris Meller wrote:

On Thu, Sep 4, 2008 at 10:57 AM, Arthus Erea <arthu...@gmail.com> wrote:

This seems to be very useful information.

I am very much in favor of including this as and opt-in option during the installer.

I disagree with Chris – one should be able to opt-out of this later on in the options page.

The polling frequency should be relatively infrequent (once a month?).

One point to make here is that useful things like several of the request-related / script-related $_SERVER variables would change from user-to-user. Half the value here would also be the ability to isolate odd cases such as proxies in this data. That's where we really get into paranoia land - when we start sending info about visitors to a blog too. In any event, that's the kind of thing that would make this a regular event, rather than a one-time phpinfo() dump type thing.

I don't think we should be collecting that kind of information... that is sensitive information which not only difficult to collect/detect as well as justify.

For the time being, lets focus on collecting server information. The reason I think we should periodically check is so we can see how systems are evolving over time – down the line, we would be able to see as PHP is updated and other things. Once a month seems like a reasonable polling frequency to me.

I think we should make every effort to keep things anonymous: ideally, there should be no identifiable information sent.

[Christian Mohn]

My views on this is well known. J