WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 11 days ago

#16778 reopened enhancement

wordpress is leaking user/blog information during wp_version_check()

Reported by: investici Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version:
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

Hi,
we've noticed that wordpress will send how many users and blogs are in a given installation during the GET to api.wordpress.org together with the installation URL in the headers.

Is there any reason why this is done? It seems quite a leak of information. Can it be turned into an option defaulting to off and admins can opt-in if they want to report how many users/blogs are currently there?

thanks.

PS. slightly related, WP will also leak which blog in MU mode is requesting any URL via the user-agent in the WP_Http class (for example while updating the news feed on the dashboard)

Attachments (3)

wp-includes--update.php.diff (1.3 KB) - added by toscho 3 years ago.
Fixed patch introducing a filter.
wp-includes--update.php.2.diff (1.3 KB) - added by toscho 3 years ago.
Renamed filter to 'wp_version_check_query_variables'
wp-includes--update.php.3.diff (407 bytes) - added by MattyRob 11 days ago.

Download all attachments as: .zip

Change History (29)

comment:1 nerx3 years ago

  • Component changed from General to Administration
  • Keywords needs-patch added
  • Severity changed from normal to minor

comment:2 follow-up: vimishor3 years ago

I suppose that some statistics are generated using this information. And besides, this information can be used to plan future updates.

comment:3 in reply to: ↑ 2 ; follow-up: nacin3 years ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Replying to vimishor:

I suppose that some statistics are generated using this information. And besides, this information can be used to plan future updates.

Correct.

comment:4 investici3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Thanks for the quick reply, a question still stands though: can it be turned into an option to be opted in by administrators? While it is clear that wordpress is checking for updates it isn't clear that it is also leaking how many blogs and users are on the current installation.

comment:5 hakre3 years ago

Thanks for reporting the issue.

So far I can only say that I did not see an opt-in nor any information which information is to be transferred and for which use.

The information you reported is obviously not necessary for the update procedure.

comment:6 in reply to: ↑ 3 hakre3 years ago

Replying to nacin:

Replying to vimishor:

I suppose that some statistics are generated using this information. And besides, this information can be used to plan future updates.

Correct.

Can you please reference the changeset when this came in?

comment:7 toscho3 years ago

  • Cc info@… added

See #12672 for more information. We need a filter for the data.

toscho3 years ago

Fixed patch introducing a filter.

comment:8 follow-up: hakre3 years ago

Thanks for providing a patch, I could review it, probably it's better fitting to name the filter wp_version_check_query_variables instead of update_core_data_send as this does not modify the core data send with request headers.

toscho3 years ago

Renamed filter to 'wp_version_check_query_variables'

comment:9 in reply to: ↑ 8 toscho3 years ago

Replying to hakre:

Yes, that’s a better name. Added another update.

comment:10 wpmuguru3 years ago

For the record, this code was added to WordPress as part of the merging of WordPress MU (#11644). WordPress MU included the number of blogs and users when calling the api at wordpres.org.

http://trac.mu.wordpress.org/browser/tags/2.9.2/wp-includes/update.php#L47

Last edited 3 years ago by wpmuguru (previous) (diff)

comment:11 follow-up: wpmuguru3 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

I'm closing this again. The call to api.wordpress.org was discussed extensively prior to the [14010] being committed to trunk including being an agenda item at at least one of the weekly dev meetups in IRC.

comment:12 in reply to: ↑ 11 toscho3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to wpmuguru:

I'm closing this again. The call to api.wordpress.org was discussed extensively prior to the [14010] being committed to trunk including being an agenda item at at least one of the weekly dev meetups in IRC.

The fix is backwards compatible and the privacy concerns were not resolved in [14010].

comment:13 follow-up: westi3 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

This has been discussed many times in the past.

There are plugins available already which allow you to disable the checks if you don't want to send the data.

We are not going to add any UI option for this and I don't see that we need a new filter either as plugins have already sucessfully been created using the filters/actions we already have.

comment:14 in reply to: ↑ 13 hakre3 years ago

  • Keywords legal added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Replying to westi:

This has been discussed many times in the past.

There are plugins available already which allow you to disable the checks if you don't want to send the data.

We are not going to add any UI option for this and I don't see that we need a new filter either as plugins have already sucessfully been created using the filters/actions we already have.

Please be so kind and leave the ticket open until it's solved. I'm sure that for you personally this is all okay but this should be about the common user.

Tscho is right in the point that the privacy concerns were not resolved. That those have been discussed in the past did obviously not help much so far to increase the awareness within the wordpress core team.

I think the problem is that most users are not aware which of their data is spread to which third parties and for what reason.

And wouldn't it be such an important topic, I'm sure this wouldn't come up again.

Even if a user knows that some data needs to be passed for a version check of core, plugins or themes, the amount of data passed to remote is obiously more than needed to do the version check. It has been already written in this ticket that the additional data get's passed for stats.

But users should be made aware upfront so they can freely decide on their own if they want to instead of being forced to support the project with their usage-data. They could be offered an opt-in to do so.

But instead, you're promoting that users that have no clue what a plugin is should search through many of them and probe some until they luckily find one that prevents leaking their data. It's more likely that they can not even verify if a plugin is doing what it announced. So the only safe bet is to have that as part of the application itself.

Wordpress does not offer such and the privacy settings page in the backend is not informative at all about this issue. The installation screens do not contain a single word about this either.

Maybe I've just overlooked it, but where is the information available which data gets transfered to whom, for what reason and how this can be prevented? Please keep in mind that this is about the average user and not plugin coders that have no problem to remove such a check within a minute.

Let's be more constructive here. Probably it can be created a statement so users can learn more about the privacy issues when downloading from worpdress.org.

Additionally I'm intereseted to learn about the reasons to not offer an option for submitting stats.

Last edited 3 years ago by hakre (previous) (diff)

comment:15 hakre3 years ago

Related: #16778

comment:16 ryan_b3 years ago

  • Cc rbilesky@… added
  • Type changed from defect (bug) to enhancement

I agree that

1) WordPress should be more open about what data they collect and why.

2) WordPress should offer a checkbox perhaps on Settings->Privacy that allows the user the option to opt-out of sending unnecessary infromation, the default setting can still be to send statistical information.

Privacy now adays is a concern for many users, transparancy and options are important. A plugin to do this is not enough as many users do not know that this data is even sent.

comment:17 ocean903 years ago

  • Milestone set to Awaiting Review

comment:18 toscho3 years ago

Is there anything else I can do to help resolving this issue?

comment:19 F J Kaiser3 years ago

  • Cc 24-7@… added

@investici, @toscho, @hakre: +1 Having plugins which can solve a task means nothing if you're not aware of the fact that you're sending data. If this doesn't get into core as an option, imo wp should note that on update.

comment:20 follow-up: investici3 years ago

@toscho: thanks for your patch, it is a step in the right direction. Any plans for review/inclusion in core?

whether this bug is fixed by that patch is debatable though, we'd much prefer having the users opt-in before leaking so much information or at least make the users/admins aware of the fact (and the reason why?) that information not related to check for updates is sent while checking for updates.

what is the best way to get consensus (and a fix) for this from the wp developers?

comment:21 in reply to: ↑ 20 toscho3 years ago

Replying to investici:

whether this bug is fixed by that patch is debatable though, we'd much prefer having the users opt-in before leaking so much information or at least make the users/admins aware of the fact (and the reason why?) that information not related to check for updates is sent while checking for updates.

I agree, opt-in via wp-admin/options-privacy.php would be much better. But seeing how strongly some people are against more privacy I thought my patch could be a first compromise. Not good enough – but better than nothing.

I would write a patch for a user controlled opt-in per backend if we find a consensus.

comment:22 ocean903 years ago

  • Keywords has-patch added; legal removed

Toscho, instead of your foreach loop you could use add_query_arg( $update_data, $url ). Should be easier.

comment:23 mau3 years ago

  • Cc ngomau@… added

comment:24 viniciusmassuchetto20 months ago

  • Cc viniciusmassuchetto@… added

comment:25 pixline10 months ago

  • Cc pixline@… added

comment:26 MattyRob11 days ago

Updating this patch against the 3.9RC code as it's a little out of date now.

Note: See TracTickets for help on using tickets.