[wp-trac] [WordPress Trac] #16778: wordpress is leaking user/blog information during wp_version_check()

[WordPress Trac]

#16778: wordpress is leaking user/blog information during wp_version_check()
----------------------------+-----------------------
 Reporter:  investici       |       Owner:
     Type:  enhancement     |      Status:  reopened
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:
 Severity:  minor           |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-----------------------

Comment (by Otto42):

 > Not sure how would number of registered users or blogs help, especially
 during version check.

 Specifically, this code was imported during the merge of WordPress to
 WordPress-MU, when multisite was added. The reason for this particular
 data being sent has to do with the possible necessity of providing
 alternate upgrade paths for large installations.

 When in multisite mode, WordPress stores each site in the network as a
 separate set of tables. For anybody who has done an update on such a site,
 you'll know that there is an "Update Network" process which runs through
 each of those tables performing any changes to them that may have happened
 in the update. These can be as simple as running some queries to update a
 few rows in the options table, or entire schema adjustments. While this
 process is fine for smaller installations, it won't work on truly big
 installations. Too slow, basically.

 The "number of blogs" is thus sent back in case there is some major update
 to the schema that might require the dev team to create a separate update
 path. It's one thing to have a couple of blogs do some schema changes, but
 multisite instances exist with hundreds of thousands of sets of tables.
 Those sites might need special handling at some future point. It has not
 happened yet, but it is certainly possible.

 The "number of users" information is for the same reason. Large multisite
 instances can have tens of millions of rows in the users table. Schema
 changes to that table can literally cripple sites and bring them to a
 screeching halt. Such large updates might need special handling if the
 users table schema changes (and that has happened before).

 So, these checks exist in the API just in case an update ever needs to be
 created specially for larger instances of WordPress. They were added to
 the update checks solely for that reason. They're not there specifically
 for data gathering purposes.

 If you wish to filter the data for privacy purposes, then you can do so
 and it will not affect the update process for small WordPress
 installations. At present, there is not a secondary update path for large
 installations, but that does not preclude the possibility of one occurring
 in the future.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/16778#comment:67>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform