Privacy policy/Fix block messages

The process required to fix the leaking of private information via messages to auto-blocked users

See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=53008, (now https://phabricator.wikimedia.org/T55008) proposed patch https://gerrit.wikimedia.org/r/#/c/92254/ by saper, which may or may not fit the current thinking on this bug.

Note: I (Rich Farmbrough) am drafting this based on my understanding of the software, processes and technology. Please improve this page where my understanding is flawed.

Background

Private information pertaining to blocked users (blocked user or blocked party) is provided to other users who are autoblocked (autoblocked user or autoblocked party), due to using the same IP address (or range?). May also reveal IP address of autoblocked party to "the world" if they are careless, or instructed to reveal it.

This is done to facilitate unblocking in a "good guy" scenario.

It is possible to provide the autoblocked user(s) with only the block ID number while still enabling the block to be reviewed and removed.

Further it is possible to restrict the access to block numbers only to administrators. (According to the Privacy Policy it should be to those who have self identified.)

Other information currently available is:

• Block reason supplied by admin - provides a link through the block log to indicate the blocked party
• IP address of blocked user - If reposted reveals the autoblocked party's IP address, and in conjunction with certain other items the blocked user's IP address. The user is seeing their own IP address, which they know anyway, so the only risk with this item is that they see it and post it unnecessarily.
• Blocking admin's name - provides a link through the admin's action log to indicate the blocked party
• Timestamp of autoblock expiration - this is the timestamp for the autoblock. It is the 24 hour anniversary of the start of the autoblock, or the expiry time of the original block that led to the autoblock, whichever is earlier.
• User block was applied to - reveals to the autoblocked user (and if posted the world) the link between the blocked user and the autoblocked user. Significantly may reveal the real life identity of the blocked user to the autoblocked user, and indeed vice versa.
• Timestamp of block start time - Enables the autoblocked user to know when the blocked user was last editing, and hence may reveal their identity.

Preliminary removal of surplus information from Mediawiki: message pages

Removing the sensitive information and leaving just the block number can be done in a number of ways:

The most thorough method is

1. Change the default messages in the Mediwiki code
2. Update all the translations on translatewiki
3. Check all Wikimedia projects have been updated

Autoblocker

For example the text on Autoblocker, according to translatewiki

Autoblocked because your IP address has been recently used by "$1". The reason given for $1's block is "$2"

For Autoblocker the parameters are

   $1 - target username
   $2 - reason

both of which should be suppressed.

The message can be simplified to

Autoblocked because your IP address has been recently used by a blocked user

MediaWiki:Autoblockedtext/en

2. Ideally the message in MediaWiki:Autoblockedtext/en should be something like

---

Your IP address has been automatically blocked because it was used by another user, who was blocked by an administrator. This type of block generally expires within 24 hours.

You may contact any administrators to discuss the block. The block ID is #$5. Please include this number in any queries you make.

Note that you may not use the "email this user" feature unless you have a valid email address registered in your user preferences and you have not been blocked from using it.

MediaWiki:Cantcreateaccount-text

Current text is

Account creation from this IP address ($1) has been blocked by $3.

The reason given by $3 is $2

Again this should be replace s with something like:

Account creation from this IP address has been blocked. The block reference is #$4. To appeal this block please contact an administrator quoting the block number.

I'm not sure that the block ID is available so a code fix might need to precede this change

Suppression of unneeded parameters in mediawiki code

The solution above is subject to a number of attacks, by translatewiki editors, or by admins on any language wikiproject. Also a well meaning agent could inadvertently disclose these parameters by attempting to make the message pages more comprehensive.

This is because the private parameters are still passed to the mediawiki pages.

The proposal is that both parameters passes to Mediawiki:Autoblocker are suppressed, and all except $5, are suppressed from MediaWiki:Autoblockedtext.

Something like:

           return array(
                , // name of mediawiki page here?
                ,	
                ,
                ,
                $this->getId(),
                ,
                ,
                ,
           )

Parameter 4, $context->getRequest()->getIP(), may be necessary, but I believe the unblock can be done by the block number, which is used to find the autoblock on the block log.

At this point personal information and opportunities to find it is not being thrust in the face of users, so although the data is not secure, pragmatically we have moved forward.

Suppression of block ID number in log

The block ID is needed by the unblocking admin to investigate and lift the block. This block ID number is of little or no use to anyone else, unless they are asked to look at an autoblock. There are sufficient admins that that this should not be a problem.

Therefore the block log interface should not show the block ID number, except to admins. Autoblocked users will see the number on the autoblock message of course.

Change in generation of block numbers

Block numbers are currently sequential. A suitable means of generating pseudo-random non-repeating block numbers should be employed. Possibly UUIDs.

Suppression of historical leaks of private information

Each project, with support where necessary, should perform an audit/oversight on uses (including uses in history) of the following templates (or their equivalents)

• Template:Unblock-auto
• Template:Unblock-auto reviewed
• Template:Unblock-auto on hold

Example

You can see where this has been done correctly, though possibly the private data is still visible to administrators, by viewing the history of wp:en:User talk:Leodj1992.

Limitations

1. According to the privacy policy the personal information should only be available to users who have self-identified to the Foundation, however I believe this (I.E. the admin only solution) is an expedient compromise.
2. It may be possible to monitor the block log and see unblocks occurring, thus deducing which autoblock was unblocked.
3. It may be possible to extract a limited amount of information by social engineering and relatively advanced means.
4. I have no knowledge of the code and have not (as far as I remember) fixed any autoblocks, so I may have missed something obvious.