WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 6 minutes ago

#16778 reopened enhancement

wordpress is leaking user/blog information during wp_version_check()

Reported by: investici Owned by:
Milestone: 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 (4)

wp-includes--update.php.diff (1.3 KB) - added by toscho 6 years ago.
Fixed patch introducing a filter.
wp-includes--update.php.2.diff (1.3 KB) - added by toscho 6 years ago.
Renamed filter to 'wp_version_check_query_variables'
wp-includes--update.php.3.diff (407 bytes) - added by MattyRob 3 years ago.
16778.diff (619 bytes) - added by swissspidy 14 months ago.

Download all attachments as: .zip

Change History (68)

#1 @nerx
6 years ago

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

#2 follow-up: @vimishor
6 years ago

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

#3 in reply to: ↑ 2 ; follow-up: @nacin
6 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.

#4 @investici
6 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.

#5 @hakre
6 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.

#6 in reply to: ↑ 3 @hakre
6 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?

#7 @toscho
6 years ago

  • Cc info@… added

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

@toscho
6 years ago

Fixed patch introducing a filter.

#8 follow-up: @hakre
6 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.

@toscho
6 years ago

Renamed filter to 'wp_version_check_query_variables'

#9 in reply to: ↑ 8 @toscho
6 years ago

Replying to hakre:

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

#10 @wpmuguru
6 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 using when calling the api at wordpres.org.

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

Version 0, edited 6 years ago by wpmuguru (next)

#11 follow-up: @wpmuguru
6 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.

#12 in reply to: ↑ 11 @toscho
6 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].

#13 follow-up: @westi
6 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.

#14 in reply to: ↑ 13 @hakre
6 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 6 years ago by hakre (previous) (diff)

#15 @hakre
6 years ago

Related: #16778

#16 @ryan_b
6 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.

#17 @ocean90
6 years ago

  • Milestone set to Awaiting Review

#18 @toscho
5 years ago

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

#19 @F J Kaiser
5 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.

#20 follow-up: @investici
5 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?

#21 in reply to: ↑ 20 @toscho
5 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.

#22 @ocean90
5 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.

#23 @mau
5 years ago

  • Cc ngomau@… added

#24 @viniciusmassuchetto
4 years ago

  • Cc viniciusmassuchetto@… added

#25 @pixline
3 years ago

  • Cc pixline@… added

#26 @MattyRob
3 years ago

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

#27 @chriscct7
14 months ago

  • Keywords close added

@swissspidy
14 months ago

#28 @swissspidy
14 months ago

I know this ticket hasn't got any traction for quite some time, but I think a filter here could still be useful and make it easier for people to change query args. 16778.diff adds a core_version_check_query_args filter.

#29 @MattyRob
14 months ago

I have to manually apply this patch myself after every WordPress update - so frustrating that a seemingly simple patch like this takes so long so get committed.

#30 @swissspidy
12 months ago

  • Keywords close removed

#31 @swissspidy
2 months ago

  • Keywords close added

#32 @investici
3 weeks ago

Hi @swissspidy !
Did your filter eventually make it into wordpress given the close keyword?

Thanks!

#33 @swissspidy
3 weeks ago

@investici: "close" means the ticket is a candidate for closure with a disposition other than fixed. So no, there's no such filter in WordPress right now. I re-added the keyword because of a lack of traction and no high demand for such a filter.

#34 @MattyRob
3 weeks ago

@swissspidy

I agree with half of your statement - 'low traction'. This ticket has basically be ignored for 6 years. What basis are you presuming there is no high demand? I manually patch WordPress myself after every new release to put this into the code. I accept I'm only one person among millions using WordPress but then the average users is blissfully ignorant of privacy otherwise we wouldn't have so many DrDOS web attacks.

WordPress does not publish (to my knowledge) any statement of what data are collected about my site(s) nor what that data is used for or how long it is kept. The current code doesn't allow me to opt out of sharing any information either.

IMO, such privacy concerns needs to be acknowledged and addressed.

#35 follow-ups: @chriscct7
3 weeks ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

WordPress is an open source project. Unlike closed source projects, you can freely read and edit the codebase and see exactly what is sent, or learn about how different parts of the project operates.

Additionally, the WordPress project maintains an open information section, similar to Wikipedia, where anyone can contribute new documentation or information about the platform, that to a reasonable extent would be useful to other users. As such, you're free to create a page for this, and the instructions for doing so are here: https://codex.wordpress.org/Codex:Creating_a_New_Page. It would likely be categorized here: https://codex.wordpress.org/About_WordPress. As a volunteer-based project, there's no group that's "responsible" so to speak for creating content really of any sort for WordPress.org. The best way to ensure that things get done, is often to do them or spearhead them. This could be something to consider, as it doesn't appear that any of the other volunteers who work on the project have had the interest in doing so for this topic. As a place to start, the data is stored by WordPress.org for calculation purposes for 48 hours, and then discarded.

There is a balance between having too much and too little information about usage, and what that entails. There's groups on both sides of this. This ticket is mostly comprised of users who would like (from my understanding of reading the comments) less information to be sent back. There are other tickets, who want WordPress to collect more information than it currently does (generally with the argument that WordPress needs to know more about it's users to make better software OR alternatively that the WordPress core developers aren't collecting enough information to base decisions on). This is a balancing act between privacy and practicality.

As for this ticket, WordPress is now used by almost a quarter of the internet, and since 6 years ago a total of what appears to be just 6 (quick count on my part; could be off +/-2) have expressed interest in a filter for this. Aside from the performance implications of calling apply_filter() which albeit while small is still a consideration factor, there is also WordPress's core philosophies of "Design for the majority" and "The Vocal Minority": https://wordpress.org/about/philosophy/. It is unlikely that of the many tens of millions of active WordPress installs more than a handful would actually use this filter. Furthermore, introducing new filters have to be done with care, particularly out of consideration for future development. Does a filter here prevent WordPress from being able to achieve future goals due to backwards compatibility concerns? Probably not, but again another thing to consider.

Finally, there is already an applicable WordPress filter that can be used to achieve the same result: http_request_args, where the existence of the wp_install header (which is exclusively used on wp_version_check() calls in WordPress) could be used to filter the information from the body.

Given there's a way of filtering this data already, and there's a lack of significant interest, closing this ticket. As a reminder, ticket conversations can continue while the ticket is in a closed status.

#36 @MattyRob
3 weeks ago

@chriscct7

Thanks for your detailed response.

I'm not sure I'd be the best person to start writing a new 'privacy' page as 1, I don't have all of the information about what happens to the data on server end (which is perhaps why I'm so concerned about my privacy) and 2, it would probably be worded in an incredibly negative and potentially damaging way!

The other concern here is that you suggest that the http_request_args filter can be used for the same purpose, I disagree (but am happy to be corrected. That filter takes 2 parameters, $r and $url, but only the former can be amended during that filter call, so where and how can I amended the private information added to the $url requested? That's what this patch addresses.

#37 @dd32
3 weeks ago

I'll just note that this page exists: https://wordpress.org/about/privacy/ (as it hasn't been mentioned on this thread)

The other concern here is that you suggest that the http_request_args filter can be used for the same purpose, I disagree (but am happy to be corrected)

You're right, that filter doesn't really work for the purpose you want, instead you should use the pre_http_request filter and perform a modified request, similar to what the WordPress Beta Tester plugin does:
https://plugins.trac.wordpress.org/browser/wordpress-beta-tester/trunk/wp-beta-tester.php?rev=1367272&marks=35,69-86#L33

#38 @MattyRob
3 weeks ago

@dd32

I'm aware of that page but it seems to be aimed at human visitors to the wordpress.org site. Is that where you'd suggest putting details of all of the data collected through API requests also?

I'll take a look at the pre_http_request hook - thanks.

#39 @MattyRob
3 weeks ago

I can't get `pre_http_request' to work, it kills the updates, Plugins and Themes pages of my site as the server runs out of memory.

Others have asked to filter the HTTP API url also and referenced this ticket:
http://wordpress.stackexchange.com/questions/72529/filter-any-http-request-uri

This ticket was mentioned in Slack in #docs by mattyrob. View the logs.


2 weeks ago

#41 @MattyRob
2 weeks ago

@chriscct7

I've drafted a privacy page and then checked in on the Slack #docs channel. They advised that the Codex is being shut down soon, so where should this go now? They suggested attaching to this ticket but is needs to be findable by WordPress users.

#42 @TJNowell
5 days ago

This strikes me as something that would be trivially fixed by adding a sentence to wp-admin/about.php

I understand that adding checkboxes and steps is something people don't want to add, and I agree, the only suitable place for such a UI is during install and on update.

Stating what information gets sent to .org and why should only take a short paragraph of text at the bottom of the about page. If we can add an entire page talking about Freedoms I think we can write a short privacy statement.

Here's a suggestion:

Note: WordPress may send statistics to WordPress.org when requesting updates. This is to help plan and improve future updates.

With perhaps a "For more information, click here" that leads to a .org page

#43 @MattyRob
2 days ago

@TJNowell

I like your idea but fear that it won't gain any traction and also perhaps isn't as straightforward as it first seems.

If you take the principles of individual data privacy, all collected data needs to have a stated purpose. If the assertion is that the data are collected as you say to 'plan and improve future updates' why is there a need to know how many users and blogs are running? I cannot think of any justification for collecting this data.

#44 in reply to: ↑ 35 ; follow-ups: @DvanKooten
6 hours ago

It saddens me to read through this ticket and notice the general unwillingness to improve.

Let me start out by saying that the number of registered users I have on my site tied to the URL that is sent with tracking request gives out vital information on how well my business could be doing. Information that is mine and mine only.

If this is really used to "help plan and improve future updates" then there are much more privacy friendly ways to go about this. At the very least we could make it very clear that WordPress is tracking this information and what exactly it is doing with it, I really do not think there is any excuse for that.

We would not opt-in to usage tracking in a plugin without knowing what exactly it tracks. WordPress doesn't have to play by this rule as the download is the opt-in, but let's at least make it super clear what we're opting into then.

This becomes even more important as the collected data is not visible to us, lone contributors outside of a8c. All we have is your word.

Replying to chriscct7:

As for this ticket, WordPress is now used by almost a quarter of the internet, and since 6 years ago a total of what appears to be just 6 (quick count on my part; could be off +/-2) have expressed interest in a filter for this. Aside from the performance implications of calling apply_filter() which albeit while small is still a consideration factor, there is also WordPress's core philosophies of "Design for the majority" and "The Vocal Minority": https://wordpress.org/about/philosophy/. It is unlikely that of the many tens of millions of active WordPress installs more than a handful would actually use this filter. Furthermore, introducing new filters have to be done with care, particularly out of consideration for future development. Does a filter here prevent WordPress from being able to achieve future goals due to backwards compatibility concerns? Probably not, but again another thing to consider.

This is a very oversimplified way of looking at things. Just because only 6 people replied to this Trac ticket does not mean that no one else has an issue with this. WordPress sending the number of users your site has is undocumented behaviour which you would only know of by going through the WordPress source code, and we both know that the majority of WordPress users never does this. Furthermore, you are comparing "a quarter of the internet" vs "the # of Trac users". Certainly a quarter of the internet is not using Trac.

Wrapping up: the very least we could do to improve is to document this behavior and to create a page on what data exactly WordPress is collecting, and why.

People should know without having to go through each line of code in WordPress one by one, so they can make an informed decision on whether they want this or not. Alternatively, WordPress should quit saying stuff like "own your data", because apparently you don't.

#45 @mbootsman
6 hours ago

Totally agree with @DvanKooten. Awareness is key here.
The majority of users doesn't know this, and they should. Best solution IMHO is an opt-in setting in the General settings to share this data with wordpress.org.

#46 in reply to: ↑ 44 @LucP
6 hours ago

Hear hear! DvanKooten

#47 in reply to: ↑ 44 @anu.gupta
5 hours ago

Completely agree, also agree that this should be opt-in, not opt-out. If a user *wants* to share this information, they should be able to do so, but by default sites should not be phoning home and sharing this information.

#48 @gellenburg
5 hours ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I just found out about this ticket a little while ago and I have a SIGNIFICANT problem with the amount of personal and detailed information about my blog and my users being relayed back to Automattic. I manage 50 some-odd Wordpress sites, all on private hosting, and this is unacceptable.

I'm hoping this can be fixed with a Plugin to strip out this data if WP core refuses to take this out (or at the very least make this optional).

Drupal is suddenly looking like a much better alternative.

#49 @idea15
5 hours ago

Not my place to step on any legal team toes but what steps are being taken towards GDPR compliance? WP will need to publicly clarify all data collection as well as the legal basis behind it in any case.

Rather than thinking in terms of general, wooly concepts of data collection, you need to be working towards compliance with that specific framework.

That needs to include 1) full disclosure 2) notice of consent and opt-out and 3) subject access rights.

Last edited 5 hours ago by idea15 (previous) (diff)

#50 @nofearinc
5 hours ago

Automatic WordPress updates are still something that many organizations avoid at all cost (or even pick another CMS/WCM) due to the lack of control and inherent dependency on 3rd party (be it WordPress.org in that case).

Being transparent about what internal data is being sent externally is mandatory. Handling an undefined set of data probably gets in the gray legal area within the EU, possibly some USA states, China, many Arab countries and others that actually care about data privacy.

I like the patch sent by @toscho many years ago as the safer option (or a Settings -> Privacy checkbox), together with an update of https://wordpress.org/about/privacy/ that @dd32 shared here with a more detailed list of internal data items transferred over the web.

The bold statement above regarding "reading and editing the codebase" completely fails to comply with "Democratize Publishing". A Content Management System is such as it doesn't require IT intervention at all times.

#51 @toscho
5 hours ago

Note that sending the site URL (user agent and wp_blog header) along with these checks makes every WP installation vulnerable to targeted malicious updates. It is even possible that that has happened already: There are gag orders in the US making it impossible for the .org site admins to deny such a scenario convincingly. So we have a bad situation for both sides. Reducing the data and offering an opt-in would really help.

#52 follow-up: @MattyRob
5 hours ago

Pending action in the core code that may or may not happen I've created some code after many hours of messing about logging and blocking all requests and come up with a few functions that reduce the leaking of data. Apologies it's not well documented in what it is doing at the moment and there may be more in there than you need (like blocking auto-updates) but if you are concerned already you are free to use my code:

https://gist.github.com/mattyrob/2e492e5ecb92233eb307f7efd039c121

#53 in reply to: ↑ 52 ; follow-up: @DvanKooten
5 hours ago

Replying to MattyRob:

Pending action in the core code that may or may not happen I've created some code after many hours of messing about logging and blocking all requests and come up with a few functions that reduce the leaking of data. Apologies it's not well documented in what it is doing at the moment and there may be more in there than you need (like blocking auto-updates) but if you are concerned already you are free to use my code:

https://gist.github.com/mattyrob/2e492e5ecb92233eb307f7efd039c121

I just created a simple plugin for this as well, although it only strips off the number of users from the version check request for now. It's on GitHub here: my-precious. It also does not get rid of the auto-update functionality, which is super valuable IMO and makes for another discussion altogether. :-)

Not my place to step on any legal team toes but what steps are being taken towards GDPR compliance? WP will need to publicly clarify all data collection as well as the legal basis behind it in any case.

Heather Burns just pointed this out on Twitter as well. The General Data Protection Regulation is taking effect in May 2018 and it seems that does REQUIRE this sort of behavior to be documented, so it seems there is a legal side to this too.

Last edited 4 hours ago by DvanKooten (previous) (diff)

#54 in reply to: ↑ 53 @idea15
5 hours ago

Heather Burns just pointed this out on Twitter as well. The General Data Protection Regulation is taking effect in May 2018 and it seems that does REQUIRE this sort of behavior to be documented, so it seems there is a legal side to this too.

That's me by the way. ;-)

#55 follow-ups: @TJNowell
4 hours ago

I would note that this information is being sent to WordPress.org, not Automattic. WP is an open-source community project, not an Automattic product

I'd also note that an opt in is going to be much more complicated to implement as the immediate result is no stats or a prompt on update, both of which are bad. WP just needs to state what it sends and where, and we should be doing this anyway if only for documentation purposes

#56 in reply to: ↑ 55 @MattyRob
4 hours ago

Replying to TJNowell:

I would note that this information is being sent to WordPress.org, not Automattic. WP is an open-source community project, not an Automattic product

I'd also note that an opt in is going to be much more complicated to implement as the immediate result is no stats or a prompt on update, both of which are bad. WP just needs to state what it sends and where, and we should be doing this anyway if only for documentation purposes

Your bold text misses one valuable point - I agree that WordPress need to tell users what information is being sent and where to, but users also deserve to be told exactly why, and for each individual piece of data collected.

#57 in reply to: ↑ 35 ; follow-up: @Myatu
4 hours ago

Replying to chriscct7:

... you can freely read and edit the codebase and see exactly what is sent, or learn about how different parts of the project operates.

The "you" used here seems to infer that everyone has the knowledge, time and willingness to inspect the entire WordPress codebase prior to installing or upgrading it. It also contradicts the "Design for the majority" philosophy you quoted later.

... the data is stored by WordPress.org for calculation purposes for 48 hours, and then discarded.

That is enough to warrant disclosure. People need to know what you are collecting, if it is anonymous and for what purposes you use that data.

I don't know the full details of that, and I'd wager a lot of other WordPress users do not either.

You speak of editing the Codex, but:

  • How does someone know what to add to the Codex, if one doesn't know what you do with the data?
  • How will the ordinary WordPress users come to know of it PRIOR to installing or upgrading?

That is a problem and the reason @investici opened this ticket six (!!) years ago.

Also, keep in mind that if the data is not entirely anonymous, then in addition to disclosure, WordPress.org will also be required by the upcoming EU GDPR (2018) to allow WordPress users to opt-out from this data collection, as that regulation will also apply to non-EU organisations.

As for this ticket, WordPress is now used by almost a quarter of the internet, and since 6 years ago a total of what appears to be just 6 (quick count on my part; could be off +/-2) have expressed interest in a filter for this.

Has it occurred that this may have been due to the lack of information to begin with? Had I known about it when I started using WordPress (2008), then I would have certainly chimed into this debate then too.

Aside from the performance implications of calling apply_filter() which albeit while small is still a consideration factor

To sacrifice privacy or security over performance sets a very, very dangerous precedent. I certainly hope this is not the case for other parts of the WordPress codebase.

I wholeheartedly agree with @DvanKooten closure statement, and would like to repeat it in closing:

the very least we could do to improve is to document this behavior and to create a page on what data exactly WordPress is collecting, and why.

#58 in reply to: ↑ 55 @toscho
4 hours ago

Replying to TJNowell:

I would note that this information is being sent to WordPress.org, not Automattic. WP is an open-source community project, not an Automattic product

That doesn't matter for the user. It is an external institution.

I'd also note that an opt in is going to be much more complicated to implement as the immediate result is no stats or a prompt on update, both of which are bad. WP just needs to state what it sends and where, and we should be doing this anyway if only for documentation purposes

It is clear that the exact version numbers of PHP, the database and WordPress itself are needed to generate a useful response. The rest needs to be removed. And even then the user should be made aware of the fact that these data are sent.

#59 in reply to: ↑ 57 @pixline
3 hours ago

Replying to Myatu:

Replying to chriscct7:

As for this ticket, WordPress is now used by almost a quarter of the internet, and since 6 years ago a total of what appears to be just 6 (quick count on my part; could be off +/-2) have expressed interest in a filter for this.

Has it occurred that this may have been due to the lack of information to begin with? Had I known about it when I started using WordPress (2008), then I would have certainly chimed into this debate then too.

Working with WP since 2006 I wrongly assumed that core developers would care about user privacy, and I wrongly assumed that the development process was open and trustworthy for everyone. Now I know that I can't really trust both anymore, I'll take actions by my side to limit this issue.

The suggested solution - a simple filter - would have been enough, but six years without the intention to solve this issue is a show stopper for me and my business partners as well.

On a side note: I really trust @investici and their work, as many other people in EU and elsewhere do because they take action to protect digital rights and user privacy from day one. Feel free to have a look to one of their projects to know more: http://www.autistici.org/en/index.html

#60 @robertheessels
3 hours ago

This is absurd!

Sending sensitive private info, like number of users, without consent or clear warning is morally wrong, if not outright illegal in some countries.

Why are plugins forced to only phone home when the user gives specific consent, while WordPress itself phones home very sensitive info without any consent?

Absurd!

Last edited 3 hours ago by robertheessels (previous) (diff)

#61 @ashokrane
3 hours ago

Like @pixline, I too didn't care for this until now, assuming that there wouldn't be any concerns/issues about user privacy. Not sure how would number of registered users or blogs help, especially during version check.

A checkbox in the Settings -> Privacy page along with a page on what data WP sends back would be ideal.

#62 @danhgilmore
88 minutes ago

Well said, @DvanKooten

I have a major problem with any of the software that I use at work that "calls home" (for lack of a better term). I run WordPress Multisite on three different networks, two of which are completely closed. I can't have WordPress reaching to .com or .org and timing out. Please let me opt-in for stuff like this.

#63 @Rarst
21 minutes ago

I had been WP user since 2008 and I remember privacy issues being repeatedly raised as long. In numerous channels from blog posts, to trac, to the stage of WordCamp Europe. More often in context of plugin/theme updates, which have relatively more impact than multisite stats.

Silent collection of private data is fine — no, it's not.

WP org is run by good guys and that makes it ok — it does not.

There is a way with HTTP API — as an author of Update Blocker plugin that "solution" is ugly, unreliable, and extremely inconvenient. More so at one point in history WP changed API format, which broke every existing implementation of such filters.

I do grasp the context and challenges of such old and grown in system.

But WP should either treat such concerns with respect and attention they deserve or get off the corpse of its "own your data" high horse.

Last edited 17 minutes ago by Rarst (previous) (diff)

#64 @salcode
6 minutes ago

+1 for a clear description of what information is tracked and why, plus a filter for the values sent.

Note: See TracTickets for help on using tickets.