Last modified: 2013-03-08 19:22:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37971, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35971 - Local revision-deleted block summaries appearing at Special:CentralAuth
Local revision-deleted block summaries appearing at Special:CentralAuth
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: revdel SWMT
  Show dependency treegraph
 
Reported: 2012-04-14 12:40 UTC by MA
Modified: 2013-03-08 19:22 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Hide block reason from unprivileged users (537 bytes, patch)
2012-05-04 23:46 UTC, Chris Steipp
Details

Description MA 2012-04-14 12:40:16 UTC
Local revision-deleted block summaries appears at the Special:CentralAuth user info table vgr. <https://es.wikipedia.org/w/index.php?title=Especial:Registro/block&page=Usuario:Carliitaeliza> & <https://meta.wikimedia.org/w/index.php?title=Special:CentralAuth&target=Carliitaeliza> [at es.wikipedia.org].

Even if you are logged-out you can see those revision-deleted summaries. I think that very part is wrong. My thinking is that stewards and users with the, maybe, 'centralauth-oversight' rights could still be able to see it [currently stewards and employees] but other users should not be.

I'll test if suppressed (oversighted) summaries still appears too and report back here in a new comment.

Thank you.
Comment 1 MA 2012-04-14 13:33:15 UTC
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.
Comment 2 Snowolf 2012-04-15 12:25:54 UTC
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.
Comment 3 Philippe Beaudette 2012-05-02 17:56:55 UTC
Escalating priority on this one.  From a legal perspective, we'd like to see something happen here.
Comment 4 Chris Steipp 2012-05-03 23:57:07 UTC
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?
Comment 5 MA 2012-05-04 05:13:35 UTC
(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.
Comment 6 db [inactive,noenotif] 2012-05-04 16:23:55 UTC
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)
Comment 7 Chris Steipp 2012-05-04 23:46:15 UTC
Created attachment 10516 [details]
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?
Comment 8 Victor Vasiliev 2012-05-05 10:04:42 UTC
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.
Comment 9 Snowolf 2012-05-05 11:30:39 UTC
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.
Comment 10 Tim Starling 2012-05-07 04:46:26 UTC
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.
Comment 11 Aaron Schulz 2012-05-07 05:56:16 UTC
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.
Comment 12 Chris Steipp 2012-05-07 16:29:50 UTC
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?
Comment 13 Victor Vasiliev 2012-05-07 16:47:59 UTC
(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).
Comment 14 Victor Vasiliev 2012-05-07 17:08:43 UTC
(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.
Comment 15 Aaron Schulz 2012-05-07 17:13:20 UTC
"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.
Comment 16 Aaron Schulz 2012-05-07 17:16:17 UTC
That said, I don't see much of a use case for just hiding summaries for non-suppress blocks.
Comment 17 Oliver Keyes 2012-05-07 17:25:29 UTC
Perhaps we should ask an oversighter or a steward? They're the guys who have to deal with this in practise. :)
Comment 18 Chris Steipp 2012-05-07 18:41:08 UTC
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?
Comment 19 Victor Vasiliev 2012-05-07 19:53:58 UTC
(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.
Comment 20 Andre Klapper 2012-12-19 11:29:12 UTC
[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!]

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links