[wp-hackers] Proposal: Add a Privacy Option: Anonymise Updates

[Travis Snoozy]

On Wed, 26 Sep 2007 23:46:24 -0700, Viper007Bond
<viper at viper007bond.com> wrote:

> On 9/26/07, Travis Snoozy <ai2097 at users.sourceforge.net> wrote:
> > On Wed, 26 Sep 2007 23:58:52 -0400, "Austin Matzko"
> > <if.website at gmail.com> wrote:
> > For the time being, this cuts out all potentially-sensitive data
> > (language, PHP version, charset preferences)
> 
> Huge -1 to that, mainly the PHP version. I'm fine with plugins
> disabling sending that, but if we don't send that with the core, then
> that's a lot of very important statistics lost (i.e. if we only
> support PHP5, what % of users would be affected?).
>
> And what's the harm in sending PHP version anyway? You're REALLY
> paranoid if you think that's a security risk and if for some reason it
> is, then you have bigger problems (i.e. upgrade your PHP version).
> 

I'm not concerned with the affect on statistics. I'm concerned with
providing full information control for the user. It is conceivable that
someone, somewhere, does NOT want to send their blog URL and PHP
version, or even IP and PHP version. I can't make that call for someone
else's environment.

There *is* another interesting statistic that falls out: the rough
proportion of people who leave updates on, but don't feel comfortable
sending PHP or other information (real security issue or not). How
people feel about that data being collected should be a big player in
whether you actually collect it. Forcing it down throats because "OMG
we need the statistics!" is not conducive to building a sense of trust.

Now, that said, I do intend to put excerpts into the config info that
outlines what the data *could* be used to good effect for. Most of it
is pretty straightforward:

PHP version -- the service *could* provide a warning if the next
WordPress release isn't compatible with your PHP version (though that
could be performed very simply as a local check, too). I don't think
that PHP version has much other relevance for the user.

Language -- the service *could* return an appropriately-localized
message (though the displayed message is actually in the WP code
itself; it might send a URL to an appropriately-localized page). I don't
know what other benefit this would have for the user.

Charset -- The service *could* return a message in an appropriate
charset for the user's site (pretty similar to Language).

Blog URL -- Let's WP gather more useful stats about individual blog
installations, hopefully allowing for better software development in
the future. No direct benefit within the context of the service, as of
yet.


All that said, if there's some -real- desperation to get blog URLs,
they'll be sent by most browsers in the referer if people actually
*use* the "update" link. That's probably a better success-tracking
metric than anything, anyway: we had X visits to the site, Y "unique
seeming" visits (cut dup IPs and dup referers), and Z% of the remaining
hits appear to be coming from the dashboard of a WP installation.


-- 
Travis