bugs wrote:

Why is this necessary? CheckUser is supposed to be restricted as is, so I don't know why we'd need to hide the data from even them. We don't really have anything like this either, e.g., there's no "block-protect".

admin wrote:

For protect from disclosure personal data of bureaucrats, sysops and other trusted users when check IP ranges.

In some private wikis this right would be very helpful.

happy.melon.wiki wrote:

Quis custodiet ipsos custodes?

Closing as WONTFIX. Maybe if there was some sort of community discussion then we could consider it, but I think it's a bad idea. The point of CheckUser is so that the editor community can sort out identity disputes themselves, without bothering sysadmins. This change would be a step backwards: when sysops or bureaucrats are suspected of having sockpuppets, the CheckUser request would be forwarded to a sysadmin instead of handled in the usual way.

admin wrote:

Reopened.

This is NOT for Wikimedia projects and I not proposal enable this right in Wikimedia sites.

This is proposal of OPTIONAL right, not defined by default, for use in private wikis, not related to Wikimedia...

admin wrote:

Example:

If I sysadmin and founder of wiki-site, I have the right to protect my personal data from local checkusers, this is mistake proofing.

Currently this is not a change that will be accepted into the main repository; as noted above, the requested feature doesn't mesh with CheckUser's design goals (use by a trusted admin subset on Wikimedia Foundation sites, with a flat permission access level).

However since the code is available to you, please feel free to modify it for your own custom use case. It should pretty much be a matter of adding:

global $wgUser;
if ( $wgUser->hasRight( 'checkuser-protect' ) ) {
  return true;
}

to some of the hook functions in CheckUser.php.

(In reply to comment #7)

Currently this is not a change that will be accepted into the main repository;
as noted above, the requested feature doesn't mesh with CheckUser's design
goals (use by a trusted admin subset on Wikimedia Foundation sites, with a flat
permission access level).

For what it's worth, I disagree with this resolution, but seeing that both Tim and Brion have now marked this as "wontfix," I won't overturn it.

CheckUser was certainly designed with Wikimedia wikis in mind, but much like MediaWiki and its various extensions, it's used on plenty of other sites. I don't see anything here that interferes with the principle and tradition of agnostic code development. It's perfectly possible to add a permissions check that doesn't interfere with Wikimedia's operations (e.g., comment out the permissions making them opt-in, problem solved).

The idea itself (allowing people to be exempt from CheckUsers) has a bit flimsy reasoning currently, but no more so than the counter-arguments, which basically amount to "this wasn't in the original spec." I don't see any reason that we should be saying "we're not even going to accept patches for this, so stop asking."

Without any real justification *for* a feature that goes against the design, it shouldn't be considered on bugzilla. People could still talk about it, such as on MW.org, and come up with reasons. BZ isn't really a good forum for tossing ideas out there (not once the comments start piling up).

This reminds me of some of the confusing, un-discussed, design melting features requested for FlaggedRevs...which ended up causing trouble and some were later removed or redone. These things need to be discussed/refined first before being implementable.

Also, I don't think Brion or Tim's reasons are flimsy...though they aren't 100% "beyond debate" knock-downs either.

admin wrote:

OK.

Brion and others, you can publish the corrected file CheckUser.php for MediaWiki 1.16.2 with fixes for use on non-Wikimedia sites, for example as attachment to this request?

Would be very grateful...

Range checks are not only done for fiding suspects, but also for determining damage of a block.
So you could determine that blocking a /24 is safe to do, since there are no good editions from there, and end up blocking several admins!

admin wrote:

Proposed patch

Patch with proposed fixed by wikireality.ru users Edward Chernenko and His Shadow.

attachment checkuser-protect.txt ignored as obsolete

happy.melon.wiki wrote:

Created attachment 8433 [details]
Proposed patch

Patch with proposed fixed by wikireality.ru users Edward Chernenko and His
Shadow.

Currently this is not a change that will be accepted into the main repository;

It's great to have a patch, although it would be better if it were in unified diff format. That doesn't change the fact that MediaWiki's Lead Architect and Release Manager have both said such a patch will not be accepted into the main repository. *Please* don't bugwar over resolution statuses; you are rearranging deckchairs on the Titanic.

attachment checkuser-protect.txt ignored as obsolete

Created attachment 8434
Proposed patch in patch format, with interface messages added

I've converted the supplied patch into patch format so someone else can apply it easily to their working copy.

I've also added in the missing interface messages that were added in this patch, based on the documentation I could glean from a google-translated version of http://wikireality.ru/wiki/CheckUser_Protect

By default the userright isn't assigned to any groups, it should probably stay this way if this whole thing isn't completely discarded. Please note that I've not actually even looked at the code supplied, just pushed it onto the code properly - if there are glaring holes, look back to the original author.

I'm not so sure about this, it seems like a bad idea - if you don't trust those whom you give checkuser to, what's to say others can trust them? If you can't trust them, maybe they shouldn't have checkuser access in the first place.

I made the patch so someone else could review it for feasibility - I hope it's semi-useful in that review process.

Attached:

krsneugene wrote:

Hmm, this patch is very useful code...

Probably, if 'checkuser-protect' right isn't assigned to any groups, it's possible merge this code to the extension?

And system administrators of wiki will be able to opt-in this feature.

Please, let decide Brion Vibber or Tim Starling.

Nothing seems to have changed in the situation, so re-resolving as WONTFIX. Do feel free to use the custom patch if it serves your specific needs, but we won't accept it into mainline as it doesn't seem to be a good match-up with how CheckUser is meant to be used.