The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

Change 990790 had a related patch set uploaded (by AntiCompositeNumber; author: AntiCompositeNumber):

[operations/puppet@production] Add global_edit_count to fullviews

https://gerrit.wikimedia.org/r/990790

AIUI currently Data Engineering reviews the view changes to ensure the data is ok to publish and then WMCS (or Data Platform?) SREs deploy them. Let's use this as an example to figure out the review process and document it to https://wikitech.wikimedia.org/wiki/Portal:Data_Services/Admin/Runbooks/Deploy_wiki_replicas_view_change#Review_process.

@lbowmaker, @WDoranWMF, @Ahoelzl - Would you be able to help us to define the procedure here please?
We have anew request for a change to the wikireplica views.

@taavi has tagged the ticket with Data-Platform (which I think is correct) and it's been in the backlog for a while.

Either Data-Platform-SRE or cloud-services-team could apply the patch, but I think that we need a review from Data-Engineering in order to be sure that we meet the privacy requirements.

The change seems simple enough, adding global_edit_count but I wouldn't want to say, personally, if this is permissible from a privacy standpoint.

I agree that this would be a good opportunity to get the review process defined a little better.

Suggest to filter out all rows for gec_user which gets itself filtered out of globaluser, visible should be only rows with gu_hidden_level=0 (join condition/not exists condition on gec_user=gu_id)

@joanna_borun could you help with defining the review process for this change, and similar ones in the future?

This will be useful for T355594 too. My script for generating voter lists for global elections can run quite faster if it can easily filter out users with less than N global edits.

Hi @aranyap, similar to T402145, could you review and approve this one too?

For reference, this is the sample content of the table:

mysql:research@dbstore1008.eqiad.wmnet [centralauth]> select * from global_edit_count limit 10;
+----------+-----------+
| gec_user | gec_count |
+----------+-----------+
|        0 |         0 |
|        1 |     14223 |
|        3 |     55550 |
|        4 |    149447 |
|        5 |         0 |
|        6 |      7460 |
|        8 |        22 |
|        9 |         1 |
|       10 |        46 |
|       11 |        78 |
+----------+-----------+
10 rows in set (0.001 sec)

Global edit count for any user is publicly accessible from Special:CentralAuth. Per T344108#9527354 and similar to the existing globalblocks view, there'll be a filter to redact rows corresponding to hidden users (not exists ( select 1 from globaluser where gu_id = gec_user AND gu_hidden_level != 0 ))

The Product Safety & Integrity team has reviewed this table and is considering this to be a low privacy risk as long the following privacy protecting strategy is implemented:

1. Suppress the counts that fall below a data-driven percentile cutoff of the overall distribution. To determine the cutoff, run:

SELECT PERCENTILE_CONT(0.05) WITHIN GROUP (ORDER BY gec_count) 
FROM global_edit_count;

and use the resulting value as the suppression threshold.

Thank you for your patience!

In T344108#12078673, @aranyap wrote:

The Product Safety & Integrity team has reviewed this table and is considering this to be a low privacy risk as long the following privacy protecting strategy is implemented:

1. Suppress the counts that fall below a data-driven percentile cutoff of the overall distribution. To determine the cutoff, run:

SELECT PERCENTILE_CONT(0.05) WITHIN GROUP (ORDER BY gec_count) 
FROM global_edit_count;

and use the resulting value as the suppression threshold.

Thank you for your patience!

@aranyap, @sbassett consider me confused here. I do not understand the privacy consideration being used here, and I think you've made the wrong assumptions. This value is already publicly available for a specific user publicly to all users through the Wikimedia UI (on Special:CentralAuth) and in the API. If an adversary wanted to deanonymize a person (or even a group of persons) based on the global edit count, querying the wikireplicas would be the most inefficient way to mount such an attack, since one normal API call can "deanonymize" a user (or worse yet, a single fetch to the CentralAuth page). Even assuming that the value is elided in some manner, for a determined attacker, it would be easier to query a particular user's edit count across all our wikis by making relatively spaced-out API requests and then adding them together than to sign up for a Toolforge account, waiting for approval, write SQL to query this value, downloading the huge list of values and then correlating it on the fly with a username.

Even setting that aside, the methodology you propose for anonymizing the gec_count value (which is already trivially publicly accessible) risks suppressing the data for folks who are less likely to be deanonymized. A user with one edit globally is less likely to be identified (since there are a lot of folks with at least one edit) versus somebody with say > 50k edits globally.

Would it be possible for you to reconsider/revaluate the risk of exposing this value without any suppression?

@Soda Thanks for pushing here - your analysis is right, and we are fine with exposing this value without any suppression, given it is already easily publicly available, and that lower edit counts are not more identifiable than higher edit counts.

Similar to T402145, this table is currently marked as visibility: private in the catalog, and so isn't replicated to the Wiki Replicas. Tagging DBA for what options we have for starting to replicate that table.

In T344108#12085858, @taavi wrote:

Similar to T402145, this table is currently marked as visibility: private in the catalog, and so isn't replicated to the Wiki Replicas. Tagging DBA for what options we have for starting to replicate that table.

The table isn't very big: -rw-rw---- 1 mysql mysql 2.5G Jul 3 14:48 global_edit_count.ibd so the process would be something like:

• stop replication on the sanitarium master
• make it public on the catalog
• restart replication on sanitarium to pick up new filters
• mysqldump the table on sanitarium master
• import it on sanitarium and let it replicate
• start replication on sanitarium master
• places the needed views on it.

In T344108#12085972, @Marostegui wrote:

In T344108#12085858, @taavi wrote:

Similar to T402145, this table is currently marked as visibility: private in the catalog, and so isn't replicated to the Wiki Replicas. Tagging DBA for what options we have for starting to replicate that table.

The table isn't very big: -rw-rw---- 1 mysql mysql 2.5G Jul 3 14:48 global_edit_count.ibd so the process would be something like:

• stop replication on the sanitarium master
• make it public on the catalog
• restart replication on sanitarium to pick up new filters
• mysqldump the table on sanitarium master
• import it on sanitarium and let it replicate
• start replication on sanitarium master
• places the needed views on it.

This would need to be signed off by Security.

In T344108#12085973, @Marostegui wrote:

This would need to be signed off by Security.

That's T344108#12085846, unless I'm missing something?

Ah right! Missed that! THanks

Change #1307487 had a related patch set uploaded (by SD0001; author: SD0001):

[operations/puppet@production] maintain-views: add view for global_edit_count

https://gerrit.wikimedia.org/r/1307487