Talk:CheckUser policy

From Meta, a Wikimedia project coordination wiki

Jump to: navigation, search
This page is for discussions related to the CheckUser policy page.

  Please remember to:
Wikimedia Community Logo.svg


Archive
Archives

Contents


[edit] checkuser in user log

Currently use of checkuser is not logged anywhere. It should be logged somewhere similar to logs of moving/uploading/blocking/protecting. For example: "User:XYZ checked user User:ABC." This would bring in transparency, and protect privacy. It would be a not so difficult technical task to make it work. Thanks. Phantom 34323 06:46, 26 November 2007 (UTC)

It is logged, but the logs are only available to checkusers for privacy reasons (which trump transparency). John Reaves (talk) 06:56, 26 November 2007 (UTC)
Every checkuser action in logeed privately. The log is visible for everybody with that permission, but not to general public due to privacy policy. Open log would make it easy to make corellations like "first they checked this user, one minute later they checked that IP. Guess whose IP it is?". Publishing username checks only is no less bad idea, as it would allow people to make usubstaintiated assumptions of bad faith like "he was checked, probably he has something to hide". MaxSem(Han shot first!) 06:58, 26 November 2007 (UTC)
Oh this is cool, and importantly very fair, IMO. Thanks for the info, and this info should be mentioned in policy page (if its not there already). Wikimedia is so much alive :) Phantom 34323 07:15, 26 November 2007 (UTC)
It is already there in policy page. Phantom 34323 04:57, 27 November 2007 (UTC)

[edit] Autoblock procedure

Unblocking of an autoblock needs to disclose one's ip address. Is it a necessary or just "list of autoblock #s" enough? I think this is important in view of privacy policy.. Thanks. Phantom 34323 04:57, 27 November 2007 (UTC)

(belated) You can unblock an autoblock by using the autoblock number (unblock #32623 for instance). The IP isn't necessary. Kylu 17:02, 10 July 2008 (UTC)

[edit] needing clarification

Hello, I'm trying to find out whether the change of the statements below is official, as the discussion above seems somewhat unsettled, and most translated versions of the policy have not reflected this change yet:

Even if the user is committing abuse, it's best not to reveal personal information if possible.

  • Generally, do not reveal IPs. Only give information such as same network/not same network or similar. If detailed information is provided, make sure the person you are giving it to is a trusted person and will not reveal it himself.
  • If the user has said they're from somewhere and the IP confirms it, it's not releasing private information to confirm it if needed.
  • If they're on a large national or international ISP (e.g. AOL, NTL, BT, Telstra) where they're one of millions of users, saying so is unlikely to be personally identifiable.
  • Revealing the country is generally not personally identifiable (e.g. "User:Querulous is coming in from the UK, User:Sockpuppet is coming in from Canada").
  • If you're in any doubt, give no detail.

was changed to

Even if the user is committing abuse, it's best not to reveal personal information if possible.

  • Generally, do not reveal IPs. Only give information such as same network/not same network or similar. If detailed information is provided, make sure the person you are giving it to is a trusted person and will not reveal it himself.
  • If the user has said they're from somewhere and the IP confirms it, it's not releasing private information to confirm it if needed.
  • If you're in any doubt, give no detail.

If it is official, please confirm, so that the translated versions can be adjusted accordingly. Thank you for your attention.--75.156.77.73 22:28, 2 December 2007 (UTC)

[edit] Votes

Just a piece of question. How many votes do you have to get to have a checkuser on a Wikipedia with less than 15 quite active wikipedians about 5 to 8 of which are very active but three of which don't want to vote and remain neutral? We already have three votes for one and another two for the other in a local checkuser election here in the Tagalog Wikipedia. -- Felipe Aira 07:13, 23 December 2007 (UTC)

I believe the feeling is that if you are not able to get at least 25 votes, then your community is not active enough to need local checkusers. Feel free to request that stewards perform checkusers for you on Requests for CheckUser information. Cbrown1023 talk 12:50, 23 December 2007 (UTC)

[edit] Removal for inactivity

I think this part of the policy needs to be clarified. Does anyone have any suggestions about ways to tweak the wording to clarify whether the inactivity is related to the Checkuser tools or overall account inactivity. Also, do we need to add wording about if there is a duty for an Arbitration Committees, stewards, or the Community to investigate an Checkusers level of activity. FloNight 21:00, 3 January 2008 (UTC)

I think there is no need to connect this to inactivity as checkuser. Smaller wikis have a good chance to have few problems that need CU. Should anyone who is active as editor check random users in order to show checkuser activity? :-) Bináris 07:53, 6 January 2008 (UTC)

Any wiki which is that inactive probably doesn't need the CU in the first place; I'd be surprised if the requisite 25-30 votes could be mustered on a wiki which has no need for a CU over the course of a full year.  – Mike.lifeguard | @en.wb 21:41, 6 January 2008 (UTC)

There must be at least 2 CUs per wiki. I can easily imagine that one of them is a network sysop IRL and spends his/her day in front of the monitor and will complete all the requests before the other arrives. Should the other one removed for inactivity and elected a third one instead of him/her immediately in order to have the 2 CUs? :-) Bináris 09:26, 15 January 2008 (UTC)

I think this needs approaching with common sense on a per wiki basis. If you have ample CUs some of whom are completely inactive (the case on Commons) then the policy allows removal. In the case you use I hope the community would discuss the matter and certainly not lose CU access completely --Herby talk thyme 09:32, 15 January 2008 (UTC)
Just to be a thorn in the side of common wisdom, might I point out that there may be Wikimedia projects with two dozen or more active participants whose cultural background would encourage them to elect two local CUs ready to protect the project even if they hadn't had a single serious problem yet? Some cultures prefer establishing authorities in advance of problems instead of resisting authority unless a compelling need is demonstrated. Not everyone buys into the overarching principle of personal freedom and privacy that many Western cultures demand. And although one might expect that the use of a wiki would encourage people to think that way, I suspect most cultures are more resilient and flexible about sustaining what might appear to be contradictory beliefs to the Western mind. In other words, I'd be surprised if we don't have (or will soon have) projects that can summon 25-30 votes for local CUs with no urgent need, simply because they'd rather act proactively than wait to suffer the problems they hear about on other projects. ~ Jeff Q (talk) 03:07, 9 March 2008 (UTC)

[edit] Arbcoms vs. elections for CUs

Elian made this revision back in November. While it's apparently what de:wp does (?) I'm not sure it's actually official policy, is it? I became aware of this because of this w:Wikipedia talk:Requests for checkusership in which Majorly proposed elections and the en:wp arbcom reasserted the appointment process. This may be something to bring up at "rewriting" as well. ++Lar: t/c 06:51, 27 January 2008 (UTC)

Hmmm I am rather indifferent about this, and wonder if German Wikipedia just could choose a course to have their Arbcom say "yes" to existing CUs when their Arbcom was set up, but it introduce some ambiguity and better to have been discussed beforehand. I personally feel it would be better for us all to let each community decide if their Arbcom rules here or not, keeping the current flexibility, but anyway we need to discuss. (foundation-l perhaps?) --Aphaia 04:22, 28 January 2008 (UTC)
One of the pitfalls of this type of addition to policy without discussion is that the Community has no way of knowing about the change. The Wikipedia English Arbcom had no idea that the policy was changed. That is the reason that I'm pushing for a Wikicouncil to help review all the policies in an organized manner and make recommendations taking into account the needs of all the projects. As to the substance of the change, I think that we need to recognize that the needs of communities differ as well as the political dynamics that allow for changes to happen. For that reason, I think that we need to be as flexible as possible in allowing Communities to make decisions that keep their Community growing and thriving. FloNight 11:39, 28 January 2008 (UTC)
Just for clarification. On dewiki there is no policy for the appointment of Checkusers at all. Neither the checkusers themselves can appoint new collegues nor is the arbcom willing to do so. There must be a normal election just like for sysops and other people. --Thogo (talk) 11:43, 28 January 2008 (UTC)
Out of curiosity, who monitors the CU's activity to make sure that it falls within the activity level policy, or Foundation privacy policy, or other Community standards? FloNight 13:00, 28 January 2008 (UTC)
Every checkuser monitors the other checkusers, of course. --Thogo (talk) 13:03, 28 January 2008 (UTC)
So it is a self-monitoring system. As we appoint more CU on Wikipedia Englsih that are not on arbcom, I think we need to decide who is responsible for monitoring the CU. Since we are responsible for the appointments, we monitor the activity level to see the need for more appointments. We are also responsible for examining complaints of misuse as they relate to our policies. I wonder if any other communities do it differently than self monitoring and/or arbcom monitoring. Thanks for answering my questions as I try to sort this out. :-) FloNight 14:03, 28 January 2008 (UTC)
I thought the point of this section was to allow communities not large enough for an ArbCom to have CUs. If that's the case, then wikis with an ArbCom should have ArbCom appoint CUs, while wikis without an ArbCom will use the voting method. Is there some problem on dewikipedia that is solved by allowing an election despite there being an ArbCom?  – Mike.lifeguard | @en.wb 16:02, 28 January 2008 (UTC)
The role of an arbitration committee is dispute arbitration, not government; if some wikis want a reduced level of bureaucracy compared to the English Wikipedia, I really don't see a problem with letting them have regular elections instead. —{admin} Pathoschild 16:35:35, 28 January 2008 (UTC)
I am not opposed to that idea but I think it needs ratification by the Foundation Board, rather than just being changed by an edit with no prior discussion. The current process came from them. Because of privacy concerns, they may have reasons for wanting ArbCom involved if one exists. Or not... I agree that ArbComs are for problem resolution not governance, except that the Board has seen fit to give them some governance roles, and so has Jimbo directly (the en:wp IRC mandate being an example), whether they wanted them or not. ++Lar: t/c 17:06, 28 January 2008 (UTC)
Well yes, but my questions was really "What does the policy actually say on this point?" If it says that elections are for use where ArbCom doesn't exist, then we may want to change it. (As opposed to a change that went unnoticed for 2 months and is only now being discussed).  – Mike.lifeguard | @en.wb 17:09, 28 January 2008 (UTC)
The change is still there I think, last I checked. I'd advocate changing it back until it's clear that there is a mandate for the change. As an aside, I'm not sure I see how the WikiCouncil proposal would solve this issue. I am not sure that more talking shops without clear mandates would help matters, I suspect they would make things more confusing. This particular thing (CU permission granting) is one small policy that is not under the control of individual wikis. But most things are and I suspect most wikis like it that way and are not too keen on the idea of a vast new bureaucracy that will have authority over them. But I digress. ++Lar: t/c 17:21, 28 January 2008 (UTC)
We need to figure out a way to write policies that represent the needs of wiki of all sizes and types. What we are doing now will not scale. Having unstable versions of policies that are not regularly reviewed is problematic. Users that read a policy expect it to be an accurate statement of the actual policy and well thought out. Currently, no one is doing this work in a systematic timely manner. I suspect that elected representative that commit to doing research into the needs of the Global Community will have a better outcome than user(s) that makes changes based on their immediate thought. The step of forming a Wikicouncil to do some of these tasks for the Community meshes with the growth and maturity of the Foundation. Once all the work was done primarily by a volunteers. Hiring qualified staff is moving the Foundation forward. The Community need to find better ways to work with them. We need to figure out our needs so they can meet them better. FloNight 17:50, 28 January 2008 (UTC)
Mike, dewiki does actually have an arbcom, so there is no problem. If the foundation decides that only the arbcom can approve checkusers, we will do it this way, but until now we arbcom people didn't feel responsible for checkusers. I would wish a clarification of the foundation about this point in the policy. Otherwise I guess it's completely ok, if a community decides to elect their CUs like sysops/bureaucrats. --Thogo (talk) 18:01, 28 January 2008 (UTC)
Again, let's set the policy back the way the board had it. If de:wp arbcom wants to delegate the selection of CUs to the community, that's within their remit... they just say "we will have the community hold elections and after they are held, we submit the results as if we made the choice ourselves"... no need for policy change. As for the issue of the policy being changed, again, for this particular thing, no need for a big new bureaucracy... just put the policy on the wmfwiki, instead of here where it can be edited by just anyone that comes along. Maybe there is some need for a new 30(? ... 200 ?? ... whatever) person grand shiny new council to decide things but this isn't the thing that demonstrates that need as far as I can see. that would be way overkill for something that common sense sorts out easily. ++Lar: t/c 19:15, 28 January 2008 (UTC)

I support to change it back to the previous version of Elian's with a hope to update it reflecting all current situations. FloNight brought a good point: policy should cover all community needs. We have already two problematic cases which the original policy didn't consider, that is:

  1. A project which is too small to collect required 25 support but has an ArbCom, and their arbcom appoints Checkusers. (enwikinews case)
  2. A project which has been enough big to collect required 25 support but lacked their Arbcom until some time. Now they have an Arbcom and their CUs are not appointed by that Arbcom. The next CU should/can be elected by the community vote or should their Arbcom rule here now? (dewiki case, and predictably soon of many other wikis)

I think we are better to avoid "relying common sense" here. This policy was intended to be handled strictly, and we have seen what the common sense says are varied from the community to the community. While it doesn't directly concern the crucial part of this policy, say, privacy information handling, we are better to choose a way with the full precaution we can afford. --Aphaia 03:48, 29 January 2008 (UTC)

After reading a bit of the recent discussion, and some of the archived stuff, I think this is what was meant here.
The intent of this part of the policy is to put the bar fairly high (for obvious reasons). There are 2 methods, and whichever has the highest onus is the method a wiki uses. So using the ArbCom route to bypass the 25-vote minimum because it's a small wiki is not kosher. Likewise, the 25 votes method at enwiki (or other large wikis) is a bad joke. I have no good suggestions of what language to put in the policy, and I'm sure there will be some discussion to follow. – Mike.lifeguard | @en.wb 00:52, 9 March 2008 (UTC)
I think that whether or not the project's ArbCom appoints CUs should depend on two factors:
  1. whether or not the project community desired that the ArbCom should handle appointments in place of community elections when they set up the ArbCom, and
  2. whether or not the Foundation has given that ArbCom approval to appoint CUs.
It may be necessary for existing projects with ArbComs to resolve either or both of these points. --bainer (talk) 10:13, 9 March 2008 (UTC)
In light of discussions on CheckUser-l and here, I have "fixed" it to be clearer that the ArbCom needs to be approved by the Foundation to give out CheckUser before the wiki's ArbCom can do that. (I would hope that the Foundation would not approve without community support.) But this needs to be made clearer still, yes.
James F. (talk) 22:37, 10 March 2008 (UTC)

[edit] A Checkuser Question

I wonder if it might help to pop a note here about the question I asked at Talk:Ombudsman_commission...?

Basically, I've been enquiring about some aspects of the privacy policy, and having established that checkusers are free to share username information with whomever they wish, I wondered if other checkusers might be free (from a foundation perspective) to share the information about when a check was run, and maybe by whom?

I'm also happy to talk about why I think this might be a good idea!

thanks,

Privatemusings 04:26, 19 February 2008 (UTC)

[edit] age

This needs to be updated to reflect the amended version passed in JuneGeo.plrd 19:01, 6 March 2008 (UTC)

Actually, for whatever reason, OTRS is excempt from that, although being 16 or over is preferred. Majorly (talk) 22:33, 6 March 2008 (UTC)

[edit] immediate removal of checkuser

The policy currently says that "In case of abusive use of the tool, the Steward or the editor with the CheckUser privilege will immediately have their access removed", yet the rest of the section doesnt indicate how this would occur. Quite the opposite in fact; it does say that a steward cant remove access on their own, and indicates local community consensus is required, which is far from "immediate". How would immediate removal occur? John Vandenberg 11:50, 4 April 2008 (UTC)

I suppose it means that as soon as abuse is discovered, a member of the ArbCom or another checkuser will ask for the bit to be removed. I don't know if checkuser has ever been forcibly removed from anyone, so if it ever did happen, the current wording is certainly confusing. Would it be a good idea for the (other) checkuser to bring up the issue on the checkuser mailing list, and ask for input on the issue? Perhaps with agreement of people there it could be removed. It would be difficult to ask the community, due to the privacy issues concerned. I suppose this also applies to oversight, but the consequences of oversight abuse aren't nearly so bad as those of checkuser. Majorly (talk) 12:48, 4 April 2008 (UTC)
Removal would occur immediately in situations akin to "emergency desysopping" when there is clear abuse happening right now. – Mike.lifeguard | @en.wb 16:23, 22 April 2008 (UTC)

[edit] Appointed by ArbCom or elected?

I have been trying to make sense of the Access to CheckUser section (here), but it gets more obscure every time I read it. There was a big change in November 2007 (here), allowing local projects more say in the matter.

  • Then came the change of 10 March 2008 (here), which first is quite emphatic that "[check]users can be appointed by the Arbitrators only" and then goes on to "On a wiki ... where the community prefers independent elections, ..." negating that strict requirement. This does not make sense.
  • It is not made clear what exactly is "an Arbitration Committee (ArbCom) which has been approved by the Foundation to assign CheckUser status...". Is there a list of Arbitration Committees approved by the Foundation for this purpose, or is this automatic (as per this list)?
  • The English Wikipedia has three checkusers appointed by the "Office". This, too, is mystifying as the Access section says nothing about them. Why are they there? Does the "Office" have carte blanche to appoint checkusers in any project they feel like? As many as they like? Etc?

- Brya 12:19, 22 April 2008 (UTC)

Will try to answer this; note that I'm just answering as I understand it, and I could be wrong. In order:
"where the community prefers independent elections"
I always understood this to mean "where the approved Arbitration Committee determines that the community would prefer to elect individuals directly; they remain responsible for making sure that the policy is followed and raising concerns to the Foundation if appropriate".
Approved Arbitration Committees
Is it automatic? No. Is there a list? No. Should there be? Yes. But I can't write this list off the top of my head; I'd recommend asking the Volunteer Co-ordinator. (Sorry, Cary! ;-))
Foundation-mandated individuals
Can the Foundation make changes its software as it wishes? Yes. Does this apply to all parts of its software? Yes. Is there a limit to this? No. (That is, the Office as part of the Foundation can do what it likes.)
Hope this is helpful. We (the CheckUsers) are currently discussing the issue to see if we need to clarify the policy further. Also, we might full-protect the page, given the nature of its content.
James F. (talk) 08:21, 26 April 2008 (UTC)
Basically agreeing with Jdforrester I certainly think this page should be protecting once it reads in the "agreed" way ( of course how long that will take is another matter....:)) --Herby talk thyme 08:40, 26 April 2008 (UTC)

The Foundation can traditionally give additional rights to people it chooses; there is at times WMF appointed sysop access, checkuser access, developer access and so on. These are all outside the scope of simple "editing access". As with many traditional matters on the wikis, it's a balance of having the right, and not excessively using the right. Basically if the WMF feels it would be useful, and appropriate/necessary to give a user a right on a wiki, they can, but they don't do it that way often. I think. FT2 (Talk | email) 12:23, 26 April 2008 (UTC)

Thank you. I do feel that the page should mention that the WMF has unlimited powers to appoint checkusers. This need not be more than a few words, just enough to be clear about it. - Brya 07:18, 27 April 2008 (UTC)

[edit] Better process?

As for "appointed or elected", this would probably need more discussion. Clearly a well-agreed communal decision is fine, but as drafted this doesn't yet work for me. What I'd rather see at WMF level would be something that ensures a high quality standard if communal decision-making is decided upon. Quick outline concept in case it's useful:

"On wikis with an ArbCom, Checkuser is normally appointed by that ArbCom following internal deliberations and any process that the Committee may determine. Alternatively, a wiki with an ArbCom may decide to communally appoint its Checkusers. A consultative process is required to agree this:
  • Policy - A policy must be drafted which:
  • Must faithfully reflect WMF privacy and checkuser policies and affirm their primacy.
  • Must cover how checkusers are to be appointed and removed. It should make clear that usually CheckUser should not be granted unless there is an actual need for more CheckUsers. (minimize access to IP data: checkusers don't get appointed "just because they'd be good" or popularity, but only if there's actual need for more.)
  • Must also ensure that significant changes affecting appointment and usage, require reasonable length discussion and clear consensus on the talk page. Typically this would cover nominations/requests, appointment, removal, usage and accountability. (ensures key issues get discussed first not just "added to policy")
  • Additionally it should cover basic checkuser criteria (trust, necessity, technical competence) and may cover other processes or norms or information as needed.
  • Consultation process - The consultation process may include measures to ensure a high quality decision, including a minimum standard for suffrage, a limit on comment length, agreement on the process and structure of consultation, and a decision on who shall ratify it at the close or (if needed) for interim stages. The consultation may be single- or multi-stage, and will often involve discussion and (recommended) a "straw poll" to resolve any issues before a formal vote is taken.
  • Consensus - The community must be consulted on the proposed policy, which must be widely advertized and discussed beforehand on the wiki and noted on 'meta', and a high standard for adoption obtained. A typical suggested standard is 150 - 400 valid votes (depending on the size of the wiki) and somewhere in the range of 70% - 90% support (or equivalent). For smaller wikis, a lower number of votes may be agreed by consensus.
  • ArbCom - The ArbCom should be consulted as needed, and at critical junctures, for a view whether WMF policy is being correctly complied with, and any feedback to the community.
  • Ratification - If WMF policy has been complied with, the decision will be ratified and become the communal decision."

A quick stab at "what a WMF policy section on this might look like". FT2 (Talk | email) 13:06, 26 April 2008 (UTC)

An attempt to phrase this more user friendly:

"On wikis with an ArbCom, a Checkuser is normally appointed by that ArbCom, following a procedure set for or by the ArbCom, as the case may be. Alternatively, a wiki with an ArbCom may choose to appoint (all, or some) Checkusers by a community decision, but only if a policy has been adopted.
  • Requirements:
  1. The policy must faithfully reflect WMF privacy and checkuser policies and affirm their primacy. It should make clear that usually additional CheckUsers should not be appointed unless there is an actual need for more CheckUsers. It should cover basic checkuser criteria (trust, necessity, technical competence) and may cover other processes or norms or information as needed. (Reflect WMF policy. Also minimize access to IP data: checkusers don't get appointed "just because they'd be good" or popularity, but only if there's actual need for more.)
  2. The policy must cover how checkusers are to be appointed and removed.
  3. The policy must ensure reasonable discussion, publicity, and time frames, for proposed changes that will significantly affect nominations/requests, appointment, removal, usage, and accountability. (ensures key issues get discussed first not just "added to policy")
  • Formal adoption of this policy must go through the following steps:
  1. Consultation process - The draft of this policy must be up for discussion by the community. The consultation process may include measures to ensure a high quality decision, including a minimum standard for suffrage, a limit on comment length, agreement on the process and structure of consultation, and a decision on who shall ratify it at the close or (if needed) for interim stages. The consultation may be single- or multi-stage, and will often involve discussion and (recommended) a "straw poll" to resolve any issues before a formal vote is taken.
  2. Consensus - The community must be consulted on the proposed policy, which must be widely advertized and discussed beforehand on the wiki and noted on 'meta', and a high standard for adoption obtained. A typical suggested standard is 100 - 400 valid votes (depending on the size of the wiki) and somewhere in the range of 70% - 90% support (or equivalent). For smaller wikis, a lower number of votes may be agreed by consensus.
  3. ArbCom - The ArbCom should be consulted as needed, and at critical junctures, for a view whether WMF policy is being correctly complied with, and any feedback to the community.
  4. Ratification - If WMF policy has been complied with, the decision will be ratified and become the community decision."

I am not sure if this addresses all the issues. Also, by my standards it looks still too wordy and too inexact (two things which tend to go hand in hand) - Brya 07:53, 27 April 2008 (UTC)

Two minor edits - the full rationale for the first item (better explanation is being discussed), and 70 - 90% (realistically it'll almost always be 75% or 80%, maybe 85, but indicating "somewhere between 70 - 90" lets the community choose fully) FT2 (Talk | email) 02:44, 1 May 2008 (UTC)


[edit] Age Restriction

The age restriction is no longer a firm requirement as of 2 June 2007. The policy needs to be changed to reflect the update. Geo.plrd 06:21, 27 April 2008 (UTC)

You seem to misunderstand. It is no firm requirement only for the chosen role, in the current context, OTRS volunteers. Checkuser is still very strictly restricted by that requirement. --Aphaia 07:53, 27 April 2008 (UTC)
Aphaia is correct, see foundation:Access to nonpublic data policy for more information. Cbrown1023 talk 14:29, 27 April 2008 (UTC)
which may include proof that such user is at least 18 and explicitly over the age at which they are capable to act without the consent of their parent in the jurisdiction in which they reside. This is not a firm requirement. Geo.plrd 02:50, 28 April 2008 (UTC)
That's complete nitpicking, even if it is not a firm requirement from that specific policy, it is one in practice. Cbrown1023 talk 21:20, 28 April 2008 (UTC)
Notice, "and", not "or"...... and that "proof of age" may be asked does not imply the age limit will be waived..... FT2 (Talk | email) 02:22, 1 May 2008 (UTC)

[edit] CheckUser vs. SUL

It seems to me that SUL-enabled accounts will have their IP addresses visible to checkusers of any wikimedia project.

  1. This should apply at least as soon as they first visit a project, when they have their accounts created automatically. Does this also apply to subsequent visits, even if the users performed login on another project?
  2. IIUC, checkuser logs only last a limited amount of time. However, can checkusers see the IP address that registered the account (either automatically or manually) forever, independent of how long the checkuser logs last?

Balabiot 08:39, 2 June 2008 (UTC)

I don't see why there's any difference between merged and non-merged accounts from a CU standpoint. What's your basis for that?  – Mike.lifeguard | @en.wb 11:39, 2 June 2008 (UTC)
I'm just asking. My point is that while accessing a project for the first time definitely creates an association between you and your IP in the check-user logs, it's not clear to me whether accessing a project subsequently constitutes a login action. Since check-user logs cannot be written (for performance reason) on every page visit, what actions can (for example) en.wiki checkusers see about me? That I just logged into meta? That I just logged into it.wiki? Neither of these as long as I don't visit en.wiki? Neither of these as long as I don't edit en.wiki? Neither of these, they can only see me if I explicitly log into en.wiki? I hope this clarifies my first question.
Regarding the second, I was wondering if the specific IP address/user account used for registration is special and remains for more time in the checkuser logs (similar to how bureaucrats creating accounts have their actions logged forever). In this case, does the first IP I used to visit a project (thus creating a SUL login there) remain forever? Balabiot 04:37, 3 June 2008 (UTC)
CheckUsers on a wiki can see only data for that wiki - it is not a global permission. The data a CU at enwiki can see is just actions at enwiki. All CU data is treated the same I think, so that would be purged along with other data.  – Mike.lifeguard | @en.wb 11:30, 3 June 2008 (UTC)
Yes, that I know. But which actions? Is visiting a page on en.wiki with a SUL login considered an action? logging out (even if I logged in from a different wiki)? editing? Balabiot 12:12, 3 June 2008 (UTC)
Checkusers can only see what is recorded in recent changes, so viewing pages is not recorded, but editing pages yes. The "account created automatically" log entry isn't anymore recorded in recent changes, so the IP address of that action is not accessible to checkusers. iAlex 12:25, 3 June 2008 (UTC)
Checkusers can see your IP if you have logged in and not edited... i tried it several times and the usual dipshits nailed the account and the IP even if it didn't edit anything... TIV 22:21, 11 July 2008 (UTC)

[edit] Selection method

Crossposted from [1]; discussing this change.

The change was the result of a long discussion on the checkuser-L mailing list. The problem, essentially, is that there is no single system, and seems to be no easy way to describe any of the current systems. During the discussion, no one from the Foundation weighed in. For example, enwiki has an Arbcom, which appoints checkusers. dewiki has an arbcom, but checkusers are elected. eswiki (if I recall correctly) has one CU elected by the community before the creation of their arbcom and one CU appointed by the arbcom, with no clear decision (and some controversy) about whether future CUs will be elected or appointed. There was also concern on the list about the recent attempts to establish an arbcom in order to appoint some people as CUs who had failed to be elected (I think it was en wikiquote but I would have to look it up to make sure). I think the requirement of having a minimum number of votes and 75-80% consensus is a good idea, especially if it has been established as a precedence. But that language was being used by some people on enwiki to justify creating an election mechanism that would be independent of Arbcom. So that's the problem. Perhaps the confusion could be addressed by saying, "If a wiki currently has a mechanism to appoint or elect checkusers, future checkusers must be selected using the same mechanism. If a wiki does not have checkusers, the 30 vote/80% consensus rule applies. I confess I have not given this much though recently but does that seem reasonable? Thatcher 17:22, 10 July 2008 (UTC)

Sorry, private list (checkuser-l) is not the place for talking about policy changing. So, please, start to talk here. --Millosh 18:58, 10 July 2008 (UTC)
Actually, there is considerable discussion above that was never implemented, and in March JamesF made changes based on checkuser-L without objection. Perhaps you should revert to Bastique's version. Thatcher 19:57, 10 July 2008 (UTC)
As I said at CU list, this is not your mistake (at least, not 100%). Practice of talking at private lists and changing policies should be changed. Policies are public and it should be publicly discussed about them. At the other side: Yes, of course, CUs are the most introduced contributors into the CU issues, so their word should have a significant weight. --Millosh 20:12, 10 July 2008 (UTC)
The only problem with this policy change is that it affected small wikis and that it is now possible that someone becomes CU with 7:1 score. If you change that, I don't have any objections to your changes. (However, others should say what do they think, too.) --Millosh 20:12, 10 July 2008 (UTC)

Why shouldn't a normal user see if their account has been checked? TIV 22:18, 11 July 2008 (UTC)

There is some control measures already installed. For example, on fr wiki, a request page lists all the checks details (request, cu decision to make or not the verification, check result). Then, any checkuser have access to others checkusers log. Finally, there is an ombudsman commission to deal with complaints. --Dereckson 04:15, 14 July 2008 (UTC)

[edit] Question

Does the required support of 25 people mean that a community could block an appointment to checkuser that the arbcom wishes to make by calling a community vote and failing to come up with this number of support votes? Can a community call for the removal of someone who already has access without going through the arbcom? (the logical answer IMO would be that if the community fails to support the arbcom that means the community does not have confidence in the arbcom to select checkusers, and it reverts to the no-arbcom scenario) —Random832 19:51, 29 August 2008 (UTC)

I think there's two answers to this:
On most projects with Foundation-approved arbcoms, the correct course of action would be to petition the arbcom to overturn its decision regarding the potential checkuser, though other solutions may include holding a vote of no-confidence in the current arbcom, or at the extreme, hold a vote to abolish the current arbcom and nullify its current actions.
On the English Wikipedia, there is ongoing controversy regarding the relationship between its arbcom and the community: The best solution would be to petition arbcom there to reverse its decision and request that they state whether the current members of arbcom there believe that it can be overruled by the community regarding these sorts of situations.
There is no current policy allowing stewards to overrule a local arbcom regarding checkuser access except in cases of the user failing to provide sufficient identity to the Foundation, nor is any branch of Meta willing to take on such a task as to provide oversight of local consensus: Projects are requested and required to determine that themselves.
While the Board of Trustees has the authority to perform such actions as revoking permissions, it is highly unlikely that they will do so, and unless there is an extreme and urgent need for Board intervention, requesting such intervention is highly discouraged.
I hope this helps to resolve your situation. Kylu 20:23, 29 August 2008 (UTC)
It was a purely theoretical question - though, who exactly judges the vote when there is no local arbcom? —Random832 06:30, 30 August 2008 (UTC)
The local community judges the vote. The stewards only intervene when it's clear that the requirements haven't been met or someone brings up suspicion of vote stacking/sockpuppetry to them. If the outcome isn't absolutely clear, stewards will not act. Kylu 18:00, 30 August 2008 (UTC)

[edit] Contradiction

This policy contains a serious contradiction regarding the appointment of CheckUsers. It states (emphasis added):

“ On wikis with an Arbitration Committee (ArbCom) whose members have been elected with the support of at least 25-30 members of the local community, CheckUsers can be appointed by the Arbitrators only. ”

Yet immediately follows with (emphasis added):

“ On a wiki without an Arbitration Committee that meets the criterion above, or where the community prefers independent elections, two options are possible ”

Which is it? Can CheckUsers only be appointed by qualifying ArbComs (where applicable) or can CheckUsers be appointed by election when the community prefers indepedent elections? Vassyana 11:45, 25 November 2008 (UTC)

Let's face it. This policy is completely and utterly stupid. It is ignored by English Wikipedia, whose CheckUsers can do whatever the hell they want, without facing any consequences for misuse - same for Oversight.
I tried, earlier this year, to implement a Requests for checkusership process on English Wikipedia - it failed spectacularly, when ArbCom found out about it (and a Bureaucrat/Arbitrator closed my own nomination, in a massive COI). See the page for the details, and the talk page (especially the first archive), where it was shot down by Arbitrators, unsurprisingly, who hated the idea of the community taking their so-called right away from them. Majorly talk 12:45, 25 November 2008 (UTC)
:-( FloNight 19:54, 25 November 2008 (UTC)


[edit] Combining CheckUser and Oversight flags

CheckUser and Oversight rights both involve handling private personal data, though OS is usually used to hide something for the future, and CU is used to unhide something from the past... What do people think about combining these rights into a single flag? I'm not sure what one would call it; oversight of [hidden revisions and hidden IP addresses]? -- sj | help translate |+ 21:09, 5 April 2009 (UTC)

I'm in favour of the idea. No clear name springs to mind though. Any cons to this? ++Lar: t/c 15:33, 12 April 2009 (UTC)
"privateers"? :P Cbrown1023 talk 22:15, 12 April 2009 (UTC)
Agreed that this is a good idea. Cirt (talk) 22:23, 2 October 2009 (UTC)
Retrieved from "http://meta.wikimedia.org/wiki/Talk:CheckUser_policy"