Talk:CheckUser policy/Archive 4

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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)

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)

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)

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)

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)

I agree with Herby that this should be handled case by case. "10 edits or actions in a year" seems like a reasonable low bar for absolute activity. However each wiki should be able to set their own standard for activity, and to remove inactive CUs and elect new ones. The default global standard should probably be "edits and logged actions" not just logged actions, since there may be little cause to use the tool. –SJ · talk | translate 13:11, 2 March 2011 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

I also find it strange and I wonder why this was put down like this in the first place. We have decided on plwiki that ArbCom has nothing to do with the CheckUser powers at all. Actually (except for the one short exception, but even then no CU checks were made by the CheckUser elected while sitting in ArbCom) we maintain separation between ArbCom and CheckUsers. Personally (not the community opinion) I find this separation of powers very good - ArbCom should ask for CheckUser data just like any other user, even via public request page (as mandated by few wikis). Nlwiki goes even further - checkusers are not even sysops. Separating ArbCom from CheckUsers adds additional checks and balances, since it limits the need to "dig for evidence" or explain the issue deeper than just a straight sockpuppet check.  « Saper // @talk »  20:35, 6 March 2011 (UTC)

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)

While I see benefit in automatically granting (full or partial) oversight flags to a checkuser, I am less persuaded that granting checkuser flags to an oversighter should be automatic. The skill set for oversight mainly focuses on solid understanding of the privacy policy and demonstrated decision-making and communication skills; checkusers also require additional technical skills and knowledge that simply aren't necessary for one to be a good oversighter. As well, on enwiki there is a significant demand around the clock for oversighters, whose job is more time-sensitive; thus, we have extended this permission to a larger group than we have the checkuser permission. There are multiple overlaps, of course. Risker 20:42, 9 December 2009 (UTC)

Maybe this is a stupid question, but.....

At what wikis do these CheckUser policies actually apply? I ask because I know Conservapedia does not abide by these rules and I was wondering if anything can be done. It is common on Conservapedia for users to be blocked before they even make an edit because the checkusers run a check on every new account. Can anything be done about this or does Conservapedia not fall under these rules? Thanks. Keegscee 03:57, 9 December 2009 (UTC)

This policy only applies to wikis listed on Special:SiteMatrix. Conservapedia is not owned or controlled by the Wikimedia Foundation and as such, the WMF cannot do anything regarding their usage of Checkuser. MBisanz ^talk 04:01, 9 December 2009 (UTC)

Additions to our privacy policy subsection on the meta Checkuser page

Per my discussions with Risker here, I wished to add the following line to our privacy policy subsection on the Checkuser page.

• Checkusers can, in the interests of the project and for the purposes of protecting Wikipedia against actual and potential disruption and abuse, maintain a personal record or backup of checkuser findings.

This will allow users to know that apart from the three-month standard maintenance on our logs, ip and usage information could be stored by Checkusers otherwise too for protecting our project's interests. Thanks♪ ♫ Wifione ♫ ♪ 06:43, 30 October 2010 (UTC)

Not all WMF projects are Wikipedias. --Pi zero 13:50, 30 October 2010 (UTC)

Sure. Maintaining a personal record or backup of checkuser finding is obviously useful and necessary in various situations, since some logs may be expired from the system before the investigation is completed or sockpuppets of banned users appear in the distant future. Ruy Pugliesi^◥ 14:54, 30 October 2010 (UTC)

Should be made clear. Fred Bauder 18:24, 30 October 2010 (UTC)

I think this might be better off as a silent policy. Making this explicit will likely lead to the assumption that all Checkusers not only may, but do, maintain such information; there's a lot of fuzzy-edged privacy stuff in there that would get even more confusing if official policy permitted (read: encouraged) Checkusers to maintain private data. --Jpgordon 19:38, 30 October 2010 (UTC)

At least the original wording at Wikipedia is not being proposed, but this states what CheckUsers already know. The checkuser-l mailing list archives go back to the beginning of 2006 and people's email clients routinely archive messages received. Whether explicitly defined in policy or not and despite a three month expiration window on data, records on people and IPs that have gained attention go back years. Adrignola 20:40, 30 October 2010 (UTC)

The original wording is strange, as it includes admins and editors as well. People can obtain IPs from a raft of sources, including IRC, and IP edits being signed by a logged in user. We can't force people to forget this information; all we can do is ensure that it is not acceptable to repost this information publicly on our projects.

I don't mind if the checkuser policy informs people that checkusers may retain records for longer than the three month period, but I agree with Jpgordon that this is hairy area. I don't like the proposed wording, as it starts to lock down when we are allowed to keep records. Who is going to judge 'potential disruption'? In short, checkusers are appointed to make good judgements, there is a WMF ombudsmen to review misuse and dubious cases, and there is an audit subcommittee on English Wikipedia. John Vandenberg 00:27, 31 October 2010 (UTC)

I am in agreement with John and Josh here. It is already common knowledge that the mailing lists are archived, if individual checkusers wish to keep copies of their records, there is nothing the foundation can do to prevent that outside of subpoenaing their computers. Many other checkusers do not keep records. What we do know is that currently the log-in records on projetcs are set to be scraped after three months. That is a reasonable thing to have in the policy—forcing CUs to keep or not keep records is not. Our CUs are supposed to the editors with the highest degree of "clue" in the projects; we trust them or we don't. -- Avi 00:52, 31 October 2010 (UTC)

I agree with Avraham and John. Ruy Pugliesi^◥ 13:54, 31 October 2010 (UTC)

I do not consider the proposed privacy policy necessary. I see nothing wrong for those who keep a personal record or backup of checkuser findings, as long as they do not leak sensitive information improperly. As I do not this kind of record or backup in my computer, I abstain from supporting or opposing the proposal here.Jusjih 22:12, 31 October 2010 (UTC)

I do not see any value in the additional statement, especially as the general communication means between checkusers is such a record, and would be self-evident a record, whether it is used for forensic analysis or otherwise. A variation to John's statement that may be useful is the clean statement "historical records of use and abuse exist and may be used for the purposes of protecting Wikimedia sites against actual and potential disruption and abuse." billinghurst sDrewth 11:12, 1 November 2010 (UTC)

As a CheckUser with almost 2 years of experience on plwiki I personally don't like keeping logs beyond the usual span of the CheckUser data. We don't have a whole lot of long-term persistent sockpuppeting as other wikis do, so this was not necessary for me and I am a pretty active CU. The point is why I don't like this is that limited availability of the CU information is there for a reason, and this reason is still valid. CheckUsers may use information available in the CheckUser log as a hint on previous, even very old checks - sometimes it provides the needed information (i.e. old IP addresses vs. username). I don't like doing this either. Checkuser-l archives are another method of evading limited data retention period. Some persistent sockpuppeteers come often enough to compare their data with their recent sockpuppet, not with the original account (usually blocked long ago for a long time). And, if somebody is blocked for, say 2 years, and comes back silently after a year and makes no visible harm except for being a sockpuppet of the old blocked account - so be it. That's actually a problem with computers - people do forget old stuff and relations have a chance to improve over time, computers usually don't. I agree that this is an issue for some wikis (especially enwiki) but this should be addressed in the original data retention policy. Maybe the data retention period should be longer on enwiki? I am pretty comfortable with a fact that after 2 or 3 years sockpupeteering goes forgotten. It's bad editing that we should go after, and not sockpuppets. Blocking socks is just an additional method to keep block enforceable. But of course this is a problem for users blocked forever, and we have very few of them on plwiki.  « Saper // @talk »  20:16, 6 March 2011 (UTC)

Random user checks

Due to massive sockpuppeting in the hebrew wikipedia, it was suggested by a user that the community should allow the local checkusers to do random IP checks for users, even if no evidence for sockpuppeting is present, in order to prevent future sockpuppeting. Is such a suggestion consistent with the global checkuser policy? לירן 11:41, 5 March 2011 (UTC)

Hi לירן, according to the policy "there must be a valid reason to check a user". This means that every check should be individually motivated and justified by some observed behaviour of that user, and that imho is not compatible with doing random checks. Regards, --Sir48 12:20, 5 March 2011 (UTC)

The policy states: "There must be a valid reason to check a user." So, in my opinion, random checks is not allowed as it violates the policy. Usually, CU is not used for fishing. Pmlineditor (t · c · l) 12:59, 5 March 2011 (UTC)

Random user checks are not permitted, abuse could result in action, certainly I'd consider removing checkuser from someone who was using it so abusively after being asked to stop, and then refer to case to the locals or ombudsman if privacy policy violations had also occurred. Also, do keep in mind it would violate CheckUser is not for fishing. As Sir48 has said, each use of checkuser must be able to be justified on its own merits. If hewiki needs help in how to do checks on known socker's and their ranges that's one thing, and we'd all be willing to help (there are tips and tricks that can be used instead), but random checks without a good justification would be bad. Remember that CUs should be done to back up other evidence, not to look for prima facie evidence on its own. fr33kman 13:30, 5 March 2011 (UTC)

it is done in meta. for whatever reason meta finds it valid to check users who voted, such should be the case in the hebrew wikipedia: random checks of users who used the voting privilages. 87.69.188.174 18:19, 5 March 2011 (UTC)

Could you please clarify? Not all of us can read Hebrew, so we can't really understand the link to pointed to. Regards, Pmlineditor (t · c · l) 18:26, 5 March 2011 (UTC)

I think he meant to refer to this link: [2]/ אני ואתה 15:42, 6 March 2011 (UTC)

indeed. my mistake. my point is that making sure no puppets are used in out official voted is a "valid reason to check a user" -- just like it is done here. do you not agree? 87.69.188.174 20:46, 6 March 2011 (UTC)

Added schools and businesses ...

as acceptable circumstances of cases where release of information may be allowed. Schools and businesses can validly be seen as ISPs for their users and are usually responsible in some fashion for the use of their networks. Revert or discuss if disageee. :) fr33kman 14:17, 5 March 2011 (UTC)

As this pertains to any owner of the network address block (and this can be virtually any entity), I have copied over the actual wording from the 2008 privacy policy, which IMHO addresses this problem better, listing ISPs only as example.  « Saper // @talk »  20:24, 6 March 2011 (UTC)

Makes better sense!Cheers :) fr33kman 20:47, 6 March 2011 (UTC)

Removal for inactivity 2

Any user account with CheckUser status that is inactive for more than a year will have their CheckUser access removed.

I find this statement very incomplete. When a user account is considered inactive? No checks in a year? No activity in a year? No checks and no activity in a year? etc.

I already requested clarification from the Board, however one of its members have told me that this policy is not governed by them so I'm putting this here for consideration.

Personally I've always interpreted that paragraph in this way: no edits and no checks (both) in a full year.

Comments welcome as well other proposals.

Regards, -- Dferg ^{☎ talk} 14:31, 6 March 2011 (UTC)

On plwiki we interpret this as no checks only. I have requested one just a moment ago, as this was with the previous request, although the user had some edits during the preceding year (contributions). The older case the user was inactive as CU for 1 year and 3 months and didn't edit for the last 3 months. All of those users are still with us again (after some periods of inactivity perhaps). Our community somehow got used to a very quick response from checkusers (it's usually almost immediate), and it seems like there is quite a bit of disconcern when one request recently need to wait for a week. We are thinking about electing one or two more CheckUsers but growing number of CheckUsers beyond 7-8 for the wiki of this size might seem an overkill. This is a very special area of work and it's very different from editing or even typical sysop tasks. Losing interest in this kind of work doesn't have to impact other activities - in fact, some inactive CheckUsers seem to be quite busy editors. For now, I think no checks only policy is enough for us, but I would like to hear about more experience in other wikis, especially larger or smaller than us. Speaking for myself only, during extremely real-life busy times (like organizing last year's Wikimania) I reduced my Wiki activity almost exclusively to CheckUsers tasks, but others mileage may vary.  « Saper // @talk »  19:45, 6 March 2011 (UTC)

I've always read it as "inactive as a checkuser", but found the policy to be incomplete. The last time I found a user that was inactive as a checkuser, I asked him to resign himself, so that we didn't need to clarify it because of his case... Laaknor 19:51, 6 March 2011 (UTC)

I too have interpreted this as inactive with their functionary (CheckUser or oversight) permissions. Certainly on enwiki the Arbitration Committee has occasionally removed active editors who were inactive with their functionary rights. PeterSymonds 20:07, 6 March 2011 (UTC)

Having said above, however, enforcing this policy among users makes them upset, which is not a good thing.  « Saper // @talk »  23:20, 6 March 2011 (UTC)

There are certain expectations for activity at en.wikibooks, where one year of inactivity will result in desysopping. While this thread discusses CheckUsers, at en.wikibooks they are tied to each other. Local policies require CheckUsers to be administrators first. Part of the definition of inactivity as it applies to administrators is the use of administrative tools. I quote: "Administrators who are not using privileges, those privileges provided by the community due to the user's knowledge and activity, do not need to continue having them. Administrators do not have a 'lifetime membership' and are expected to continually use their tools for the good of the community." As a local bureaucrat, I then interpret that to extend to CheckUsers in the same manner; namely, if they are not using the tools for a year, they face removal of the tools just as an admin would. – Adrignola talk 23:22, 6 March 2011 (UTC)

My question is what are is trying to be achieved with a clarification of the rule? Are you wanting a hard and fast rule to make it easier to enforce, or because you think that people are not pulling their weight, or that there are people disappearing and we have a security hole because of it? Let us set the context and that allows a simple rule, that enables governance with good guidelines and principles. At this point in time I like the rule as it is, and feel that there needs to be the flexibility of the enforcement, and stewards and/or communities can act as the overarching governance.

Issues that I see are

• Difference in activities between sites. A larger site may remove for inactivity as a checkuser for non-use of the tool, though smaller sites may not have the necessity, and we surely do not want to be encouraging activity in CheckUser tool solely to remain compliant to a use-based rule.
• Requirement for a minimum of two checkusers. If sites have the minimum of two, and remove one then you have removed that wikis capacity. So if you are going to enforce such a rule the implications where one may do checkuse, and the other does audit, then we have issues.
• Existing definitions of inactivity and confirmations. Some sites (like enWS which I represent) have confirmation discussions (at enWS that is annually). I would see that such a community conversation should be sufficient to continue the endorsement of retention of a tool whether the tool is being used or not, especially if they already have a consideration for what is inactive (enWS inactive)

Possible solution. Request communities to explicitly set their definition of inactivity, and where they do not set their definition then a model WMF definition applies. If a community set definition seems that seems excessive, then let us have that discussion. So in practice this could be (made-up examples only) inactivity equals

• WMF default (for stewards to apply) is no use of admin tools (easy to check)
• enWP community decision is no use of checkuser tools
• enWS community decision is based upon passing administrator confirmation where there is already a definition of activity.

So this gives a governing and achievable framework for stewards, and allows communities where there is the activity and the support to define their (in)activity criteria. To what a WMF model would be, let the stewards decide and tell the community, and let us not have a bunfight to determine. If a particular community doesn't like it, they have the opportunity to set theirs and not rely on the default. billinghurst sDrewth 01:24, 7 March 2011 (UTC)

Why isn't this up to the projects that have checkusers? I know EnWiki ArbCom is actively discussing this now. -- Avi 02:15, 7 March 2011 (UTC)

indeed, big enough to have CUs, big enough to have a policy :) fr33kman 02:47, 7 March 2011 (UTC)

Persian Wikipedia doesn't have a policy specifically for Checkusers, but the existing policy (which was created to deal with inactive sysops) considers one year of "no edits" as the requirement for removal of access. Huji 04:51, 7 March 2011 (UTC)

Since inactive ru.wiki CU usually ask on meta to remove a flag on their own, we never had a so long time of inactivity, --DR 07:10, 7 March 2011 (UTC)

To clarify, stewards are supposed to implement community consensus on projects too small to have local "functionaries" as it were; subject to wikimedia foundation guidelines (foundation trumps local wiki, obviously). If the wikimedia foundation or global community has agreed to certain preconditions to various bits (minimum of 2 per project, must be identified and over 18, etc.) we must enforce that. Other than that, as freekman put it, if a community is large enough to have these kinds of editors, it is large enough to control the access (subject to adherence to foundation requirements, which is a precondition to each and every project's existence). -- Avi 11:51, 7 March 2011 (UTC)

I have a very simple view on this and related issues. If you are not active why the hell do you need these (or other tools). They are not badges of office, they are tools to be used. If you are not using them to help the community you do not need them. --Herby ^{talk thyme} 17:08, 8 March 2011 (UTC)

It should not be forgotten that "orphaned accounts" also pose a risk to the projects. A lot has been written about this issue - some examples are:

• Internetnews.com: Orphaned User Accounts Run Wild in Enterprises (May 2008)
• Inc. Technology: Downsizing Dilemma: Dealing with Orphaned Accounts (February 2009)
• Campus Technology: Orphaned Accounts Are a Growing Security Concern, Study Says (May 2008)

--Sir48 23:21, 8 March 2011 (UTC)

Section on privacy policy

The italized sentences about release of information in the section on Privacy policy differs somewhat from the stipulations in the Privacy police approved by the board in October 2008. Although the section links there, the wording is probably left over from some earlier version and ought to be updated and identical. Rgds --Sir48 17:28, 6 March 2011 (UTC)

I have boldly copied point 5 about the information release to ISPs from the current WMF policy, see also above. This is because it is just a better wording, since we are releasing information to the owners of allocated IP address blocks, irrelevant who they are (ISPs, education, government, private persons, whatever). What's left is an interesting issue of point 3. The current version of CheckUser policy says:

data (...) may be released by the system administrators or users with CheckUser access (...) 3. To the chair of Wikimedia Foundation, his legal counsel, or his designee, when necessary for investigation of abuse complaints;

, while the newer WMF Privacy Policy says

data (...) may be released by Wikimedia volunteers or staff (..) 3. When necessary for investigation of abuse complaints,

It looks like the board has decided that privacy policy should be about relations of the Foundation (as the data owner) vs. the external world, and checkusers (or people with OTRS access etc.) are treated as Foundation agents of some kind (with regards to this policy of course). This makes and Foundation employee equally empowered to access or request data from the checkusers. I am not going to discuss this issue whether it's good or not. But CheckUser policy, as it affects primarily Wikimedia volunteers, might be more specific in clarifying relations between Foundation and the CheckUsers. I think it is okay to limit number of people who can talk to CheckUsers and that CUs should know exactly who might talk to them in the name of the Foundation. This limits the possibility of some social engineering or plain abuse. I think that this will be very limited, as the Foundation might actually obtain all data internally, but I imagine that Foundation employees might need to work together with local checkusers in cases of dealing with some abuse complaints or court cases outside of the United States, where knowledge of the local community/policies/languages/law might be necessary and even hiring local lawyers by the Foundation might not always fully resolve the issue. My current suggestion would be to copy the WMF policy verbatim (as this is supposed to be an actual quote), but we might consider adding additional provision to clearly appoint people that might contact volunteers with requests. This can be Foundation CEO or legal counsel, designated DMCA agents, but for example, it should be none of the Trustees or Foundation contractors.  « Saper // @talk »  20:56, 6 March 2011 (UTC)

I find that point 3 should also be copied. It covers other potential situations than interaction between Foundation staff and CUs. If additions regarding CU are needed, they should be described - and discussed - separately from the citation. Rgds --Sir48 22:45, 6 March 2011 (UTC)

 Done, copied verbatim the whole paragraph again.  « Saper // talk »  20:55, 12 March 2011 (UTC)

Unblock id

kindly view the history of Omer123hussain, for my every edit i took responciblity and discussed it by my own id, i never used any false id's to support my edits to work on WP. I understand, when i discussed with my friends about my work on WP, may be any of them might have created account and try to support my work/ or may be someone delibrately created the account to prove it my false id and stop me from working. but its not true that i used other (false) accounts to support my edit. for my every edit since begning i used my own id, though i am only one month new on WP, i did my best to follow WP standards, what ever i was adviced by the administrators and senior regular editors i followed those WP policies. though i agree may be some time i did mistakes un-intentionaly, but i never used any false id to support my work. Kindly unblock my id. Kindly advice? --86.96.226.14 04:16, 15 May 2011 (UTC)

Page could do with some archiving

It may be worthwhile having a level of (slow) automated archiving. It would seem that 2008 conversations would be well to be but to bed. (my opinion only) billinghurst sDrewth 01:32, 7 March 2011 (UTC)

Well, I actually read almost thewhole page today, since the issue of "user inactivity", adjusting policy to 2008 privacy policy changes as well as issues pertaining checkuser appointment on English Wikipedia are still relevant....  « Saper // @talk »  03:11, 7 March 2011 (UTC)

I've cleaned up the heading code (subpage created) and ordered MiszaBot to archive threads older than 60 days in the the new /Archive 4 subpage. Max. size of the archives: 100K. Thanks. —Marco Aurelio (Nihil Prius Fide) 12:19, 29 December 2011 (UTC)