Confirming that suppressed (oversighted) block summaries are visible for everybody at Special:CentralAuth vgr. https://meta.wikimedia.org/w/index.php?title=Special%3ACentralAuth&target=Dferg+%28test%29 & https://test.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=MarcoAurelio&page=User%3ADferg+%28test%29&limit=1. That is problematic. Thanks.

I've done some testing too. Both rev-del'ed and suppressed block summaries are visible on central auth, but also blocks with the hideuser options, which is a suppress action and as such the log of it is already oversighted are fully visible. This is a problem.

Escalating priority on this one. From a legal perspective, we'd like to see something happen here.

Hi Philippe,

I'm still trying to understand everything going on with this bug, but just to clarify, looking at Marco's examples:

it would be desirable on

https://meta.wikimedia.org/w/index.php?title=Special%3ACentralAuth&target=Dferg+%28test%29

to not show the line that shows 1 edit to test.wikipedia.org?

And on https://test.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=MarcoAurelio&page=User%3ADferg+%28test%29&limit=1

the log entry should not show up at all?

(In reply to comment #4)

Hi Philippe,

I'm still trying to understand everything going on with this bug, but just to
clarify, looking at Marco's examples:

Hi all,
I'll try to explain again:

it would be desirable on

https://meta.wikimedia.org/w/index.php?title=Special%3ACentralAuth&target=Dferg+%28test%29

to not show the line that shows 1 edit to test.wikipedia.org?

No, what it needs not to be shown is the "Reason:Test" because that summary is oversighted locally. We need to think if the summary is hidden for all, or just visible for people with the centralauth-oversight rights. If it is very complicated, a placeholder like "Reason: [hidden]" would be great. Stewards can always go and check.

And on
https://test.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=MarcoAurelio&page=User%3ADferg+%28test%29&limit=1

the log entry should not show up at all?

That entry is fine. No need to modify it.

Hope that it helps.
Regards.

Not the whole log entry is the problem only a part of it. The log on testwiki shows a striked (edit summary removed), that is fine, but on meta in the Global user manager the reason is exposed ("Test") and should also striked and replaced with (edit summary removed)

Created attachment 10516
Hide block reason from unprivileged users

This patch should replace the block reason for users without centralauth-oversight permissions in the CentralAuth logs.

Replaced with '<s>(edit summary removed)</s>' for now, unless '[hidden]' is preferred?

Attached:

You are not able to oversight block summaries.

You are able to do hide the block summary from the log, that does not constitute hiding block summary. Block summary oversighting is not currently supported by MediaWiki engine. They are exposed through number of ways, including https://es.wikipedia.org/wiki/Especial:UsuariosBloqueados?wpTarget=Carliitaeliza&limit=50, probably many API functions as well, and also the Toolserver.

The best thing you can do is to reblock the user with non-private summary.

I'm closing this bug until block reason oversighting is implemented in MediaWiki itself, by adding appropriate rev_deleted flags to the block, otherwise the implementation of this would be incorrect.

That really should be done imo, as there's bound to be plenty of blocks laying around that aren't hidden and really should be, as knowledge of this issue is/was not widespread.

I have sent an email to all the oversight and steward lists informing them of this issue and advising them to reblock users to fix this. I have no idea how many blocks are affected nor how to go about listing them to send them to the various OS'ers for fixing (especially including the revdel'ed ones). I've also sent an email to those oversighters with public email addresses, but that's a limited number.

Also, it's clear that the patch posted does way more harm than good, disabling seeing block reasons on CA for everybody no matter if the block is oversighted or not, as I understand it. (the blocks are apparently also leaked thru the BlockList as vvv points out above, as well as API or TS databases, and god knows what else :) ).

Seems it needs a comprehensive solution as VVV said above.

I searched the block logs on the English Wikipedia for suppressed comments. There were 92, but the majority of them were suppressed by accident while suppressing an offensive username. There were only 9 instances of the log comment alone being suppressed: 6 in 2009 and 3 in 2011. More than 12 months have elapsed since the last such log entry.

So given how rare this is, and how simple the workaround is, and how complicated it would be to fix, I'm inclined to think that this should have a low priority.

Why does it not check ipb_deleted? I see that CentralAuthUser::localUserData() only fetches the reason and expiry.

Viewing such items should require centralauth-oversight.

My initial thoughts were along the lines of what vvv and snowolf said-- blocking this in one place seemed like a cover up for a much bigger problem. I was hoping a quick fix would help with Philippe's immediate concerns, but I should have gone with my gut and tried to dig into the root of the problem before throwing out a proposal.

Aaron and Tim, maybe we can chat about this sometime today?

(In reply to comment #11)

Why does it not check ipb_deleted? I see that CentralAuthUser::localUserData()
only fetches the reason and expiry.

Because this code was written before ipb_deleted was implemented, as far as I remember.

Viewing such items should require centralauth-oversight.

Certainly. Although I should note that ipb_deleted stands for "hide name", and I am not sure about what should happen when local name is oversighted and global is not. I mean, it should certainly be oversighted globally (from social standpoint), but how engine should handle those situations (hide whole name, hide row, display "hidden" placeholder for the row, or something else).

(In reply to comment #12)

My initial thoughts were along the lines of what vvv and snowolf said--
blocking this in one place seemed like a cover up for a much bigger problem. I
was hoping a quick fix would help with Philippe's immediate concerns, but I
should have gone with my gut and tried to dig into the root of the problem
before throwing out a proposal.

The proper way to fix this is to rework ipb_deleted. Currently the code assumes it is a boolean field which is set to 1 when the username is hidden and 0 when it is not. It should be a bitfield instead (like rev_deleted), or a separate column, but reworking it and fixing it in many places (I am not to mention possible breakage of third-party extensions) may be tedious and difficult to do. Also, both ways would require a schema change, since ipb_deleted is a boolean.

"boolean" in MySQL means integer (tinyint(1)). So we wouldn't actually have to change anything for wmf sites (though if we did it would be pretty fast anyway).

In any case, if ipb_deleted is set, then the whole block should be redacted if possible. That's how it works locally on wikis.

That said, I don't see much of a use case for just hiding summaries for non-suppress blocks.

Perhaps we should ask an oversighter or a steward? They're the guys who have to deal with this in practise. :)

Aaron pointed me to SpecialBlockList, which does

if ( !$this->getUser()->isAllowed( 'hideuser' ) ){
$conds['ipb_deleted'] = 0;
}

for querying the list. Would it make sense to try and be consistent in CentralAuth?

(In reply to comment #18)

Aaron pointed me to SpecialBlockList, which does

if ( !$this->getUser()->isAllowed( 'hideuser' ) ){

$conds['ipb_deleted'] = 0;

}

for querying the list. Would it make sense to try and be consistent in
CentralAuth?

As I said above, this is irrelevant to the current bug, which relates to block summaries, not to blocks themselves. A fix for displaying hidden blocks would be surely a good thing, but I am not sure how should it be displayed to the user.

[Removing RESOLVED LATER as discussed in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . Reopening and setting priority to "Lowest". For future reference, please use either RESOLVED WONTFIX (for issues that will not be fixed), or simply set lowest priority. Thanks a lot!]

I can confim that I was victim of this bug today. Having suppressed the summary of a block so as to make it invisible to anyone except users with the viewsuppressed user right, I was disappointed to see that the summary was leaked on Special:CentralAuth — on Meta as well as on other wikis, including the wiki that I suppressed it on.

In the end, I worked around this bug by changing the block summary to an empty one: after the update, the old (already suppressed) summary was no longer visible.

In my situation, this was not that much of a deal, but it is nonetheless something that should not be happening for privacy reasons.

Users shouldn't be blocked without an edit summary honestly, so the workaround (reblocking with a non suppressed rational) should actually be the best practice. What I think needs to be fixed is disabling the ability for oversighters to suppress the currently applied block so that they have no choice but to reblock with a new rationale before suppressing the block log entry.