Anonymize update checking

I know it's stupidly close to the line, but I think it would be a good move to delay 2.3 and get this into 2.3. Putting it in 2.4 or even 2.3.1 will be too late for the tinfoil hat brigade.

Note that I couldn't give a shit. I'm thinking of the PR here.

Actually scrap that last comment.

A good move would be to delay 2.3 by a day or two in order to prepare a bullet-proof press release explaining in detail what the update notification system is, how it works, and what information will be sent by it (for both the core updates and plugin updates). The aim of it being to reassure people that this is a good thing™. Because it is.

Attached a quick patch. Basically if the option 'update_plugins' is not set then no checks will be done. The nag screen at the top asks the user to select if they want to opt in or out, with a link to the privacy screen. Once they select either yes or no, the nag screen goes away.

I would like to have some other eyes check over the wording real quick.

OOPS - I attached the wrong patch (guess I should clean the desktop). -2 is better.

Changing to 2.3 in hopes of getting this in.

-1

Checking for core updates (and possibly plugins) shouldn't be able to be disabled without a plugin. It's just too important.

+1 for an option to adjust sending statistics data (blog URL, etc.).

There needs to be notification/disclosure of the information being sent, though, which was the initial thrust of my ticket.

I support adding 3 options: * Option name "Updates" * Option choice 1: "WordPress should check for updates automatically and send my blog url." * Option choice 2: "WordPress should check for updates automatically but *not* send my blog url." * Option choice 3: "WordPress should not check for updates." * Then the text: "For more on how this information is used, see the Privacy Policy" - link to the policy online.

If there's good support on wp-hackers I'll write a patch.

Replying to chmac:

May I suggest that you create two radio buttons?

• "WordPress should check for updates automatically"
• "WordPress should not check for updates"

And

• "WordPress should advertise itself via User-Agent"
• "WordPress should not advertise itself"

This is because there are lots of User-Agent strings with data that some blog owners don't want transmitted. See bug #5065

Even better would be if there was an option to take "WordPress/$wp_version" out of everything.

If you do the options part, I'd be willing to go around and locate all the places that WordPress leaks it's name and version number and change them depending on the option.

Ciao!

+1 for just one single checkbox:

[X] Check for updates of WordPress and Plugins <a href="#">Privacy Policy</a>

All other things should be adjusted via plugins.

I have added a patch to bug #5065 and added a new bug #5085 for the various generator strings.

The patch in bug #5065 would allow exactly as arnee suggests: turning off the user-agent via a plugin.

Bug #5085 is a little more complicated to make it plugin-patchable.

Ciao!

I'm on the fence about an option to disable update checking, but I don't think it's really necessary. Those who want to disable it can install a relevant plugin - that's what the plugin system is there for, to enable control of options and functionality that a smaller subset of people who use WordPress might want.

To quote Westi:

One of the core design ideas for WordPress is that we don't introduce options lightly. The moment you think of making a feature optional you challenge the argument for introducing the feature in the beginning.

This is exactly why WordPress has a very extensive plugin API. Write a plugin so people can change their user-agent and be done with it.

There needs to be a way to allow those who are concerned about this issue to ensure that nothing gets sent the first time they load up the WP admin and plugin admin pages. If you have to go to the plugin page (at which point, if my understanding is correct, it will fire off an update attempt) in order to activate the plugin, you've already sent the information at least once. This, to be quite frank, is unacceptable and will preclude users concerned about this issue from using WordPress.

There needs to be an opt-in solution from the beginning, IMNSHO.

Replying to johnbillion:

I'm on the fence about an option to disable update checking, but I don't think it's really necessary. Those who want to disable it can install a relevant plugin - that's what the plugin system is there for, to enable control of options and functionality that a smaller subset of people who use WordPress might want.

You are right, but I don't think that every future release will state in the announcement that WP will look for updates and "phone home". An option to enable or disable the functionality with a link to an explanation or the privacy policy would avoid the "Whaaat? WP phones home? Why didn't I know???" effect because I think that most of the users click through the options pages first. Or include this checkbox in the installation where the other privacy options are set too.

Of course every user may disable the update-check via plugin, but why should users install or look for a plugin if they don't know that this update-feature actually exists?

One checkbox, "enable update-check", at the privacy options and the installation page won't hurt, or?

I noticed that there is negative response to that feature mainly for one reasons: You have missed communicating it. If you transmit data, make the users aware of it, tell them what the data is used for and give them a choice. I am perfectly ok with sending a list of all my plugins to wp.org, but I do not want to expose which of them are active. And, as a side note, is it really neccessary to transmit the description of every plugin? Just thinking about performance here.

Solving this via a plugin is a good idea, but not that easy as a) you have to go to plugins page to activate it, thus the update-check will be done once and b) plugins have little access to what's going on in wp_update_plugins().

Furthermore I like the idea of having a function wp_user_agent() that provides Wordpress/$wp_version but can be overridden by a plugin. And for the really paranoid I could imagine an option to remove/obfuscate the blog url in http requests.

My plugin (http://wordpress.org/extend/plugins/anonymous-wordpress-plugin-updates/) replaces wp_update_plugins with a version that does not transmit plugin-desc etc. and the list of active plugins. It also replaces WP version and blog url. I also offer making a patch out of if, but I'd rather wait and see how the discussion goes on.

Just found #5065 which addresses the user agent part.

How about instead of enabling/disabling the auto-update-notification feature, we enable/disable the sending of the information that bugs people?

E.g.:

When receiving and sending services 
(RSS, API, ATOM, etc.) WordPress should:
 [x] Identify as WordPress/2.3 and the blog
     URL when appropriate
 [ ] Be anonymous

Selecting "Be anonymous" would replace the user-agent string with something generic (bug #5065) and remove the generator strings (bug #5085).

Ciao!

I'm getting bored of this now, but let me just say this:

Selecting "Be anonymous" would replace the user-agent string with something generic (bug #5065) and remove the generator strings (bug #5085).

Having this option will mislead users into thinking that by using it, their requests to the update server will be anonymous, when in fact they are not and cannot be.

Replying to johnbillion:

I'm getting bored of this now, but let me just say this:

Selecting "Be anonymous" would replace the user-agent string with something generic (bug #5065) and remove the generator strings (bug #5085).

Having this option will mislead users into thinking that by using it, their requests to the update server will be anonymous, when in fact they are not and cannot be.

Well, the verbage is easily changed. But I meant the concept more than the verbage.

Instead of "Be anonymous" how about "Don't identify" or something like that. Less stigma associated and makes the choice that the developers dislike a negative choice (and therefore influences the user to not choose it).

We promoted a plugin about this in the release announcement for 2.3, but it has had very little adoption:

http://wordpress.org/extend/plugins/disable-wordpress-plugin-updates/stats/

Rather than bumping the milestone, let's just close it until there are compelling new arguments.