Wikipedia talk:Arbitration Committee/Noticeboard/Archive 39

Original announcement

@Euryalus, Newyorkbrad, Doug Weller, DGG, and DeltaQuad: Since you were arbitrators when Alex resigned, I thought it was appropriate to ping you to this discussion Worm^TT(talk) 19:14, 6 February 2019 (UTC)

• I imagine this is regarding Alex's running for Steward on Meta. My suspicion is that you guys are going to get yelled at for not disclosing this earlier by 50% of the people here, and are going to get yelled at for disclosing it in the middle of the Steward election by the other 50%. So before that happens, just wanted to sneak in a comment first that I appreciate both the initial discretion, and this timely statement now. --Floquenbeam (talk) 19:19, 6 February 2019 (UTC)
  • Yes, I was just thinking the same thing. Bishonen | talk 19:23, 6 February 2019 (UTC).

Same, and I'll also voice and add my appreciation to ArbCom for choosing to disclose this information publicly. All drama and whatever aside: I believe that transparency, by principle, is important; it's a big part of what makes this encyclopedia open and free, as well as part of the reason why it's so popular and widely-used world-wide. ~Oshwah~^{(talk) (contribs)} 03:55, 7 February 2019 (UTC)

• Were the people whose private information was accessed or shared inappropriately informed? Natureium (talk) 19:22, 6 February 2019 (UTC)

  Natureium, where private information was published, it was of course oversighted, however I do not believe any of the subjects have been directly informed, though I do know that some are subsequently aware. Worm^TT(talk) 19:48, 6 February 2019 (UTC)

  Worm That Turned, I feel like that if it was my information accessed, I'd want to know about it. When will this be rectified (or maybe who will rectify this situation?) Cheers! ―Matthew J. Long -Talk-^☖ 21:56, 6 February 2019 (UTC)

  MattLongCT, if your information is accessed by a checkuser, you would't know about it. This is standard operating practice on WMF sites, indeed on most websites and it is covered by the foundation's privacy policy. I will look into whether that should be different if the information is accessed against policy - my priority was to stop it happening again. Worm^TT(talk) 10:26, 7 February 2019 (UTC)

  Worm That Turned, this is much appreciated. Thank you. ―Matthew J. Long -Talk-^☖ 17:32, 7 February 2019 (UTC)

• I would also like to thank the committee for taking the necessary step of alerting the community to this. Like Floq I think the initial discretion was warranted, but now that he was running for steward on a platform of being the de facto CU for zh.wiki this was needed. TonyBallioni (talk) 19:25, 6 February 2019 (UTC)
• What Floquenbeam said. I recall a somewhat similar (although not identical) situation that came up during the time that I was on the Arbitration Committee. I agree with the steps that were taken at the time and also agree that it is appropriate to share further information at this time. Risker (talk) 19:27, 6 February 2019 (UTC)
• What did the OC say, if that can be disclosed onwiki? --Rschen7754 19:37, 6 February 2019 (UTC)

  Rschen7754, I'm afraid I don't have an answer to that question. Worm^TT(talk) 19:53, 6 February 2019 (UTC)

  In the past, there has not been any issue with a complainant revealing the status of an OC investigation as they know it (i.e. if it is still in progress, if it was declined, etc). The status of an investigation itself is not private information under the access to nonpublic data policy. I've sent the Commission an email requesting clarity and a public statement, if possible. -- Ajraddatz (talk) 19:59, 6 February 2019 (UTC)

  I've also made an onwiki inquiry on Meta. I agree a public statement from the OC and/or WMF would be appropriate. --Rschen7754 20:01, 6 February 2019 (UTC)

  @Rschen7754: I am a signatory to the OC complaint, and they have not updated us on the status of the investigation nor have they given us a time frame for completion. Katie^talk 20:50, 6 February 2019 (UTC)

  @KrakatoaKatie: When was the complaint filed? It is disturbing that they have not given an update in several months. --Rschen7754 01:33, 7 February 2019 (UTC)

  @Rschen7754: In August. Katie^talk 02:27, 7 February 2019 (UTC)

  I think that is completely unacceptable on their end. I have started a more pointed inquiry on Meta: [1] --Rschen7754 02:33, 7 February 2019 (UTC)

  Rschen7754, This is not a surprise to me. I made a report back in November to the OC, and had to ask in December if it had even been received. I still have not heard back since the acknowledgement - tho to be fair I wasn't sure if I should hear back ordinarily. SQL^{Query me!} 04:21, 7 February 2019 (UTC)

• +1 - I agree with the time taken and thank the committee for sharing this. –Davey2010^Talk 19:47, 6 February 2019 (UTC)
• I think it would have been very unfortunate to allow the Steward election to run its course without disclosing this information. Valid concerns regarding previous inappropriate use of the Checkuser tool(s) is directly relevant when it comes to electing an editor to a role where they will again have access to permissions involving privacy. The statement by the Committee is appreciated.-- Jezebel's Ponyo^{bons mots} 19:57, 6 February 2019 (UTC)

This is weak. Checkuser is routinely used during RFAs. I could go right now and find unsubstantiated CUs run during RFA. Why have you chosen to single out Alex Shih? This comment is based on BURob13’s question to Alex at the steward election page. Mr Ernie (talk) 20:05, 6 February 2019 (UTC)

Checkuser is *not* routinely used during RFAs; in fact, such checks are very rare, and normally are well-substantiated in advance, often at WP:SPI or potentially as a private discussion at the checkuser mailing list or between two or more checkusers. I'm concerned that you have the impression it is commonplace and routine. Risker (talk) 20:08, 6 February 2019 (UTC)

Risker could you provide any data to back that up? My impression is that C/U is run on most new accounts or IP comments at RFA. Mr Ernie (talk) 20:16, 6 February 2019 (UTC)

Regardless on the statistics (which I have not looked at), there is a difference between an uninvolved CU running a check based on legitimate concerns about bad-faith editing and the nominator of an RfA in the 'crat chat zone CU blocking an oppose. That is pretty clearly prohibited by the local CU policy: The tool may never be used to: Exert political or social control. TonyBallioni (talk) 20:22, 6 February 2019 (UTC)

I'm not going into "when did you stop beating your wife" territory here. You're the one alleging that checks are routinely being performed, so it is up to you to substantiate your statement. Without some evidence, CUs should not be randomly poking around in the CU logs, either. Risker (talk) 20:29, 6 February 2019 (UTC)

I'm a CU, and a former Arb, and running CU on people commenting in an RfA is not standard. I'm not saying it's never done, but I don't remember ever having done that, or that it has ever come up on the ArbCom or the CU mailing lists. Drmies (talk) 21:44, 6 February 2019 (UTC)

Excuse me for interacting with you again, but actually the point is that it's more about the community understanding and believing in an Ombudsman rather than hearing second-hand anecdotes of "chastisement" (wow, spank me) from those involved. Ombudsmen usually issue statements about significant cases, rather than stay silent (perpetually). This would be a good opportunity for the "Ombudsman" to speak to the community. The Rambling Man (talk) 21:53, 6 February 2019 (UTC)

When in doubt, I take you literally, but I thought I'd leave that note not necessarily for you but for others who may know less about the more or less shady bits. Spanking--well, "chastise" was the best word I could find in my thesaurus, which admittedly is more like a concordance of the collected works of De Sade. Seriously, I agree with you and wish the Ombudsman/woman/men would be more present. I knew (but forgot) who the Ombudsperson was that I was in contact with, but if it hadn't been for those interactions I'd never have known. Then again, so frequently these problems have privacy concerns at their center, and so any exposure is often another infraction. Drmies (talk) 01:20, 7 February 2019 (UTC)

Risker, wait CU's aren't audited? It isn't standard practice to systematically check random checkusers to see whether or not they made unsubstantiated checks using the logs? ―Matthew J. Long -Talk-^☖ 22:02, 6 February 2019 (UTC)

I'm not sure how systematic the reviews are now, although like most CUs I will look for outliers and red flags in the last few screens of the logs. I don't know the details of the information that was reported to the OC or Arbcom. What I was responding to was Mr Ernie's demand for proof that CUs aren't routinely done in relation to RFA, which would probably require a review of potentially hundreds of accounts (the voters) to see whether they appear on the CU logs. The CU log search functions aren't all that refined or flexible, because they're not intended for this type of research; carrying out such a study would have the potential to unnecessarily intrude on the comparative privacy of hundreds of users, particularly when there is no objective basis on which to carry out the study. Just because we all have access to the logs doesn't make it okay for us to routinely carry out searches to see if any particular user has been checked or what the result was, if available. Aside from a quick look for outliers in the logs (which aren't focused on whether specific users were checked, usually), the primary function of the CU logs is to review whether *known* problem editors have been checked in the past. Risker (talk) 22:50, 6 February 2019 (UTC)

Risker: (For one, I am glad you cleared up the RfA thing because I was under the impression that the question was about whether the nominee receives a routine CU. I did not imagine that people would even consider doing a CU on all the voters). So if I understand this right though, there is no way to check an individual CU to see what checks they made in a given timeframe? Specifically, which account they made checks for (without the personal info) and any comments associated with that check (if comments are even a thing). How does Wikimedia safeguard against abuses after a user becomes a CU? I am curious about this backend process I have not really thought about before. ―Matthew J. Long -Talk-^☖ 03:07, 7 February 2019 (UTC)

@MattLongCT: All of that is logged in meticulous detail and available to any CheckUser. We do not currently do routine audits of those logs unless specific issues are brought to our attention, but I would absolutely like that to change. I've proposed as much several times while on the Committee and will do so again when I am next active. Unfortunately, that's not likely soon, due to personal circumstances. If another arbitrator wants to take up that banner, I would fully support it. ~ Rob₁₃^Talk 03:19, 7 February 2019 (UTC)

Yes, we can review the log for individual checkusers. All checks require an 'edit summary', although for about 90% of them it will be a link to a specific SPI, but that is pretty much all the info that will be there. Summaries that aren't to an SPI are more likely to be scrutinized, unless there's a known reason for the CU to be doing something different. For example, a lot of my recent CU edit summaries refer to possible compromised accounts, since I did a lot of the legwork on that investigation, but my work in that area was well known amongst CU colleagues. There have been some (global) discussions on how the CU tool could be improved, and logs and searching of logs have been brought up as having significant potential for improvement. In fairness, though, the tool works "well enough" and rewriting the code is a very major undertaking because it's not had much work in at least the 10 years that I've had the CU bit. Until there's a CU community consensus on what can/should be improved, and those recommendations have made it through Legal and Security, only mission-critical changes would be made. We had an Audit Subcommittee for several years, but it was not as effective as I think many of us hoped it would be; in particular, only a few of the members even looked at the logs. Hope that helps. Risker (talk) 03:26, 7 February 2019 (UTC)

Risker, it turns out that it is a thing even though the Audit Subcommittee was disbanded. Huh.. Either way, thank you for your responses to me! ―Matthew J. Long -Talk-^☖ 18:18, 8 February 2019 (UTC)

@MattLongCT: The Arbitration Committee still requires functionaries to maintain a minimum level of activity in order to keep the tools, so we keep track of the number of actions performed each month. It's certainly not anything close to a thorough audit, though—when I update the statistics there I just run a quick script to determine the number of performed actions, and I don't even look at the logs. GorillaWarfare (talk) 02:08, 9 February 2019 (UTC)

Mr Ernie, I won't be going into detail about the substance of the concerns. Suffice it to point out that there is unanimous support amongst the committee who voted for this statement, and the ombudsman report was sent by multiple experienced functionaries. Worm^TT(talk) 20:09, 6 February 2019 (UTC)

Unanimous support by the committee does not in any way inspire me that it was the correct decision. This statement is weak and smacks of revenge. Mr Ernie (talk) 20:15, 6 February 2019 (UTC)

Agree Mr Ernie, and if the "Ombudsman" has any substance (indeed, I'm not even clear if they exist, I have my own concerns [see below] which may need to be addressed, but I doubt this "Ombudsman" even has any credence), then they will release a statement and cover this issue properly, rather than leave it to Alex's former colleagues to decide on this and make such muffled statements. The Rambling Man (talk) 20:18, 6 February 2019 (UTC)

Are you questioning if ombuds exist? They aren't mythical creatures, they're a committee. Natureium (talk) 20:23, 6 February 2019 (UTC)

Prove it. The Rambling Man (talk) 20:26, 6 February 2019 (UTC)

m:Ombudsman commission.--Bbb23 (talk) 20:35, 6 February 2019 (UTC)

Funniest comment of the year! The Rambling Man (talk) 20:41, 6 February 2019 (UTC)

The Ombudsman commission exists. A while ago I made a mistake after having run CU, and was properly investigated and chastised. It was, in their judgment, an infraction but one that could and should be forgiven, and it's a mistake I've not repeated. No, I have faith in the existence of the Ombudsman commission and that they take their job seriously. Unless, of course, it was just a pack of dogs that had learned how to type and ask incisive questions... Drmies (talk) 21:46, 6 February 2019 (UTC)

@Drmies: it exists, for sure! What information it is able to see, is subject to various "bugs", as described below! This rather renders it meaningless. MPS1992 (talk) 01:58, 7 February 2019 (UTC)

As Amory has pointed out below, Alex was referred to the Ombudsman regarding his use of Checkuser, not Oversight, so I'm not sure why the Ombudsman's investigation would be rendered meaningless because of a bug that affects one portion of the search capability for the Oversight log. As a side note, it's one bug, not "various bugs", plural. ♠PMC♠ (talk) 03:56, 7 February 2019 (UTC)

@Mr Ernie: I think it's important to note that the RfA CU was not the only concern raised with the Ombudsman. In fact, it was the fifth concern listed of five, and I would consider them to be listed roughly in order of importance. WTT mentioned above that private information had to be suppressed on-wiki related to some of the issues. Extremely bright lines were crossed here. In any event, my concern with the RfA CU is less about the fact that a check was run and more about a clearly involved CheckUser running it. If Alex had concerns about that editor, based on his obvious involvement, he should have forwarded it to another CheckUser to determine if a check was warranted. ~ Rob₁₃^Talk 20:50, 6 February 2019 (UTC)

Not sure if CU and Oversight should appear in user rights log but they are also missing at Special:UserRights/Alex_Shih. --Emir of Wikipedia (talk) 21:42, 6 February 2019 (UTC)

CUOS changes are logged at meta. Kevin (aka L235 · t · c) 21:43, 6 February 2019 (UTC)

(edit conflict)Those are placed and removed by stewards, so will appear in the meta logs, e.g. me ~ Amory (u • t • c) 21:44, 6 February 2019 (UTC)

• Just noting that if I had been eligible to vote I would have supported the statement. Doug Weller talk 21:46, 6 February 2019 (UTC)
• Arbs, thank you for the statement. Drmies (talk) 21:48, 6 February 2019 (UTC)
• Why has Alex Shih been permitted to retain his +sysop permission ? I would have thought the level of either incompetence or misuse of the CU/OS tools and non-public information being discussed today would be incompatible with retaining any advanced permission, or perhaps, depending on the severity of the issues at hand, incompatible with continued editing access to Wikipedia itself. Nick (talk) 22:17, 6 February 2019 (UTC)

I don't believe that any evidence was presented that he abused admin tools as opposed to functionary tools, and arbcom doesn't go looking for cases. In most cases where tool misuse is pointed out and the user in question gives up those tools that's the end of it. Beeblebrox (talk) 23:49, 6 February 2019 (UTC)

I can also see the source of TRM's skepticism as apparently the OC forgot to tell anyone what they'd been up to for the entirety of last year. Now that all this is going down they are "working on it". Beeblebrox (talk) 23:52, 6 February 2019 (UTC)

Agreed. While TRM presented his argument in a bit of a snide way, his argument seems to be that the OC lacks responsiveness and I would generally agree. -- Ajraddatz (talk) 23:58, 6 February 2019 (UTC)

The Ombudsman Commission does not make public their inquiries or the results of them, generally because it's impossible to do so in a way that would actually inform the community. I admit even coming forward with as much information as I did about this situation has been a somewhat frustrating experience, because there's much more I'd like to say but cannot. I'm glad we could provide some information, in any event, even if I wish it were possible to provide more. ~ Rob₁₃^Talk 00:45, 7 February 2019 (UTC)

I really hope that they don't take this as an attack on them personally, but from what I've seen (both onwiki and during my steward term) they don't seem to be responsive, and when they are responsive they sometimes make some odd pronouncements. I remember that a large number of CUs/stewards on checkuser-l sharply disagreed with the findings of one case that happened when I was on the list. --Rschen7754 01:22, 7 February 2019 (UTC)

I know they are very tight-lipped, but they usually at least issue activity reports every six months, which they have failed to do at all for 2018. These reports are very basic and I can't see how, given their usual caseload, it would take more than hour to get them done, yet despite repeated requests for them they've not been done. Beeblebrox (talk) 02:07, 7 February 2019 (UTC)

I agree that's a substantial problem. ~ Rob₁₃^Talk 02:25, 7 February 2019 (UTC)

For what it is worth, a new Ombudsman Commission was just installed (see meta:Talk:Ombudsman_commission#2019_Ombuds_Commission_announcement and SRP of the changes). — xaosflux ^Talk 03:45, 7 February 2019 (UTC)

• Thank you arbs for the statement, and thank you to those who brought this issue to the general public. ZettaComposer (talk) 12:53, 7 February 2019 (UTC)

Hi everybody,

First of all, my opinion not represents the Ombudsman Commission. I make this comment trying to keep the community informed

Understanding the community position since there is no information on this case, I can only say that the commission is still investigating this case. Per the change of members, the case take more time for resolution. For my part, intend this case be resolved quickly due the upcoming elections.

Regards, --Galahad (sasageyo!)^{(eswikivoyage)} 03:55, 7 February 2019 (UTC) (Sorry if my english are bad. My skills has oxidized)

@Galahad: Thanks. SMDH Dlohcierekim (talk) 05:24, 7 February 2019 (UTC)

Thanks Galahad. I think the big concern here isn't the new Commission and the transition period, which has only been for a couple of days now, but rather why the previous group didn't respond within five months. Hopefully this year's group can be a bit more responsive. -- Ajraddatz (talk) 06:10, 7 February 2019 (UTC)

Yeah, I was assuming they reviewed this and came to some sort of decision and just failed to issue their usual report. This makes it sound like they've done nothing and left it for the new guys. Not encouraging. Beeblebrox (talk) 06:34, 7 February 2019 (UTC)

I'm pretty sure an hour, as you suggest above, is very optimistic. I hope very much that they spend a lot more than that on issues that are so important. Doug Weller talk 08:23, 7 February 2019 (UTC)

Perhaps the process is more convoluted than we can imagine and they have been working tirelessly on it but ran out of time. Dlohcierekim (talk) 10:30, 7 February 2019 (UTC)

The activity reports are very,very basic. Here is the most recent one. There are no details or names, just a brief overview of what the committee has been doing so it isn't a complete black box operation. With no reports, we have no way of knowing if they responded to anything that came across their place in the last 14 months. Beeblebrox (talk) 16:31, 7 February 2019 (UTC)

Beeblebrox, I have drawn the individual attention of the members of the last year's OC, to the issue of their activities in Alex's case. Let's see.

One of the outgoing members Billinghurst mentioned that she had been inactive in the committee from the middle of last year....... ∯WBG^converse 16:47, 7 February 2019 (UTC)

@Beeblebrox: Excellent point. Some sort of reportage or accounting would be much desired. Dlohcierekim (talk) 17:00, 7 February 2019 (UTC)

Hi all, will give you a summary: I understand that due to the reports that are made, many believe that our resolutions can be made in an hour. Completely false. Our procedures take considerable time since they are complex situations (of course, they send us cases that are trivial, but are counted). About the case, I hope that in a 24/48 period we can solve it and be able to issue a resolution. Regards, --Galahad (sasageyo!)^(esvoy) 18:50, 7 February 2019 (UTC)

When an ordinary sysop discloses some confidential information, the ordinary follow-up is a reduction Super-Mario ${\displaystyle \mapsto }$  Mario: when confidence is lost, tools are to be lost either. But when an extraordinary sysop is convinced of five breaches of confidentiality, he is not reduced to the simple-Mario state. He is granted a special courtesy escape, that had the appearance of a voluntary resign of special privileges, while keeping the administrative capability. This opens a new category of players: the Hyper-Mario ones, who are granted three lives instead of two. But the main point now is not to discuss this "courtesy escape bargain". The main point is that trying to reobtain the Check_User abilities while non mentioning they were lost under a cloud is nothing than an unilateral denial of the bargain... and another proof that confidence would be foolish. A re-opening of the case and a full reduction Hyper-Mario ${\displaystyle \mapsto }$  Super-Mario ${\displaystyle \mapsto }$  simple-Mario seem to be in order. Pldx1 (talk) 09:35, 7 February 2019 (UTC)

Best analogy I've read all day. Dlohcierekim (talk) 10:27, 7 February 2019 (UTC)

You could also call it a Fire Mario case... in Super Mario Bros. 3, if you touch an enemy as Fire Mario, you become Super Mario, then if you touch another enemy, you become Small Mario. — pythoncoder  (talk | contribs) 21:30, 9 February 2019 (UTC)

Several above have argued that Alex Shih retains the tools because there was an abuse of CU, not an abuse of admin tools. But isn't blocking someone who is opposing an RfA you nominated, on the face of it, an abuse of the tools as well as an abuse of CU? If he has been de-functionaried for abuse of CU, isn't there an equal case for de-sysoping him for abuse of the tools? I don't know what the other four cases were (and it seems unlikely that we will know many details, at least until the log search is fixed). But if, as suggested above, the information Alex disclosed which has since been oversighted was in log records, it seems likely that these were also cases where CU abuse went hand-in-hand with tool abuse. GoldenRing (talk) 09:57, 7 February 2019 (UTC)

@Nick, Pldx1, and GoldenRing: the idea of desysopping did get discussed when the issues first came to light. I can say this because I was the one who raised it. However, a desysop by the committee without a case is very difficult to do, by design. We have two procedures to do so and neither particularly fit. There were a large number of other factors, from the fact that the highest priority was on his CUOS permissions, to the fact that prior to starting on the committee he had been a perfectly fine admin who held the respect of the community. I could go on about other factors, but when it came down to it - Alex chose to resign, and the committee believed this was the best outcome. Worm^TT(talk) 10:16, 7 February 2019 (UTC)

I would argue that abuse of a 'functionary' permission relating to oversightable material (content or log entries) also constitutes abuse of the 'sysop' permission relating to deletable (or revdel) material (content or log entries) since those two permissions effectively are joined together. I would also argue that if a user can no longer be trusted to oversight material appropriately, they also cannot be trusted to delete material. I agree with Boing! said Zebedee and it is now firmly my opinion that Alex Shih is no longer fit to be an admin (though I will admit, that has been my opinion based on other factors for a number of months now). Nick (talk) 10:33, 7 February 2019 (UTC)

Yes, I think such a block would be a clear breach of WP:Involved. As a one-off, though, it wouldn't be enough for a desysop. Saying that, in my view Alex is clearly unfit to be an admin, as I suggest below. Boing! said Zebedee (talk) 10:17, 7 February 2019 (UTC)

We can't, of course, be entirely sure of the circumstances. CUing someone for opposing you RFA candidate is one thing; that someone quacking is another. If the latter was the case, then best practice (only practice) would have been to ask another CU to take a look. Sometimes we get excited and do things in haste that should have been left undone. For my part, I still can trust him with the rest of the tools if he avoids involved behavior in the future. Dlohcierekim (talk) 10:24, 7 February 2019 (UTC)

For my part, I can no longer trust someone with access to deleted and rev-deleted material after they have disclosed, on-wiki, non-public information to which they had confidential access as an Arbcom member, committing breaches of checkuser policy multiple times. Boing! said Zebedee (talk) 10:37, 7 February 2019 (UTC)

The CUing of an RfA !voter is, unfortunately, only one instance of several abuses of the CU and OS toolset, and inappropriate handling of non-public information, according to the statement from Rob at Alex's Steward candidacy page and according to the ArbCom announcement. I believe if it was a one-off event, the result would have been a strong rebuke from the Ombudsman Commission not to repeat such an occurrence (based on comments from another of the functionaries who had made similar errors in judgement with the CU/OS tools). Nick (talk) 10:38, 7 February 2019 (UTC)

Yes indeed, but then we have the question of whether the other abuses involved the misuse of admin tools. Boing! said Zebedee (talk) 10:43, 7 February 2019 (UTC)

@Worm That Turned:. I am not discussing the 2018 settlement. I have no doubt that the committee believed this was the best outcome, and committee's members were elected to balance the issues and take decisions. But now, this settlement has been torn into pieces by User:Alex Shih himself, so that issues are to be sorted again. By the way, I am not sure if we have to thank our arbs for their transparency/reactivity in this case: they were elected for that, weren't they ? Nevertheless, the said transparency/reactivity is noted and appreciated. Pldx1 (talk) 12:31, 7 February 2019 (UTC)

• I would say, again, that arbcom is not an investigative body. As worm mentioned, the circumstances under which they can desysop without a full case are very limited. Anyone can file a case though, if they belive there is sufficient cause to desysop. Beeblebrox (talk) 16:38, 7 February 2019 (UTC)

  Were one to file such a case, I would argue contra. Dlohcierekim (talk) 16:42, 7 February 2019 (UTC)

There are some violations of the checkuser and access to nonpublic data policies that would not translate into the level of lost trust needed for a desysop. Generally speaking, a privacy violation could range from the incidental and inferential disclosure of a user's IP when placing blocks (something that is explicitly allowed by the nonpublic data policy when necessary to prevent abuse) to running checks on trusted community members and publishing the results offline. I'm not saying that either of these happened here, but my point is that there is a range of possible misuse that could have happened, and some of it towards the incidental disclosure end of the misuse spectrum would not necessarily translate to requiring a desysop in addition to removal of the CheckUser access. This problem is also confounded by the lack of information that ArbCom can release on what happened, making it very difficult for the community-at-large to judge whether the misuse of the CheckUser tool would necessarily translate into lack of trust with the sysop tool as well. -- Ajraddatz (talk) 16:43, 7 February 2019 (UTC)

I'm seeing a lot of arguments about "loss of trust" from the community here. As an editor, I personally feel that when an administrator loses the trust of the community, they should be desysopped. As an arbitrator, our processes do not allow for desysopping of an administrator except in cases of gross incompetence or abuse of administrative tools. Administrative tools were not abused here, in my opinion. Once an editor is identified as a sock beyond doubt, a block is such an obvious action as to meet the exemption in WP:INVOLVED. While the check would not meet that exemption, once the check yields a   Confirmed result, a block would. No other instances in the Ombudsman Commission report related to potentially involved blocks. I don't see anything approaching a case related to abuse of administrative tools. When it comes to gross incompetence, I don't see lack of discretion with private information to be particularly relevant. Alex has been removed from all roles that provide access to private information, so his shortcomings there cannot cause further damage. Based on all that, as an arbitrator trying to faithfully execute the procedures for desysopping, I see no case here. If the community wants broader desysopping procedures to handle cases of "lack of trust", you would need to propose something at a wide-scale RfC. I would support, so long as the proposal had sufficient safeguards to prevent process harassment of admins working in difficult areas. ~ Rob₁₃^Talk 17:47, 7 February 2019 (UTC)

FWIW, WP:ADMINACCT actually does allow for desysoping for gross breach of trust along with several other things beyond tool misuse, and the committee has desysoped for breach of trust before when no major tool misuse happened (Salv in the MisterWiki case). Like Beeblebrox, I'm not commenting on whether or not their should be a case, but there is a policy-based argument for a desysop here even without abuse of the sysop toolkit. Also, I just realized that Breach of basic policies (attacks, biting/civility, edit warring, privacy, etc.) is also mentioned as grounds for desysop, so violations of the privacy policy would seem to count as well. Again, not saying there should be a case, but that it isn't a black and white "he didn't use the sysop toolkit" question. TonyBallioni (talk) 18:07, 7 February 2019 (UTC)

The policy goes on to give examples that I don't think this fits. I wouldn't say the access to nonpublic information policy is a basic policy that we expect all admins to understand and adhere to. But then again, if the community would want ArbCom to desysop when there is loss of trust as measured by substantial community desire for desysopping, why not create a community-based desysopping procedure? We'd be a rubber stamp if we interpreted calls for removal as gross loss of trust. ~ Rob₁₃^Talk 18:33, 7 February 2019 (UTC)

That's a fair view to take to the circumstances, I wasn't commenting on the specifics, just that there is a policy argument to be made here and that ArbCom has used in the past along with generic formulations such as "conduct unbecoming" to desysop without any tool abuse.

Community-based desysop is the thing you and I probably disagree most strongly on, and I don't want to distract this thread with that, but I think an RfC on it now or on the "trust" principle of the current desysop policy would only muddy the waters and make what amounts to a pretty clear policy (if you do something that is a large enough mistake, intentional or otherwise, ArbCom can desysop you) less clear than it is. TonyBallioni (talk) 18:41, 7 February 2019 (UTC)

Absent a general procedure for initiating the removal of administrative privileges, I think if the community wants to make an argument for a specific individual that trust has been lost, it can hold a discussion and open a subsequent arbitration case if warranted. I would prefer that the arbitration committee be conservative and not be too ready to assume that trust has been lost. However there should be a way to raise potential problems to the community at large while respecting the privacy of those involved and not revealing specific details. isaacl (talk) 19:00, 7 February 2019 (UTC)

• I'd like to be clear that my above comment was not intended to suggest that someone should file a case, only that that is the only way a desysop is going to happen, and only then if there is sufficient evidence of a pattern of misuse of admin tools. If such evidence exists I have not seen it. Beeblebrox (talk) 18:00, 7 February 2019 (UTC)
  • I think certain issues, including privacy-related ones, can cause a sufficient loss of confidence, even with a single occurrence. isaacl (talk) 19:02, 7 February 2019 (UTC)

I think there's a difference between someone making an honest mistake and someone being malicious/abusing power. In the latter, I don't think one should retain admin rights. I'm not calling for a ban or block in this case, but violations of the privacy policy can be grounds for a m:Global ban, for example. Also, there is precedent for such a desysop: Wikipedia:Arbitration/Requests/Case/Sockpuppet investigation block --Rschen7754 19:28, 7 February 2019 (UTC)

Who woulda thunk it? Sending The Guardian information linking a user with a person? SMDH. Dlohcierekim (talk) 19:45, 7 February 2019 (UTC)

• @Ajraddatz: I'm a bit confused by your statement above. I'm reading you as saying that some mistakes are not serious enough for a desysop, which I agree completely with; no sysop I'm aware of has a perfect record. However, the violations in this case were clearly seen as serious enough that ARBCOM felt a resignation was in order. That's an entirely different level of "mistake" than an ordinary admin mis-step. If someone's judgement was so impaired as to make a resignation of the CU flag necessary, I cannot see how the sysop flag can still remain in place. Vanamonde (Talk) 23:21, 7 February 2019 (UTC)

  @Vanamonde93: On the one hand, I take your point; on the other I disagree. They are different tool sets with differences in openness. Admins are by nature under constant scrutiny and all we do is done in the open. There is no privacy at all in what we do. CU's are by nature secretive with their actions hidden from view. Everything must be held in private and confidential- secret. Alex's error was in making public that which should have remained secret. Even if done with the best of intentions, it was an unbecoming error for a CU. Dlohcierekim (talk) 23:41, 7 February 2019 (UTC)

  I've thought about this for a bit, and even typed out a couple of responses. I'm not sure how to expand on what I said without saying too much or stepping on ArbCom's toes, sorry. My thoughts generally align with BU Rob13's comment above. -- Ajraddatz (talk) 23:57, 7 February 2019 (UTC)

  @Dlohcierekim and Ajraddatz: Those are fair points, but I think we're exploring a subtle but important area here, so forgive me for continuing this. Yes, a CU's activity is largely not open to scrutiny from most editors, and yes, the privacy policy (which I've had to become acquainted with, as an OS) is a complicated beast. Yet I don't recall any admin losing their bit for an action (or a single series of actions) based on a good-faith misunderstanding of the policy. Anyone who makes a mistake (and that's everybody) gets a "here's why you shouldn't do that again", and we move on. Mops have been taken away when admins showed a persistent inability to understand or unwillingness to abide by a policy, or for conduct unbecoming, and in each situation what was fundamentally at issue was temperament or judgement, not the understanding of a specific policy. To be clear, I'm not clamoring for a desysop here, but I do feel we're in a bit of a bind because the community hasn't the information to explore this further, but ARBCOM as a non-investigative body hasn't the remit to examine this further. Vanamonde (Talk) 04:20, 8 February 2019 (UTC)

  I guess that’s why they have ombudsmen. I did not even know they have ombudsmen. And the WMF is probably investigating too. As much as we want to keep our own house in order, it’s being examined at the highest level. And we may never know the outcome, cause “privacy”. This why I’ll need to be careful if I ever become a checkuser-- my need to stick my nose into dark places. They say we are not employees, but we are. And other employees are not informed about an employee's "disciplinary" issues-- again citing privacy. Dlohcierekim (talk) 04:29, 8 February 2019 (UTC)

  Okay, that's reasonable. In some ways it goes against the grain for me in terms of everything being community-run, but I can't see a different way to do it that still maintains privacy. Vanamonde (Talk) 04:33, 8 February 2019 (UTC)

  For what it’s worth, there is a simple way to address the question of if a desysop is needed: if someone thinks it is warranted or needs to be answered file a case request. No need for some community desysop RfC and ArbCom can review private info. The reason no desysop was considered here is because ArbCom can only do that in very limited circumstances without a case, and this doesn’t meet those. TonyBallioni (talk) 05:13, 8 February 2019 (UTC)

  This is the correct answer, for what it's worth. ~ Rob₁₃^Talk 20:55, 8 February 2019 (UTC)

  Something that is not clear to me, because I obviously do not know what the events were that could not be made public, is whether what Alex did was in effect a single series of errors that would fall under "here's why you shouldn't do that again", or whether problems occurred successively, in a way that would be more like a persistent problem. If it's the latter, there could be a good reason for filing a case request. But if that is the situation, most users have no way of knowing it. I think this paradox makes for a particular responsibility of the functionaries to evaluate whether or not there is a potential need for an ArbCom case, and to say that a case is not warranted only if they can see clearly that it is not warranted. --Tryptofish (talk) 22:13, 8 February 2019 (UTC)

  I think it's a valid concern, and I'm never very happy with an answer of "don't worry about it, the people with private access will regulate the other people with private access". I'm just not sure what else can be done here. The access to nonpublic data policy only prohibits disclosure of private personal information, so it could be possible to disclose more specifics about what happened. But no matter how much private but non-personal info was disclosed, the community would never be able to get the full picture. The OC addresses some of this problem, since they can be an objective and neutral body, but even then the OC cannot answer whether the user being investigated should retain sysop access after their CU bit is removed. The WMF can help a bit more with that, since OC reports go to the WMF who can then take actions like banning a user from holding advanced permissions. But I am not sure how to keep the community informed and involved in this process. -- Ajraddatz (talk) 18:51, 8 February 2019 (UTC)

Above, Worm That Turned states that "a desysop by the committee without a case is very difficult to do, by design," noting that the two procedures available "neither particularly fit." Similar comments have been made by:

• Beeblebrox: "the circumstances under which [ArbCom] can desysop without a full case are very limited. Anyone can file a case though, if they belive there is sufficient cause to desysop." He subsequently added that "I'd like to be clear that my above comment was not intended to suggest that someone should file a case, only that that is the only way a desysop is going to happen, and only then if there is sufficient evidence of a pattern of misuse of admin tools. If such evidence exists I have not seen it."
• TonyBallioni: "there is a simple way to address the question of if a desysop is needed: if someone thinks it is warranted or needs to be answered file a case request. No need for some community desysop RfC and ArbCom can review private info. The reason no desysop was considered here is because ArbCom can only do that in very limited circumstances without a case, and this doesn’t meet those." BU Rob13 followed up that "[t]his is the correct answer, for what it's worth."

So, we have functionaries and current / past Arbitrators arguing that no action was possible absent a case. This might be technically accurate, but it is also flawed in that a simple solution was available if necessary: open a case. ArbCom demonstrated in the EEML situation that it can open a case by passing a sua sponte motion from one of its members. Cases have been filed before by arbitrators (somewhat controversially) and a case request from a functionary with sufficient knowledge of the situation is still possible now. Alex's steward bid appears to provide evidence of poor judgement that fits with accountability requirements. I accept that the level I and II procedures don't fit here, but let's be honest – no case was started to allow consideration of a desysop because ArbCom (collectively) was content to let Alex resign, and nothing since has riled anyone enough to take any public step until the steward nomination appeared.

We have also had BU Rob13 arguing (wrongly, in my opinion) that ArbCom "processes do not allow for desysopping of an administrator except in cases of gross incompetence or abuse of administrative tools" and that "[i]f the community wants broader desysopping procedures to handle cases of "lack of trust", you would need to propose something at a wide-scale RfC." Rob has added that "if the community would want ArbCom to desysop when there is loss of trust as measured by substantial community desire for desysopping, why not create a community-based desysopping procedure? We'd be a rubber stamp if we interpreted calls for removal as gross loss of trust." Leaving aside the fact that every proposed community desysop procedure that I recall ends up being failing to reach consensus due to opposition from present sysops, I am disturbed to read an arbitrator arguing that (a) loss of trust (even if only loss of trust from ArbCom rather than the community) is not a grounds for desysopping, and that (b) if it were, what we need is a community process and an ArbCom rubber stamp. Arbitrators are elected to exercise discretion on desysopping. There have been cases where there has been questions whether an admin retained the trust to hold the tools, or even was trustworthy, and the idea that ArbCom is unable to act in such cases feeds into the untouchable / admin-for-life attitudes that divides the community it rulers and the ruled and makes RfA voters so strict. In the present GS case, we have a principle that portrays ArbCom as a "tool of the community" (in SilkTork's words). Given the ideas of administrator accountability state that administrators "who have lost the trust or confidence of the community, may be sanctioned or have their administrator rights removed" and that examples include "repeated or consistent poor judgment," the notion that what is discussed here does not meet the standards for a desysop to be possible, and especially as the suggestion seems to be that Alex had multiple problematic actions, appears to me (and based only on the publicly-known facts) to be absurd. Only ArbCom can desysop, a sanction available under admin accountability, and repeated examples of poor judgement are alluded to here, so the notion that ArbCom is powerless absent misuse of tools in the sysop bundle or gross incompetence is either a reflection of a deeply flawed policy or an inaccurate view of that policy. I agree with TonyBallioni that "there is a policy-based argument for a desysop here even without abuse of the sysop toolkit."

A case is clearly possible now, but the suggestion that it is up to the community to make the case for it is absurd given the amount that is unknown to the community. I note the wise words of Tryptofish: we have a situation with "a particular responsibility of the functionaries to evaluate whether or not there is a potential need for an ArbCom case, and to say that a case is not warranted only if they can see clearly that it is not warranted." I don't know if Alex's actions are sufficient for ArbCom to lack faith in his judgement and to justify removal of the tools, though there is reason to think that they might be. I do think repeated poor judgement does arguably include misusing advanced tools, asking for them to be reinstated, and making misleading statements about their removal (resignation "under a cloud"). I also think that does impact on being trusted to retain other advanced tools. I am disturbed to read an Arbitrator arguing that such actions and questions are outside ArbCom's remit, or that technicalities of procedures mean tat a case is required while denying the responsibility to ensure one is brought if one is needed.

I call on all functionaries with knowledge of these events to tell the community whether Alex retains your trust and whether you believe that Alex would retain the community's trust if we knew what you do. I call on the members of ArbCom who sought Alex's resignation, tell us whether an evaluation of whether Alex retains the trust of ArbCom or should retain the trust of the community if we knew the details you have, and including in light of events since the resignation. We do not have the information needed to make an informed decision. All of you have the obligation to maintain confidentiality and know that any case would largely need to be off-wiki. You may not be able to share all (or even much) of your reasons for whatever views you hold, but you can at least make a straight-forward statement of your view on whether some action is needed under the provisions that exist beyond the question of misuse of tools in the sysop bundle. EdChem (talk) 01:35, 9 February 2019 (UTC)

I have seen everything I'm allowed to see about this. What I have seen is a few rookie mistakes of the kind we would usually forgive, and two instances of demonstrably poor judgement, the one everyone knows about at RFA, and one other instance of a checking someone when it wasn't really warranted. When confronted about this he resigned both as an arbitrator and as a holder of CU and OS tools.

I will not be supporting him in the steward elections, and apparently he was a bad fit as an arb, but I have not lost trust in him as an admin, a position he has held now for 12 years. Arbcom is not for everyone, indeed not for most, and nearly every year someone leaves before the end of their term for whatever reason. The reason here was not just the smattering of errors with the CU tool but apparenrly also behind-the-scenes arb stuff. That doesn't really have much to do with his suitability to be an admin. Beeblebrox (talk) 02:17, 9 February 2019 (UTC)

I think you somewhat misunderstood me, EdChem. I didn't say we could only desysop through an RfC and rubber stamp. I said that we can't desysop merely because people are calling for a desysop, with the fact that such calls are happening demonstrating a loss of trust. "Loss of trust" is judged by actions, not the results of people calling for a desysop. There can be cases where we should desysop when few are calling for it or where we shouldn't desysop under our current policies when many are calling for it. If the community wanted it to be otherwise - that an admin should lose the mop if a sufficient number of editors believe they no longer should retain it - then that sounds a lot like community-based desysopping, which is what my comment was pointing out.

In any event, I think at this point, there are two options that the community has. They can file a case request or not. From an Arbitration Committee perspective, we currently have nothing in front of us to act on. Our ArbCom-initiated desysopping procedures do not particularly apply, as WTT mentioned. The community is aware of the issues and has thus far not filed a case request. I would not expect ArbCom to initiate a Level II desysop based on this. ~ Rob₁₃^Talk 06:48, 9 February 2019 (UTC)

I agree that this would require someone from the community filing a case request. I suggest that people read the reasons given by some of the people who voted against him during the current steward elections.[8] Some of them comment on how he handled his resignation from the committee and the lack of full disclosure in his run for steward. Also there is User:MastCell's post to him at User talk:Alex Shih#Conflicting stories where he raises similar issues. I personally think he no longer deserves the community's trust. I also think it's possible he's leaving Wikipedia. He's already indicated at Wikipediocracy that he's trying to "fade away" from the project, and I doubt that he'll response to MastCell. The options for the community seem to be to do nothing, initiate a case, or go to ANI for a block. Again, my guess is he won't respond to the latter two. Doug Weller talk 07:13, 9 February 2019 (UTC)

I agree with everything Doug has said. I was trying to find a way to respond to this ping but he said it better than I could. TonyBallioni (talk) 07:32, 9 February 2019 (UTC)

I thank EdChem for the kind words, and I'll say to everyone who responded to him that it is very difficult for the general community to be confident of the right course of action based upon what we know, and that things that may appear clear to you are not necessarily clear to the rest of us. I agree with Doug Weller that "he no longer deserves the community's trust", and I'm guessing that there are multiple editors waiting to see if someone else will file the case, a sort of "after you; no, after you" kind of thing. It's not like ArbCom is held back, in the event of a case, by the difficulty of determining whether there is a loss of community-wide trust based only on some editors saying so on the case request page. That's a weak excuse. ArbCom should be fully capable of evaluating evidence and determining whether or not there was inappropriate conduct, without any need to read the minds of users beyond those who comment on the case. And whether or not Alex is leaving is similar to what the Committee recently had to deal with, with Jytdog. Even if Alex leaves or appears to have left, without responding to a case request, the Committee is perfectly able to determine that he is desysopped under a cloud and can only regain the permissions via a new RfA if he returns. --Tryptofish (talk) 19:42, 9 February 2019 (UTC)

• @GoldenRing and Boing! said Zebedee: and myself have jointly filed a request that ARBCOM look into this. Those of you who have commented here, and in this section specifically, may be interested in commenting there. Vanamonde (Talk) 21:51, 9 February 2019 (UTC)

• @BU Rob13: "why not create a community-based desysopping procedure?" That's rich. WE TRIED. It was overwhelmingly approved by the non-admin community, but it failed, because, in a blatantly flawed, corrupt process, admins went against it 55-45, and arbs went even more heavily against it at almost a 2:1 ratio. So, in other words, the elite members who would actually be affected by the community's desire to increase accountability were able to drag the support percentage down to 60%, which is still rough consensus territory, and strong consensus territory when you don't give equal weight to the people with an obvious conflict of interest. Even stronger when you're simultaneously acknowledging a "general consensus" for some sort of community de-adminship, reinforcing a consensus from years earlier. The closer "wasn't comfortable" however, and who could blame them? Imagine the shitstorm if a non-admin closed that discussion in favor of the proposal, pissing off a majority of admins and super-admins. How could they? I don't blame them. It was the admins who opposed who deserve to be blamed, for their lack of accountability and integrity, and their betrayal of the community. ~Swarm~ {talk} 00:35, 11 February 2019 (UTC)
  • (edit conflict) It's a bit misleading to say I opposed community-based desysopping at the time. I opposed that specific proposal for a variety of reasons. My opinion is basically that it was simply a condensed ArbCom case that does not give the community a direct say in whether a sysop retains their trust. I made an alternative proposal at Wikipedia:Administrators/RfC for binding administrator recall which flamed out, but I still think something closer to my proposal is the way to go. I certainly went about that proposal the wrong way. I was a few month old wiki-baby at the time, and I didn't understand exactly what it takes to bring a large-scale RfC to fruition. It remains one of my greatest regrets on the project that I didn't sit on the idea and polish it up for a time when I had the ability to actually push for it with some chance at success. ~ Rob₁₃^Talk 00:46, 11 February 2019 (UTC)

@BU Rob13: Yeah, I had removed the bit about you opposing, which was just me pointing out irony because I can't help myself sometimes. But it distracted from my point. I don't blame you for it, you weren't even an admin at the time. As I said, the problem was quite straightforwardly the fundamental, institutional corruption of admins and arbs having blocked the proposal, which would have overwhelmingly passed otherwise. :( ~Swarm~ {talk} 04:02, 11 February 2019 (UTC)

FWIW as someone who would like to see a community desysop process, BARC was not appealing to me. It was comparable in bureaucracy to an ArbCom case, and didn't actually give the community power over the outcome. Don't get me wrong, bureaucrats are great, but most of them were elected 10+ years ago and looking at the totally random and made-up rationales for their crat chats doesn't inspire me with confidence that they as a group could somehow do a better job of desysops than ArbCom or the community. Just use an existing system that is already in place on Wikimedia, like the one on Commons and Wikidata (consensus on AN to start a desysop request, simple majority for removal, my preference), dewiki, nlwiki, and a bunch of others. Build a process with some safeguards to prevent admins being removed for working in controversial areas and prevent requests being filed every week. If the community doesn't like it, the process can always be changed or removed in the future. -- Ajraddatz (talk) 04:11, 11 February 2019 (UTC)

(edit conflict) @Swarm: I think that's a bit wrong-headed. On one hand, sure, admins and arbs could be clinging to power. On the other hand, they're also uniquely in a place to understand the blowback admins can face for taking necessary actions in tough topic areas, and so they can most easily see how a naive proposal for community-based desysoping may fail to account for bad-faith recalls/desysop requests. Perhaps there's a bit of both, but I think it's more the latter than the former. Obviously, I badly want community-based desysopping. ~ Rob₁₃^Talk 04:17, 11 February 2019 (UTC)

I've always found the "but what about admins who work in controversial areas???" argument to be pretty weak. It hasn't happened on any wiki where I have been active, and even the most basic process design can prevent it. Plus, if there are enough woke community members who can show up to oppose a community-initiated process in fear of losing those controversial-areas admins, there should be enough of them to vote on deadminship requests to keep said admins. -- Ajraddatz (talk) 04:23, 11 February 2019 (UTC)

@Ajraddatz: I can think of several examples where we did lose very valuable admins due to unfair blow-back from valid actions in controversial areas. Mike V comes to mind. The problem isn't so much that they would actually be deadmined. The problem is that they'd leave due to the harassment. I do agree that the most basic process design can prevent this, but I'd argue that BARC didn't have that basic process design. ~ Rob₁₃^Talk 15:36, 11 February 2019 (UTC)

@BU Rob13: Alright, fine, perhaps I'm being too cynical. Just remembering it and then re-reading that made me frustrated though. The merits of the proposal aside, seeing a realistic community de-adminship attempt fail for no other reason than admins breaking with the community and effectively blocking it just feels...so wrong. I just can't get over that. I hope you're right, and it's not as bad as it looks. But it really looks bad. I hope that theoretically, there could be a proposal that that admin corps would be on board with, that is still reasonably accessible and lightweight for the community. I'm skeptical as to whether that's a realistic scenario, though. ~Swarm~ {talk} 06:55, 11 February 2019 (UTC)

Just a couple of thoughts. While Arbcom handled the original investigation and resignation with discretion, and some above have commended that, part of me thinks there's another side to it. The thing is, we the Wikipedia electorate voted Alex Shih into high office, he violated that trust very badly, and we weren't allowed to know about it. In fact, he was even allowed to lie publicly about his reason for resigning, generating undeserved public sympathy. If he hadn't had the gall to run for Steward, we'd never have known how badly we were let down by an Arbcom member. I'm not going to accuse Arbcom of a cover up (because there obviously is information that we can't see and judge), but I do think there's something wrong here.

My other thing is that this is a perfect example of why we need a community de-sysop procedure - for when an admin doesn't misuse any admin tools but, thanks to a n egregious violation of a core Wikipedia policy and of community trust, they wouldn't stand a chance in hell if they tried RfA now. If Alex has any honour left, he (struck that part as it seems too personal) I think Alex should resign from admin, and run again at RfA if he wants to find out if he still has the community's trust. Boing! said Zebedee (talk) 12:56, 7 February 2019 (UTC) (updated)

Oh, meant to also say but forgot - I do thank the committee for doing the right thing now and revealing this information in time for the Steward election voting process. Boing! said Zebedee (talk) 11:07, 7 February 2019 (UTC)

I can't actually judge whether or not Alex's actions were an egregious violation ... it appears that a sockpupppet was exposed because of voting in an RfA because Alex checkusered the sockpuppet account. I do, however, find the ArbCom's actions in covering up the real reasons he resigned to be ... concerning. If Alex's actions were so bad that he had to be forced to resign, why was a totally different reason given to the editing community? To me, this smacks of thinking the normal editors are not worthy of being told the real reasons for something ... or it smacks of an elite trying to cover up mistakes made by other members of the elite. Either way, it smells. Ealdgyth - Talk 13:03, 7 February 2019 (UTC)

Fair point about the "egregious" bit, I've struck that. The RFA thing wasn't the only problem, though, as there were multiple instances of violations of CU policy (including on-wiki disclosure of non-public information), plus "other breaches of confidentiality in his use of private information received whilst on the Arbitration Committee". Boing! said Zebedee (talk) 13:12, 7 February 2019 (UTC)

I agree that it's disturbing that Alex was allowed to quietly resign with no reason given to the community, after he violated the community's trust in a position he was elected to. While I could understand the Committee not wanting to stir up drama, they should be accountable to the community that elected them. Natureium (talk) 14:51, 7 February 2019 (UTC)

@Boing! said Zebedee and Natureium: I definitely sympathise and would have preferred a statement last year. But remember, the Committee is a committee with all the advantages and flaws of a committee, perhaps heightened by the fact that it works mainly through email and even in those few times we had voice conferences (none last year I think) only a minority could ever attend. Doug Weller talk 15:08, 7 February 2019 (UTC)

I should note that we had no clue what Alex would say when he resigned. There was no planned "cover-up" or deal to allow a resignation with a misleading rationale; Alex posted what he posted of his own accord, and I did not expect it at the time. At least on my end, what he said caused a fair amount of consternation, because I did see it as hiding the "cloud" under which he resigned from the community. At that point, the Committee had an undesirable choice between publicly contradicting Alex's statement without being able to go into specifics, likely coming off as extremely vindictive in the process, or letting it go now that Alex was not in a position with access to the type of information he had mishandled. There were arbitrators that advocated both views for various reasons, but no majority emerged to post any particular statement until now, obviously. ~ Rob₁₃^Talk 17:55, 7 February 2019 (UTC)

• Consternation is perhaps an understatement for my feelings at the time. I didn't expect him to play it as a real life issue (or an issue with ArbCom bureaucracy which he's also said). Ok, I can understand to an extent why, but it left people feeling sympathetic and I think trusting. I had to bite my tongue (or the equivalent for my fingers I guess) not to say something. Without a statement from the committee there was nothing individual Arbs could say that wouldn't be violating confidentiality. I still think we should have made a statement but we didn't. Doug Weller talk 19:35, 7 February 2019 (UTC)

Perhaps the arbitration committee can set some ground rules ahead of time, in preparation for any future occurrence? Something along the lines that arbitrators agree to allow statements to be issued by the committee on any claims of impropriety, at its discretion? isaacl (talk) 19:08, 7 February 2019 (UTC)

While I can see this value because each ArbCom is not strictly bound by precedent, this would almost have to be stated annually and might not be worth the effort it would take to reach consensus, especially when new arbs are still settling into their roles. Best wishes, Barkeep49 (talk) 20:24, 7 February 2019 (UTC)

The Arbitration Committee has the ability to decide for itself on its own procedures. Everyone running to be an arbitrator would be aware of the procedure ahead of time. If they aren't happy with the procedure, then they should abstain from running. isaacl (talk) 20:47, 7 February 2019 (UTC)

@Boing! said Zebedee: On the other side though, if we cut ArbCom out of the desysop process entirely, it would be difficult to handle desysops based on a case like this that involved private information. That is one of the issues on wikis where there is no ArbCom (and in a lot of those cases WMF has to get involved). --Rschen7754 19:19, 7 February 2019 (UTC)

@Rschen7754: Yes, indeed. I certainly wouldn't want to cut ArbCom out of it, for precisely that reason. I'd see a community desysop as an additional process. Boing! said Zebedee (talk) 11:49, 8 February 2019 (UTC)

Term lengths and reconfirmation is something used on other projects, including with Stewards, to continuously assess community support and trust for admins on other projects. I have no idea whether it would be suited for the English Wikipedia, but it is a system that takes deals with this specific issue. Mkdw ^talk 23:44, 7 February 2019 (UTC)

@Mkdw: the usual arguments again reconfirmation are that (a) any admin that has been active in any remotely controversial area will have pissed enough people off who didn't get their own way that nobody working in those areas would ever get reconfirmed even if they were doing a good job, leading to fewer admins and nobody working those areas; and (b) en.wp has so many admins that the process doesn't scale - RFA would be overloaded by reconfirmation RFAs. While (a) is a risk I don't think it's insurmountable, but it might some fixes to RFA. (b) though is a serious consideration - there are currently 1186 administrators, assuming an even distribution that would mean an average of 3.2 reconfirmation RFAs starting every single day with 1 year terms, 1.6 a day with 2-year terms or 0.8 per day (5.6 a week) with 4-year terms (if my maths is correct, which I'm iffy about). Longer than 4-year terms and you're not really gaining that much additional oversight. Very quickly you'd get voter fatigue, not much scrutiny and overloaded 'crats. I don't know what the answer is but reconfirmation RFAs on their own are not the answer. Thryduulf (talk) 00:14, 8 February 2019 (UTC)

Really great points. In looking at Wikipedia:Perennial proposals#Reconfirm administrators it looks like this has been discussed numerous times. Mkdw ^talk 00:31, 8 February 2019 (UTC)

Simple fix, in my mind: Existing admins are grandfathered in, and for all future admins a system similair to what's already used to elect arbs & stewards is implemented - nominations in a set timeframe (let's say every June), voting over the course of the following month, two-year appointments made in August good for 24 months. Dax Bane 01:09, 8 February 2019 (UTC)

I don't know that it would solve it, given that generally the controversial admins are not the newest ones (both because standards were lower, and because numerically 95%+ of our admins were not elected recently given how RFA is nowadays). --Rschen7754 01:21, 8 February 2019 (UTC)

But it would have the benefit of allaying some of the community's concerns. We might see more admin candidates and more successful RfA's 'cause the community would know that bad admins would not be around forever. And the retainable ones would be retained. Dlohcierekim (talk) 01:26, 8 February 2019 (UTC)

@Thryduulf: ArbCom works in the most controversial areas, such that whatever decision the Committee makes gets heavily criticized. Yet individual members do get re-elected. I think that is indicative enough that the community can be trusted to make an appropriate decision regarding desysopping or reconfirming admins working in controversial areas. It is not working in controversial and/or difficult areas that matters so much as how admins conduct themselves. Working in a difficult area should not be an excuse to behave disrespectfully toward others. And generally it is disrespect that annoys people, not someone handing out a controversial sanction. All good admins handing out a controversial sanction will make themselves available to discuss the sanction, and will be open to reversing the sanction if presented with appropriate arguments and/or consensus that the action should be reversed. However, your other point on the logistics of taking over 1,000 admins through a regular reconfirmation process is well made. SilkTork (talk) 01:35, 8 February 2019 (UTC)

The more formal nature of Arbcom elections may make a difference compared to RFA, as might the frequency of potentially controversial actions (almost all the users who would oppose an RFA in this manner don't get near arbcom as admins have dealt with them already) but my comment was mainly reporting the two most common arguments against reconfirmation RFAs as I remember them rather than expressing my personal opinion. I do agree though that running out of admins is not a significant enough risk to block the idea, especially when compared to the logistical issues which are. Thryduulf (talk) 01:46, 8 February 2019 (UTC)

• As a general comment, the situation was very complicated to navigate because it not only involved the Ombudsman Commission and the English Wikipedia Arbitration Committee, but also the Wikimedia Foundation, for which the non-disclosure and access to private information agreements are signed. Confidentiality surrounds our process because of the nature of the information involved as well as anything related to the OmbCom and WMF, thereby greatly limiting our ability disclose much of anything. I know for many of us, it weighted heavily on our minds as to whether the committee should make a public statement at the time; simply acknowledge Alex's resignation and allow him to leave with dignity; or wait for all involved parties to reach a finding. We did not know how Alex would conduct himself immediately following his resignation or into the future such as requesting advanced permissions. Likewise, Alex was aware of the on-going situation and the potential for the circumstances surrounding his resignation to be made public. These situations are so rare and I imagine the circumstances each time have been very different that for the next time, all we can reasonably hope for is to use best judgement at the time with the available information. Mkdw ^talk 20:45, 7 February 2019 (UTC)

So Alex breached the Checkuser policy, and the confidentiality agreement, and straightforwardly resigned his CU under a cloud. He subsequently filed to run in the Steward elections, where he lied about his reasons for resigning, while seeking re-appointment as a CU. This obviously calls into question his qualifications to be a Steward, and, potentially, his eligibility to even run. You were under no obligation to publicly announce this information. But once the Steward election comes into play, there are very real security concerns here, and surely you are under an obligation to forward this information to the relevant parties "upstairs". I know you guys obviously did the right thing here, but our local Arbcom is not ultimately responsible for oversight of the Steward elections. Were attempts made to notify the WMF and/or the Stewards of this troubling situation? If so, what was their position? If you had not acted, would anyone have done anything? I find it hard to believe that either party would be content to let a former CU blatantly lie to the global community about past misconduct while running for Stewardship. ~Swarm~ {talk} 00:35, 8 February 2019 (UTC)

I agree that it would be good to let the stewards know at least so they can in their personal capacity vote the candidate down, but in the rules there's really not a provision to disqualify a candidate from the steward elections for something like this (just like they could run for ArbCom again). WMF would have to make the call. --Rschen7754 01:26, 8 February 2019 (UTC)

(edit conflict) We know the Committee made the Ombudsmen aware in August. The Ombudsmen processes don't mention informing anyone about an investigation other than the complainer (in this case the Arbitration Committee). My reading of that suggests that once an investigation is complete, the requester is informed of the outcome regardless, and only if wrongdoing was found the subject of the investigation and the board of trustees are informed, the stewards are not directly informed but presumably will, if necessary, be asked by the board of trustees to remove permissions if they agree with the Ombudsmen's recommendations. The Stewards elections are organised by the stewards themselves, and the board of trustees are explicitly very hands-off regarding it. So, even if the investigation into Alex was complete and the allegations were upheld then it seems that the stewards would have no way of knowing this as Alex had resigned his permissions months back and so wouldn't need them removing. Iff this is the case, then it would make sense for the stewards to, in future, explicitly ask the Ombudsmen Commission about candidates, but (a) I strongly suspect that nobody thought before now that this situation could arise, and (b) it's outside en.wp Arbcom's scope. When this incident occurred back in August it was not foreseeable by Arbcom or the Ombudsmen that Alex would stand for Steward. Thryduulf (talk) 01:39, 8 February 2019 (UTC)

The WMF has been aware of these circumstances since the Ombudsman Commission report was filed, both by route of the Ombudsman and directly. From my understanding, all Ombudsman investigations loop in WMF Legal. ~ Rob₁₃^Talk 02:36, 8 February 2019 (UTC)

• Just in case she has any comment here: pinging @Kbrown (WMF): (known around here as Fluffernutter) who is the staff person who seems most closely connected to the OC. I think we all realize that by definition much of what the OC does is completely confidential, but I think some important questions are raised by this situation, like is it normal for issues to take six months to be dealt with, is the staff aware of these long delays, does the resignation under a cloud here impact qualification as a steward, etc? Beeblebrox (talk) 03:18, 8 February 2019 (UTC)

Please, see my opinion here. Greetings, --Galahad (sasageyo!)^(esvoy) 03:36, 8 February 2019 (UTC)

Ok, let me clarify here. I said the activity reports for the last year could be done in an hour. They could. I also said I reviewed the same evidence the OC received and came to my own conclusions in about an hour. I did not suggest that the OC could or should handle a complaint in an hour. I was on the Arbitration Committee here and am well aware of how difficult it can be to keep things moving forward, and also aware that committtee membership has just turned over. I am sure the new members are getting together and deciding how best to proceed in this case, the only question is why the previous committee got the case nearly 6 months ago and failed to take any action. Beeblebrox (talk) 04:27, 8 February 2019 (UTC)

The activity report for the second half of 2018 was just released, and it is quite concerning: [9] Only 2 cases were closed, and 1012 cases are still open. What happened? --Rschen7754 14:41, 8 February 2019 (UTC) Corrected the numbers. --Rschen7754 01:25, 9 February 2019 (UTC)

I suppose it's theoretically possible that 9 of those 10 were reported in December, but it seems unlikely. I'll ask the question on the report talk page. Thryduulf (talk) 14:59, 8 February 2019 (UTC)

Thryduulf, also see meta:User_talk:Teles#Please. The times, when the requests were lodged, will be quite interesting to know:-)∯WBG^converse 15:31, 8 February 2019 (UTC)

These revelations about the apparent ineffectiveness of the OC are arguably more concerning than Alex's violations!   Facepalm It looks like TRM's statements about the commission not even existing are not simply exaggerated rhetoric. ~Swarm~ {talk} 22:44, 8 February 2019 (UTC)

At Wikipedia:Arbitration Committee/Noticeboard/Archive 12#Alex_Shih:_Statement_from_the_Arbitration_Committee, it is said that user:Callanecc and user:Courcelles are remaining inactive when the trustworthiness of a former member of their Arbitration Committee is discussed. You know, there is a rule of thumb about asking for explanations before commenting. And therefore, I am asking. Pldx1 (talk) 09:04, 8 February 2019 (UTC)

My understanding is that these two arbitrators are fully inactive and away from Wikipedia. They may wish to comment when they return. Worm^TT(talk) 09:10, 8 February 2019 (UTC)

Interesting, I note that at least one other member of the previous Arbcom furnished me off-wiki with information about a highly sensitive (oversighted) subject a year or so ago. Alex is a good guy, and was our only hope for the last group of Arbs. This is terribly sad. The Rambling Man (talk) 19:34, 6 February 2019 (UTC)

What, pray tell, is "interesting" about that? --Calton | Talk 18:29, 7 February 2019 (UTC)

I suppose that's euphemistic for implying there was a double standard or uneven enforcement. Dlohcierekim (talk) 19:18, 7 February 2019 (UTC)

It would really depend on what information was shared with TRM - if it was copies of oversighted edits made by TRM then there isn't going to be a significant privacy issue with that in almost all cases; similarly if it was information about TRM then sharing that with TRM is going to be OK generally. Information about what was oversighted and why, without revealing what that information was specifically (e.g. "I oversighted those edits because they accused the subject of serious crimes in contravention of the BLP policy") can be fine also (depending on circumstances, obviously). If it was copies of (potentially) libellous information about a third party posted by someone other than TRM then that's very different. Without more information, that it is not likely TRM can provide publicly, there is absolutely no point to this section. Thryduulf (talk) 21:44, 7 February 2019 (UTC)

In 2015 concerned with the flagrant abuse of wikipedians PII by supposedly trusted CU's (and Cavalry was far from being the first) I did a bit of research (some of the on-wiki questions can be found here which were kindly responded to in part by courcelles at the time) and pretty much came to the conclusion that CU had a)no oversight, b)no active auditing, c)no accountability, d)was actively engaged in processes that were both unsecure by their nature and encouraged abuse. This latest episode where someone was able to abuse CU, when found out about it was allowed to quietly slip off, the wider community was not informed their privacy was at risk, let alone where it was confirmed individuals privacy had been violated they were not directly informed (from reading the above). And lets not get into the legal questions to be asked in light of the UK and EU's GDPR obligations.... As it stands I think its now time to take a look at the community appointing some independant CU auditors, specifically to pro-actively question use of CU on ENWP on an ongoing basis and removing ARBCOM from any CU involvement. Because the current system is not working to prevent abuse and ARBCOM are actively engaged in hiding the abuse. Only in death does duty end (talk) 10:35, 8 February 2019 (UTC)

These are very good points. Up above I said Checkuser is routinely used during RFAs, which prompted responses from Risker, Drmies, and others about how rare it actually is. Of course there's no way for us to know for sure, but I just briefly checked the last couple RFAs, finding Bbb23 striking sock votes left and right. Where does oversight of Checkuser fall? I found another example of Bbb23 running an improper check, but I will not share that publicly due to privacy concerns. Mr Ernie (talk) 13:48, 8 February 2019 (UTC)

Struck comment - explanation: I have misunderstood what happened and parts of the checkuser policy, and no longer stand by the statement that the checks by Bbb23 were improper. Courtesy ping to those who responded TonyBallioni, Drmies, Risker, DoRD, Thryduulf, Berean Hunter - apologies to mass ping but I felt it necessary to correct the record. Mr Ernie (talk) 14:24, 18 February 2019 (UTC)

• • Looking at Bbb23's contributions for 6 December when a couple of those strikings were done, it seems that they were all related to him investigating cases raised at SPI and acting on the results of those investigations (which is exactly what CU's are meant to do) rather than systematically checking RFA voters. Thryduulf (talk) 15:10, 8 February 2019 (UTC)
  • @Bbb23: fixing ping. Thryduulf (talk) 15:11, 8 February 2019 (UTC)
    • Bbb23 also wasn’t the nominator in those RfAs, which was the big concern here. TonyBallioni (talk) 15:23, 8 February 2019 (UTC)
  • Bbb23, thank you for blocking those socks. RfA is troubling enough without socks stirring the shit pot. In the case of JLaw220, for instance, we're dealing with a troll and LTA who tried to exploit American Politics to mess things up a bit. Drmies (talk) 15:54, 8 February 2019 (UTC)
  • I found another example of Bbb23 running an improper check... Mr Ernie, if you're going to make such a provocative claim, you need to either provide evidence to back it up, or you need to retract it. —DoRD (talk)​ 16:27, 8 February 2019 (UTC)
    • Mr Ernie, what DoRD said. You need to account for that. Please email your evidence to functionaries-en@lists.wikimedia.org
       — Berean Hunter (talk) 18:07, 8 February 2019 (UTC)
      • DoRD and Berean Hunter I will send an email to the functionaries mailing list. Risker above stated that checkusers were rare during RFA. I found in 3 minutes of searching at least 2 checks by Bbb23 per RFA, therefore who cares that Alex Shih checked a user in an RFA where he was Nom. My claim was that checks are very common and non-controversial at RFA on new users or IPs. I am quite doubtful that anything happens with Bbb23's C/U permissions (as a result of 1 improper check), as he's by far the most active with at least 2000+ checks per month (about 40% of ALL checkuser actions!), and certainly there is an inherent error rate with non-justified checks. Another question - are checkusers allowed to store the results of their checks off-wiki? Mr Ernie (talk) 18:18, 8 February 2019 (UTC)
        • I believe that you may be assuming that a check was improper. There are probably reasonable explanations. Yes, as examples there is a checkuser wiki where some things may be stored. There is a separate Arb wiki also where things may be recorded.
           — Berean Hunter (talk) 18:30, 8 February 2019 (UTC)
        • Also, one or two checks of sock accounts in an RfA with many dozens of votes is not what I would call very common. —DoRD (talk)​ 18:37, 8 February 2019 (UTC)
        • Again, I wish to point out that the issue with Alex Shih was that he performed a check on an opposer in a contentious RfA where he was the nominator. No one has said that all checks in RfA are prohibited, nor that they don't happen on reasonable grounds. What is prohibited is use of CU for political control, which is what happened here. We want to catch socks in RfA. We don't want nominators checking opposers. TonyBallioni (talk) 18:42, 8 February 2019 (UTC)
• Alex's misuse of CU was detected and challenged by other arbitrators auditing the logs. It resulted in him losing the tools, which the community is now aware of. How on earth is that evidence that there is "no oversight" and "no accountability"? – Joe (talk) 14:15, 8 February 2019 (UTC)

• The structure of the system is supposed to allow self-policing. For example, the Foundation's minimum requirement of two CUs is there so that they can check each other's work. In addition the Ombudsman commission is specifically tasked with investigating complaints. However, no system that requires secrecy will ever be trusted because it is secret and therefore will create innumerable conspiracy theories from those who are that way inclined. There's no fix for this. If CU was removed from en.wp and became a centrally operated service, the same complaints of abuse of CU would be directed at that central service. QuiteUnusual (talk) 16:13, 8 February 2019 (UTC)
  • Yes. Plus, everyone who works at/with SPI knows how much work is being done by CUs like Bbb, Ponyo, DoRD, and others, and what a total mess we'd be in if it weren't for them. It is entirely likely that CU mistakes are being made (but what prompted this discussion was apparently not a "mistake"), given the huge amounts of work that they do; well, it is also extremely like that all admins and all editors here make mistakes. I, for one, am very grateful to those CUs (whom I call the "real" CUs), who do a pretty unthankful job requiring much effort and expertise. Drmies (talk) 17:11, 8 February 2019 (UTC)
    • Drmies: Thank you for posting that; I firmly and heartily agree. These folks do yeoman's work and do not get thanked for it often enough. Beyond My Ken (talk) 05:17, 9 February 2019 (UTC)
• "the wider community was not informed their privacy was at risk" - Never happened. The wider community was never at risk. All of his checks were logged and they don't add up to that many in the scheme of things.
  • Alex Shih CU statistics from Wikipedia:Arbitration Committee/Audit/Statistics
    • Dec. 95 (obtained permissions and ran first checks)
    • Jan. 31
    • Feb. 41
    • Mar. 38
    • Apr. 85
    • May. 25
    • Jun. 99
    • Jul. 124
    • Aug. 43
    • Sept. 0 (no longer had permissions)
    • Total 581 logged checks
• That equates to much fewer individuals actually being checked since checking individuals requires multiple logged steps. The first check gets you IPs but you must then check the different IPs. As an example, a person that has used four IP addresses from distinct ranges would require five total logged checks to complete a single checkuser request on that individual.
   — Berean Hunter (talk) 17:51, 8 February 2019 (UTC)

• Alex Shih has withdrawn his Steward candidacy. --Tryptofish (talk) 22:57, 8 February 2019 (UTC)
• I will just put this out there: stewards (since 2016), some WMF staff, and ombudsmen do have access to the CU logs and can see when checks are run. I don't think all of those groups would idly stand by while enwiki systemically abused CU like some editors above are accusing. --Rschen7754 01:43, 9 February 2019 (UTC)
  • Nor would many experienced CheckUsers on enwiki, for that matter. Alex's issues were especially difficult to address for several reasons. The most severe issues did not involve checks that should not have been performed, but rather handling of data after a valid check had occurred. That doesn't show up in the logs, obviously. We acted rather quickly (in arb time) after invalid checks appeared in the logs. ~ Rob₁₃^Talk 12:16, 9 February 2019 (UTC)

Discerning readers will have noticed that Alex did 91 checks in December. I don't think I knew that at the time. That's worrying in itself. I'd like to suggest to the Committee that it consider not allowing anyone without sufficient CU training to use CU until they have gone through training. By that I mean formal training on both the technical aspects and the policy/ethical/privacy aspects. This should also be done for Checkusers appointed by the Committee, but many of them already have some relevant non-CU experience with SPIs while Arbitrators may never have even read an SPI investigation. I'd like to see a training package put together by our most experienced Checkusers - not just Arbitrators. Doug Weller talk 16:07, 9 February 2019 (UTC)

• I would like to take this course. It would ensure adequate knowledge and avoid stumbling around. It would obviate need for prior technical experience in programming and so forth. As to Alex, I saw that too. Do we need a rule that ArbCom's only Cu in the course of their duties as ArbCOMs? It might avoid blunders and all.Dlohcierekim (talk) 17:31, 9 February 2019 (UTC)

• If such a course were given, which for many reasons I think is highly unlikely, it would only be for CheckUsers.--Bbb23 (talk) 18:20, 9 February 2019 (UTC)

A number of experienced checkusers have hosted trainings in the past for new checkusers and arbitrators. I believe I participated in a training session that Deskana ran when I first became an arbitrator, and I know DeltaQuad has hosted some as well. The content is there, we'd just need to a) find CUs who are willing and available to run the trainings on some sort of regular cadence, and b) formalize it as a requirement. GorillaWarfare (talk) 18:37, 9 February 2019 (UTC)

When I was first elected to arbcom I was told there would in fact be some training. As I recall there was a "live" training session but I was not available at the time, so to this day I've never had any training. However there is material that is sent to new arbs (or at least there was five years ago) regarding both the CU and OS tool sets, and all users of those tools are required to sign off on the m:Confidentiality agreement for nonpublic information. One would hope everyone is actually reading it first but I don't suppose there's any way to check that. Beeblebrox (talk) 18:41, 9 February 2019 (UTC)

I don't think that there is any need for something as formal as a training session that is hosted by a particular person at a particular time. There just have to be some informative reading materials, with someone having kept track of where those materials are, and a willingness on the part of experienced CUs or Arbs to answer questions. None of that would be particularly difficult, and any new CU who doesn't bother to do the reading has no excuse for having failed to do so, once they get caught screwing up. --Tryptofish (talk) 19:24, 9 February 2019 (UTC)

• I am happy to report that I gave such a training session to the new CheckUsers late last year, when they were being on-boarded. Doug was at that training session, so he knows about it, but I assume he means he wants something more enshrined in rule (e.g. you don't get the bit flipped on until you've had training). I agree with that position, and will push for it when we next do functionary appointments. It would be extremely wise to hold off on granting the CU flag until there's been a small group training about the privacy policy and how to perform checks, at a minimum. This is a great idea, Doug. As for the arbs on-boarded this year and any functionaries that need to brush up on their CU skills, I plan to hold a "training for technical newbies" eventually. I meant to do it shortly after January 1, but I've been inactive due to personal issues for the past couple months. I hope to have time to schedule this soon. ~ Rob₁₃^Talk 03:52, 10 February 2019 (UTC)

Please do let me know when that is happening. Part of the reason I'm barely active with the tool is that I'm entirely self-taught in it's use. Beeblebrox (talk) 21:07, 10 February 2019 (UTC)

At a minimum, it will be a week from now. I've been fairly private about this on-wiki up until now, but I recently had an allergic reaction to medication and am still recovering. I expect to be near full capacity in another week or so and can resume my full activity on the Committee. I plan to finally get around to several things once I do. ~ Rob₁₃^Talk 04:31, 11 February 2019 (UTC)

Vanamonde93, Boing! said Zebedee and myself have jointly filed a request for arbitration to request that the committee review Alex's access to the administrative tools. GoldenRing (talk) 21:50, 9 February 2019 (UTC)

Original announcement

• Thanks to all of you, and I hope to see you rejoin the CheckUser/Oversight teams in the future. ~ Rob₁₃^Talk 03:20, 20 February 2019 (UTC)

Original announcement

• I want to be very clear that this is a workflow change. As it stood before, it was very unclear where information related to abusive paid editing should be sent. Sometimes, it went to ArbCom. Sometimes, to the functionaries. Sometimes, to the inboxes of individual CheckUsers. We're throwing it all in one inbox to make it easier to accumulate evidence, track specific paid editing rings, and redirect things to the right place as necessary. If it should have gone to WP:COIN before, it should still go there. If it should have gone to ArbCom before, it will be forwarded along. If it should go to WP:SPI, we'll forward it there, too. This will just help us process the evidence that genuinely does need to be private but previously had no real "home". Feel free to ping me with any questions. ~ Rob₁₃^Talk 16:52, 14 February 2019 (UTC)

• BU Rob13, does this (in any form or manner) affects en-orangemoody; (which (till now) housed OTRS tickets about paid editing and was visible to every OTRS member from en)? ∯WBG^converse 18:23, 14 February 2019 (UTC)
  • @Winged Blades of Godric: That queue still exists at this time. I consider it up to the community what they wish to do with it, but my personal preference would be to redirect it to paid-en-wp. In practice, the people who man that queue rarely had the tools to properly investigate, and emails were often forwarded to ArbCom or the functionaries from there. Funneling them all to one place and allowing them to be re-routed as appropriate is best. I imagine if we kept it open, agents would frequently forward tickets to paid-en-wp anyway. But again, that's my individual opinion, and I don't see it as ArbCom's place to make the decision to redirect that queue. ~ Rob₁₃^Talk 19:39, 14 February 2019 (UTC)

• I think this is a very good idea, so thanks for setting it up. It might be a good idea to link to it at the top of WP:COIN. --Tryptofish (talk) 18:31, 14 February 2019 (UTC)

• I've updated the relevant bit of the header. Wikipedia:CheckUser#Contacting a CheckUser also needs updating with the other new OTRS queue.Galobtter (pingó mió) 19:19, 14 February 2019 (UTC)

• Eh, I'm not exactly a fan of that wording. Nothing prevents anyone from directly contacting a functionary they are familiar with, and I wouldn't want to change that. This just helps for people who have no clue who is good to talk to. It's definitely an improvement, but people should also feel comfortable talking to any of us if they want to, whether for paid editing or for any other reason involving suspected socking. TonyBallioni (talk) 20:08, 14 February 2019 (UTC)

• I've made a revision of that wording: [10]. --Tryptofish (talk) 22:47, 14 February 2019 (UTC)
• My thinking mainly was that people who are already familiar with a functionary will be the sort of experienced editors who won't be reading the header at WP:COIN; the sort of people who will be consulting there will be exactly the sort of people who have no clue who to talk to. Galobtter (pingó mió) 08:59, 15 February 2019 (UTC)

As one of the people who responded to many of the concerns raised at en-orangemoody, I can say that dealing with most do not require CU ability. Most are from people who have received solicitation to have an article created about them or their business for pay. These paid for Wikipedia companies are doing massive mailouts, it appears, as well as pretending to be from "Wikipedia". Our work mainly involves informing the people who mail OTRS that these companies are a scam and infringing on our TOU.

I see the new mailing list as something more for Wikipedians who find concerns about paid editing based on off Wikipedia evidence or see a pattern they want investigated that they do not want to expose to paid editors. My two cents. Doc James (talk · contribs · email) 19:57, 14 February 2019 (UTC)

• If the orangemoody-en queue is being used more to address article subjects, I see that as a valid continued use of the queue, certainly. I assumed such emails just went to Quality, where we route most queries by article subjects. This queue is indeed intended more for Wikipedians, not article subjects. ~ Rob₁₃^Talk 21:32, 14 February 2019 (UTC)
• As a side note, I'd like to thank DGG for his part in helping get these queues created. They would not exist were it not for his passion for addressing paid editing issues. His ideas and voice were invaluable over the past year as we investigated how to improve our workflow in this area. ~ Rob₁₃^Talk 21:36, 14 February 2019 (UTC)

• This sounds like amateur fake security.
  Why are not paid-en-wp@wikipedia.org and checkuser-en-wp@wikipedia.org considered too insecure for inviting submission of private information?

If there is evidence that genuinely does need to be private, should it not be ensured that it is kept private.

Email addresses invite unencrypted, plain text messages. Emails are like letters without envelopes, letters that are copied at every step of the process of transmission.

Who are recipients of these lists? Can we confirm who receives, and why they are on the list, and what they understand as to their responsibilities with private information received from it. Can they maintain their own personal unofficial archives containing private information?

Is there any access log of access to secured private information?

Why is there not a secure upload site for private or sensitive information?

Why is there not a principle of "need to know" for access to others' private information? And a record of who accessed that private information?

--SmokeyJoe (talk) 23:32, 14 February 2019 (UTC)

I feel like you need to re-read the announcement of these new queues. They will only be available to person who already have CU access, and all of those people by definition have signed off on Wikipedia:Access to nonpublic information. Beeblebrox (talk) 01:02, 15 February 2019 (UTC)

What Beeblebrox said, basically. These e-mail addresses lead to OTRS queues. The OTRS system already handles our queue for oversight requests. Everyone with access to these inboxes will have CheckUser on enwiki and are bound by the Access to nonpublic personal data policy. ~ Rob₁₃^Talk 02:01, 15 February 2019 (UTC)

I feel you ignore the inherent vulnerability of email to systematic eavesdropping, for example, if workarounds are not used. This is before they hit the OTRS system. "Everyone with access ... bound by ..."? Nice theory. Have there been no leaks to date? Amateur fake security. --SmokeyJoe (talk) —Preceding undated comment added 03:52, 15 February 2019 (UTC)

It's probably worth pointing out that checkusers already use an email list to communicate privately amongst ourselves... GorillaWarfare (talk) 04:38, 15 February 2019 (UTC)

Yeah, I'm not sure what is setting Joe off here, other than not being aware of how much functionaries use email already. Checkusers, oversighters, and arbcom have all used email for a very long time. If Joe has a better idea for off-wiki communication that is more secure I'm sure we'd all like to hear what it is. Beeblebrox (talk) 05:23, 15 February 2019 (UTC)

Beeblebrox, what set Joe off is a fair question, and I had to think about it. It’s about the the open public invitation to send sensitive invitation to a specific email address, which the public might consider to imply a competent responsibility for security of that submission, and this is not the case. And it is a flag saying “hey, look here”. It’s not so much actual risks with serious consequences. These incoming emails are easily eavesdropped, by some, but not by typical Wikipedians, and people with the capability are very unlikely to care at all about Wikipedian personal sensitive information, such as Joe’s real name. Someone else’s personal information is not as interesting to bad people as banking information, or password reset emails, but the person submitting the personal information or the subject of the personal information submission might still be worth a bit more security. —SmokeyJoe (talk) 00:51, 17 February 2019 (UTC)

Checkusers emailing each other? Security through obscurity goes a long way. They might email unencrypted, but it would only be random fragments, and sender and receiver emails addresses scattered. Declaring a specific Wikipedia.org email address to receive all sensitive information is just begging for a listening post to collect every email sent to that specific address. Easily done, probably already being done. I suggest a secure website and form for receiving sensitive submissions. Ask the WMF to do it properly. I don’t suggest abandoning email, but do suggest discouraging sending wholesale sensitive information in full context to a known special address from distant locations. —SmokeyJoe (talk) 08:18, 15 February 2019 (UTC)

@Emufarmers and Matthewrbowker: As administrators of the OTRS system could you maybe address the security concerns about OTRS? --Cameron₁₁₅₉₈ ^(Talk) 04:10, 16 February 2019 (UTC)

OTRS is what we already use for oversight and have been using it there for years. I’m sure OTRS can be improved (it kinda sucks as a software system from a user standpoint), but I don’t think we’ve ever had a private data leak from the oversight OTRS, and it gets multiple tickets a day. TonyBallioni (talk) 04:14, 16 February 2019 (UTC)

One designs security for the threats one realistically expects to face. We aren't a newspaper in need of a way for whistleblowers to leak secret documents without getting caught; we're an encyclopedia that occasionally needs a way for users and article subjects to get in contact without the whole world seeing it on the wiki. There are no doubt more secure methods than email, but the system we have seems sufficient for our actual needs. Novusuna ^talk 06:50, 16 February 2019 (UTC)

It's also worth noting that the information we expect to receive is not protected by the privacy policy or any legal obligations. It merely would be a violation of our outing policy to post on-wiki, in almost all cases. I don't think we can realistically expect ourselves to NSA-proof our mechanism for receiving a link to a promotional editor's LinkedIn profile that was findable via Google. That's extending security to the point of absurdity. ~ Rob₁₃^Talk 02:54, 17 February 2019 (UTC)

“concerns related to privacy or outing”, “paid-en-wp@wikipedia.org”. There is a wide mile of options between the current that begs to be email-eavesdropped, and NSA-proof mechanism. NSA-proof mechanism is a ridiculous extreme. A secure webpage with an upload form would be appropriate. Are people’s concerns related to privacy or outing to be taken seriously? Your response is not serious. Email submission does not take it seriously. Expect to find every such email to one day appear online. Maybe not every such email, maybe just every such email originating from overseas. —SmokeyJoe (talk) 03:24, 17 February 2019 (UTC)

Sorry, I really don't understand what risk you think arises specifically from the use of email for this purpose. We already use a similar email/OTRS setup for oversight (which is entirely about "stuff that shouldn't be public"). If you contact arbcom about something private, you're using a mailing list. What specific technical breach are you concerned about? While I wouldn't say I'm a huge fan of this idea, because I think it legitimizes people spending their time on distracting Internet-detective stuff, I don't think it makes sense to object on "data security" grounds. Realistically, the security risks for Wikipedia-related data mostly involve carelessness or intentional release by authorized users, not "eavesdropping". There's no risk here that doesn't already exist. Opabinia regalis (talk) 05:41, 17 February 2019 (UTC)

If I understand half correctly, oversight is about removing information currently available. Someone will email you asking you to remove it. If it is a full set of personal information, the email needn’t, shouldn’t, include, in the email, the full details of the the sensitive information wanted removed. So eavesdropping these emails would likely contain hints at information, not the information itself.
This latest announcement appears to invite outsiders to email private sensitive information, presumably to explain thing privately, and to do it by emailing a very specific address with servers at a known location. So, these emails will individually contain the full set of personal information, in context. Not particularly earthshatteringly scary, but very embarrassing if it all gets dumped publically at some future time.
This massive weakness exists in the delivery trail heading towards Wikipedia.org. Internal emails are much less vulnerable, and obscure, existing in much noisier environments in shorter exposed routes. Distant emails, eg any from Asia, are the most obviously vulnerable.
I am surprised at the lack of appreciation. I guess you don’t have experience working within secure systems, not NSA, not legal, not banking, not even HR. I suggest that if you are curious, google “email eavesdropping”, and if you care, ask any WMF tech for advice. I suggest that any invitations to supply personal information to Wikipedia/WikiMedia should point to a secure webpage for sending that information. Don’t put the actually sensitive information unencrypted in any external email. Most people will still email, but when something goes wrong at least it won’t be Wikipedia’s fault. Most people’s private information is completely uninteresting to anyone, but that is not the point. —SmokeyJoe (talk) 06:09, 17 February 2019 (UTC)

I know privacy is prized on Wikipedia but no need to be paranoid. Seriously, when you can go on the Dark Web and find social security numbers, contact information and medical records, is it likely that email through Wikipedia channels is going to be a target? I mean, I know that everything is potentially vulnerable but the likelihood that an email about a COI issue on Wikipedia is going to be a target for hackers to dump online is an unlikely scenario. I think we don't need to consider the means of ultimate security but what is good enough for Wikipedia's purpose. This isn't national security. Liz ^{Read! Talk!} 06:36, 17 February 2019 (UTC)

TLS encryption of emails is industry standard, at this point. What major email provider is sending emails unencrypted in 2019? Further, to eavesdrop on these hypothetical unencrypted emails, one would have to either compromise every possible sender email server, the recipient email server, or a sufficient number of major intermediary email servers to capture all email traveling between the two. The recipient email server is secured by the WMF. If a Wikipedian manages to compromise GMail, honestly, god bless. We can't be expected to prevent that. And no-one trying to compromise these sorts of emails would have the resources to set up intermediary email servers and popularize them to the point that a large amount of traffic flows through them. That's government-level work that would take a tremendous amount of resources. A script kiddie sitting at home with a server would not be able to do that. And even if they did, they could only eavesdrop on emails being sent unencrypted by the sender, which would be against industry standards for email. The overwhelming majority of email leaks come from unsecured recipient email servers, which either do not encrypt emails or have other vulnerabilities that allow unauthorized access. I trust that the WMF is sophisticated enough to employ proper data security practices when it comes to OTRS. The OTRS software comes with the appropriate tools to employ such practices. If they are not, that would be an issue that would need to be taken up with the WMF, not ArbCom, who have no ability to alter the WMF's data security practices. ~ Rob₁₃^Talk 13:44, 17 February 2019 (UTC)

I noticed that you said that The recipient email server is secured by the WMF. If that's the case, then it seems to me to be all that we can reasonably be expected to do. --Tryptofish (talk) 20:09, 17 February 2019 (UTC)

If it puts people at ease, I will inquire about the exact security methods used to encrypt OTRS the next time I'm on the phone with Trust and Safety, but yes, in my experience, the WMF does practice appropriate data security methods. ~ Rob₁₃^Talk 22:48, 17 February 2019 (UTC)

An easy example of a reasonable solution could be: Use a role account (eg) for receipt of web-form submitted email. Note the "Communications and privacy" statement that should accompany every invitation for submission of information. This can be reasonably done. --SmokeyJoe (talk) 00:55, 18 February 2019 (UTC)

I'm happy to create a role account as an alternative to directly emailing paid-en-wp, but not as the only way to email. We don't necessarily want to require someone to create an account to email us. Further, I would like to hear you articulate how you believe this would actually be more secure. The only thing it prevents is the potential for unencrypted emails being sent, but that, in practice, doesn't happen at any major free email providers in 2019. Even Yahoo supports STARTTLS. I really want to emphasize that when you hear about emails being "hacked" these days, it's because of a lack of encryption on the recipient email server, which is not happening here. That was true of the Sony hack, Hillary's emails, etc. ~ Rob₁₃^Talk 20:05, 18 February 2019 (UTC)

A better culture of respecting security of for others’ private details is an important part of security. TLS is good, but email is still vulnerable. Also consider less US-centric considerations. Why are you trying to negotiate or deal with me? Ask an IT professional. Ask whoever wrote that advice templated at User:Arbitration_Committee. —SmokeyJoe (talk) 05:25, 19 February 2019 (UTC)

You have had it explained, multiple times, why Wikipedia is fine with its users emailing. Please stop talking in a tone of voice that suggests otherwise. AGK ■ 06:41, 19 February 2019 (UTC)

You know that I respect you, Joe, and we've worked together many times, so please take this in the spirit it is given. I fully appreciate your concerns about privacy, being the usual "privacy hawk" on the Committee, but it does not sound like you understand the actual technical considerations that go into email as a secure method of communication. Encrypted email is secure. There is no computer in the world that can perform sufficient calculations to brute-force TLS within a reasonable time horizon. Encrypted email cannot be eavesdropped upon. The only technically/financially feasible attack vector to get at all of the email paid-en-wp is receiving would be the recipient email server, which has appropriate encryption to make such an attack impossible, barring as-of-yet-unknown hypothetical vulnerabilities, which could affect any method of communication. The WMF is extremely aware of data security concerns and works to secure all private user data that it retains through Wikipedia, as well as all private information retained in the OTRS system. We have asked IT professionals, in the sense that the WMF has plenty of them on staff to handle these concerns. The creation of these queues was specifically passed by the WMF, including their Legal department, which would not have okayed this method of receiving private data if they believed it exposed the WMF to legal liability through likely data breaches. I don't know who wrote the advice templated at Arbitration Committee, but I consider it out-of-date given the technology that has been developed and adopted to encrypt emails. Email is no less secure than any other online method of communication when properly encrypted. ~ Rob₁₃^Talk 18:05, 19 February 2019 (UTC)

The "advice" on the Arbitration Committee page was added following a leak of the archives through unknown means many years ago. Risker (talk) 03:31, 20 February 2019 (UTC)

AGK, I have only had it explained to be that the Arb Com community has a long history of sloppy respect for security of other’s personal details, and that the Arb Com community is overconfident in their historical practices. This, I call a red flag for unconsidered vulnerability.

Rob, “Email is no less secure than any other online method of communication” is most definitely wrong, granted you said “when properly encrypted”, but it is an unresolvable debate as to what is “properly”. Email is not secure. TLS is good, but backdoor decryption exists. Few can decrypt live, but the message is in the open for free copying, and the source and destination are flagged. It can be decrypted later. Backdoor decryption keys being one big example. You probably trust the US government to not release the contents, but do you trust them to not lose control of the backdoors? Do you trust the current encryption to remain secure indefinitely. The Chinese are accumulating massive repositories of data, way beyond their capability to process, do you trust them to keep it secure. Of all internet traffic, little is as easy to sort as emails.

I have read Wikipedia_talk:Conflict_of_interest/Archive_27#RfC_discussion and am comfortable with the response barring this issue. For the first time, ArbCom is openly inviting submissions of private/personal/sensitive information. Doing so demands some statement of what responsibility, if any, ArbCom takes for the security of the submitted information.

The User:Arbitration Committee disclaimer “Arbitrators usually seek to treat communications with the committee, including emails, as confidential. That said, we cannot guarantee against public disclosure for a number of reasons …” should have preceded the announcement of the email address paid-en-wp@wikipedia.org

Yes, please create a role account as an alternative to directly emailing paid-en-wp. User:Arbitration Committee, with its more-than-email-secure upload method and upfront disclaimer, provides an excellent example.

If you think the advice is out-of-date, please get a professional to advise. Email, in general, is the least secure method of electronic communication. Tell me you that you have had an employed IT professional tell you otherwise and I will shut up and go away. The vulnerability of email is accepted truth in my world.

I made no allegation that WMF does not practice appropriate data security methods. But I note you further blur the line between ArbCom and WMF. Are they the same? Is ArbCom bound by the https://foundation.wikimedia.org/wiki/Privacy_policy My reading is certainly “no”. I think the announcement’s audience will include many who will be confused on this point.

WMF legal approved? WMF legal were not asked to comment on this specific question. WMF legal said “We applaud the user communities for setting high standards of privacy for themselves beyond what the law requires.” There is no doubt that I am asking for a standard highly that what the law requires. I am speaking your (ArbCom’s) ethical responsibility to those who you actively invite to submit private data.

If you think I am wrong, there is no need to prove it. Just thank me for my comments. This conversation has long since become tedious. Can we agree to read everything I have said as “please create a role account as an alternative to directly emailing paid-en-wp”? --SmokeyJoe (talk) 03:28, 20 February 2019 (UTC)

SmokeyJoe, you seem to be confused about the new OTRS queue. The general public including our editors will email links where someone is advertising publicly that they will write articles for a fee and within the reviews someone thanked them for writing their article. The person emailing would link to the article and the editor and point out that they haven't disclosed that they are a paid editor. That is, generally speaking, the kind of reports that are expected. This information would constitute outing if posted on WP. Previously, the public were choosing to send many of these requests to the functionaries email list which isn't what it was intended for. It has nothing to do with the bureaucrats and not all of the checkusers are involved in investigations on undisclosed paid editors. It is unwanted emails in their boxes and the new OTRS queue is the new channel for that.

I think that you may be concerned about the checkusers' role in this and the data that they have access to. Checkusers log into the OTRS system on a secure server and post via an input system much like you have described above that you want implemented. Checkusers aren't emailing to this system. At no point will cu data be going out to those that emailed in. You have been going to bat and fighting to defend the info about those paid editors but not any kind of confidential data on our end. There is no need for checkusers to "create a role account as an alternative to directly emailing paid-en-wp" and regular editors shouldn't. No need.
 — Berean Hunter (talk) 12:57, 20 February 2019 (UTC)

• Can someone confirm what has happened to the "orangemoody-en queue" cue? User:BU Rob13. Doc James (talk · contribs · email) 15:31, 1 March 2019 (UTC)
  • @Doc James: Please see my response to Winged Blades of Godric above. ~ Rob₁₃^Talk 15:31, 1 March 2019 (UTC)
    • Oh, I had also responded to you up there, as well. Did you have a more specific question? ~ Rob₁₃^Talk 15:33, 1 March 2019 (UTC)
      • Wondering if that cue was redirected in the end User:BU Rob13? I used to have access to tickets like this[11] but do not longer. Doc James (talk · contribs · email) 15:37, 1 March 2019 (UTC)
        • @Doc James: It was not redirected; that's a community decision, and the Arbitration Committee won't get involved with that. That individual ticket was transferred over to paid-en-wp, largely because it involved something that I was actively investigating at the time. ~ Rob₁₃^Talk 15:42, 1 March 2019 (UTC)
          • Ah okay. You had simple moved the ticket out of that cue. Doc James (talk · contribs · email) 15:55, 1 March 2019 (UTC)

Reading the Manning case motion overleaf has led me to wonder if there's a page anywhere that presents all extant remedies and sanctions in a hypertext form, perhaps as some kind of expandable tree. Is there?  — Scott • talk 17:01, 26 February 2019 (UTC)

Do you mean Wikipedia:Arbitration enforcement log? Bri.public (talk) 17:15, 26 February 2019 (UTC)

No, that's a list of all the things that have been done to users (sounds dramatic, but I just mean blocks and so on) as a result of AC decisions. I'm thinking of something more akin to a book of law that tells you what's still in force and what was repealed by what.  — Scott • talk 21:32, 27 February 2019 (UTC)

As far as I know, there is no 'compiled' block log. Those would be found in each specific editor's block log or in theory, you could look at Special:WhatLinksHere/Template:ArbComBlock. Editing restrictions are logged at Wikipedia:Editing restrictions#Placed by the Arbitration Committee. Mkdw ^talk 21:53, 27 February 2019 (UTC)

That is an great question by Bri.public. Where can we find the list of in-force sanctions on topics/subjects as decided by Arb Com? Britishfinance (talk) 22:08, 27 February 2019 (UTC)

@Britishfinance: All ArbCom- and community- authorized topic restrictions can be found at WP:GS. ArbCom-authorized discretionary sanctions are found at Template:Ds/topics/table. Kevin (aka L235 · t · c) 22:16, 27 February 2019 (UTC)

thanks. Britishfinance (talk) 22:18, 27 February 2019 (UTC)

Scott, You know that is a decent question. We have Wikipedia:Arbitration/Index/Cases, but that does not comprehensively display previous motions (located: Wikipedia:Arbitration/Index/Motions). This is probably owed to Arbcom's quasi-judicial and quasi-legislative character. Separately, in crafting general statutes, revisers generally distinguish between private acts and public acts. However, that would be if we were looking for something more similar to the United States Code as opposed to the United States Statutes at Large. The latter does not tell you what is still enforced. We would probably want something similar to Case law, but even then that isn't really it either. For every case ArbCom rules in, they have both findings of fact and remedies. It's unclear which would need to be included. That's all I got. ―MattLongCT -Talk-^☖ 17:49, 1 March 2019 (UTC)

Original announcement

Welcome back! ~ Amory (u • t • c) 22:48, 17 February 2019 (UTC)

I was going to say that :/ Natureium (talk) 22:52, 17 February 2019 (UTC)

I'm glad. DlohCierekim (talk) 20:19, 27 February 2019 (UTC)

I must say that I am extremely happy to see you in the admin newsletter. Welcome back TNT! --TheSandDoctor ^Talk 23:10, 4 March 2019 (UTC)

Original announcement

Miniapolis, I thank both you and Bradv for the notifications! However, I small little nitpick note question. I believe that BU Rob13 did not intend for the parts that were stricken out to remain in the case text. Generally, that strikeouts are indications of where text is to be removed in an amendment, and underlined phrases indicate where text is to be added in its stead. Is this right? Please feel free to correct me or say that I am wrong if so. I am not up-and-up on Arbitration Committee procedure. ―Matthew J. Long -Talk-^☖ 17:53, 22 February 2019 (UTC)

It's my understanding that motions should be copied verbatim (the strikeouts and underlinings are for the benefit of readers monitoring changes), but you may be right. Pinging L235 for clarification. All the best, Miniapolis 18:00, 22 February 2019 (UTC)

@Miniapolis: It was indeed my intention that the strike-outs/underlines be removed on the case pages. They were intended as reading aids on the motion page, nothing more. The old version can remain either in a collapsed section (as is currently the case) or via a link to the old version, either of which sufficiently allows editors to track changes. Please note that the second clause of the first amendment on GGTF still needs striking; that one can remain struck, since it's just part of a larger motion that was rescinded. ~ Rob₁₃^Talk 19:18, 22 February 2019 (UTC)

Clause 2 struck; thanks for picking that up. According to the clerk procedures (unless I'm mistaken), motions are copied verbatim. Miniapolis 20:10, 22 February 2019 (UTC)

Maybe I'm not reading this change correctly but, basically, this change is saying nothing is changed. Am I right? If not, can you sum up these changes in 25 words or less? Liz ^{Read! Talk!} 01:59, 23 February 2019 (UTC)

Old, redundant discretionary sanctions have been merged into the Gamergate sanctions. NinjaRobotPirate (talk) 12:31, 23 February 2019 (UTC)

Gotcha. Thanks for summing it up. Liz ^{Read! Talk!} 06:14, 24 February 2019 (UTC)

@Liz: Yes. Nothing has changed from a functional perspective. We've just consolidated certain discretionary sanctions and pointed people toward the relevant active sanctions in old cases. ~ Rob₁₃^Talk 19:22, 27 February 2019 (UTC)

Thanks, BU Rob13. I'm out of practice of interpreting arbitratorese into plain English. But I know arbitrators have to cover all bases with their language of their decisions, amendments and motions. Liz ^{Read! Talk!} 05:08, 28 February 2019 (UTC)

• Just read this case for the first time. Crazy how different things were a few short years ago. ~Swarm~ {talk} 05:34, 28 February 2019 (UTC)

  Swarm, Can I just say how both lucky and unfortunate it is that I made this motion given recent events since we don't need to have the debate over whether discretionary sanctions already apply. –MJL ‐Talk‐^☖ 19:54, 5 March 2019 (UTC)

@MJL: Crazy how naïve it was for me to leave that comment, thinking things had changed. Lol. ~Swarm~ {talk} 21:18, 5 March 2019 (UTC)

Swarm, meh. Any reasonable person would have assumed this would not have come up again. I am, however, unreasonable. –MJL ‐Talk‐^☖ 03:52, 6 March 2019 (UTC)

¯\ _(ツ)_/¯ --~Swarm~ {talk} 05:01, 6 March 2019 (UTC)

Original announcement

• Steward @MarcoAurelio: has processed the access removal. This really only has impact the local communities logs, but as this account was already globally locked, using the "steward if necessary" option seems out of order. With the lock in place, the emergency was stopped and the rights change shouldn't have necessitated that venue. — xaosflux ^Talk 18:32, 2 March 2019 (UTC)
  • @Xaosflux: From my perspective, I have no clue when the account will be unlocked, and I have no clue what steps will have been taken to re-secure the account when it is unlocked, if any. The vast majority of compromised accounts result from re-used passwords. Nothing prevents the admin from putting the exact same password back on their account or another already-compromised re-used password. A conversation is needed before we can determine that the emergency is actually over. I looked for a bureaucrat on IRC first, and finding none, I looked for a steward. ~ Rob₁₃^Talk 18:36, 2 March 2019 (UTC)
    • @BU Rob13: just to be clear, I 100% agree that access should have been removed, and that the situation needs to be reviewed prior to a restoration, just that with both a lock, and a local block in place, the urgency was diminished. — xaosflux ^Talk 18:43, 2 March 2019 (UTC)
      • The lock could be lifted at any time. It's often lifted quite quickly. The local block does not prevent access to important parts of the administrative toolset, such as the ability to view deleted content, from my understanding. Please correct me if I'm wrong. That is both practically and legally problematic. ~ Rob₁₃^Talk 18:44, 2 March 2019 (UTC)
        • The view-delete part is correct. I'm not sure about the "quickly" component on unlocks. Outside of IRC, there is a tool listed at the top of WP:BN to help find recently active crats. Again, this isn't any sort of 'big deal' - but when we can keep things on the local logs it makes it easier for others to review in the future. — xaosflux ^Talk 19:09, 2 March 2019 (UTC)
          • I agree with Xaosflux; if you can't log in at all, you won't be able to use viewdelete or any other admin rights, and the how-will-you-prevent-recurrence conversation can happen before the account gets unlocked. Not a huge deal of course (if locking is warranted, less-than-locking isn't unreasonable), but just a bit of pointless process in my opinion. Nyttend backup (talk) 21:49, 2 March 2019 (UTC)
            • ArbCom doesn’t decide when to unlock. The WMF does. TonyBallioni (talk) 22:07, 2 March 2019 (UTC)
            • (edit conflict) Unlocks are handled globally by the stewards or the WMF and could happen at any time. For instance, Killiondude was unlocked less than two hours after the initial lock and only 20 minutes after he was desysopped locally without any notice to the Arbitration Committee. We cannot guarantee a conversation surrounding account security occurs before access to the tools is restored except through swift local desysopping. I consider that to constitute an emergency situation, which is also what WP:LEVEL1 spells out.

              We have only 20 bureaucrats, with only 15 editing in the last week. None are in IRC with any regularity, so it is not particularly easy to contact them in real-time. The community shut down the bureaucrat listserv which could have allowed relatively quick contact through mobile devices. By contrast, the stewards have a listserv. Ten are active on IRC right this second. If I need something done quickly and our procedures allow me to go to either group, it shouldn't be surprising which sounds more appealing. It would be my personal preference to use the local bureaucrats to accomplish desysopping in emergency scenarios, but I don't consider that particularly viable at the moment. ~ Rob₁₃^Talk 22:21, 2 March 2019 (UTC)

            • BTW for those wondering, this page mw:Extension:CentralAuth#Locking and hiding global users confirms that global locks also logout/end any existing sessions. Nil Einne (talk) 12:54, 3 March 2019 (UTC)

I agree that Stewards should be contacted immediately, at the same time as bureaucrats, for emergency desysoppings. However, as a user cannot log into a globally locked account, there was no obvious emergency whilst the account remained globally locked. BU Rob13, am I right that the emergency you perceived was that the account might be unlocked (without consultation with ArbCom) before a bureaucrat was available to action the desysop request locally? Why would someone unlock the account before receiving confirmation that steps have been taken to remove sensitive permissions or establish that it is no longer compromised? WJBscribe (talk) 12:41, 3 March 2019 (UTC)

Compromised accounts are not unlocked without evidence that the correct owner is back in control. Most unlocks are done by T&S, though if stewards are able to confirm that the owner is ready to take back their account then we occasionally do the unlocks as well. While I can't speak for the rest of the group, when unlocking I confirm that the user's email/password has not changed (and thus that they will be able to take control after being unlocked), and would remove any sysop+ permissions before unlocking just to be safe. -- Ajraddatz (talk) 17:00, 3 March 2019 (UTC)

I would not unlock in any circumstances, WMF has the resources to verify that the accounts are really in the good hands (like, performing the verification for what Ajr mentioned), we don't. — regards, Revi 01:10, 4 March 2019 (UTC)

• If the global lock effectively prevents all access to the account entirely, then the desysop portion (following a global lock) is not an emergency and should be handled locally so the logs can be viewed and followed locally- this is one of the primary reasons bureaucrats were given the ability to remove adminship. Unclear whether it was the committee that asked stewards to desysop or whether MarcoAurelio took that step on their own. All acting in good faith of course, but this procedure should be clarified for posterity. –xeno^talk 11:01, 4 March 2019 (UTC)

  @Xeno: I was asked by the Committee and before that, BU Rob13 and myself had a little chat on IRC in which I asked him if he looked for local bureaucrats. He told me he did, and could find none, thus that's why I proceeded to desysop. Thanks, —MarcoAurelio (talk) 12:22, 4 March 2019 (UTC)

  Thanks MarcoAurelio. Was that before or after (or coincident) with the global lock? It does seem that BU Rob13 did not fully understand the scope of a global lock (above he indicates his belief at the time that deleted edits could still be viewed by a globally locked account, which is apparently not the case). An opportunity for Stewards to provide guidance/clarification in a future case. (fwiw, the best place to find a local bureaucrat is by posting to WP:BN; while some of us are less active we do check our watchlists and BN frequently). –xeno^talk 12:29, 4 March 2019 (UTC)

  It was after the global lock, which I also performed myself. While it is true that locked accounts cannot login while locked, it is also true upon my experience that those locks can be as short as minutes or stay forever if the office cannot verify the ownership of the account. We play no role after the account is locked as compromised, as Revi said; nor we know what the office do to verify that everything is alright before restoring access. Given that there was an ArbCom request, local policy allowance and we were told that no bureaucrat could be found at that time (something that I did not question), I decided to go ahead and desysop the user to further protect the project as the ArbCom requested. I don't think I can question ArbCom mandates on desysops, and delaying it would've seemed reckless to me when we're talking about compromised accounts. —MarcoAurelio (talk) 12:57, 4 March 2019 (UTC)

  Thanks Marco, I have no complaint about your actions and it is permitted by policy. I do think this whole “the accounts could be unlocked at any time!” needs further discussion/investigation. Not sure why an account would be unlocked without due process and while still holding advanced permissions, and why it seems like there is no set procedures, checks, or balances, to lifting the lock. A bit out of my depth, I think. –xeno^talk 13:08, 4 March 2019 (UTC)

  The question of whether the desysop should have been done by a bureaucrat or a steward is a minor procedural one, ultimately only effecting which log the action ended up in. I think it's common ground that no bureaucrat was [known to be]* around, the question is whether, after the lock was performed, the desysop could have waited minutes/hours for a local bureaucrat. But as I said, it's a fairly minor point. I agree with Xeno (talk · contribs) however that a more concerning issue has arisen from this discussion, which is why there appears to be so much uncertainty about the circumstances in which a global lock might lifted... WJBscribe (talk) 13:16, 4 March 2019 (UTC)

  *added in light of Xaosflux's comment below that he was online at the time and edit conflicted with MarcoAurelio... WJBscribe (talk) 15:09, 4 March 2019 (UTC)

  @Xeno and WJBscribe: I think the office has their own internal procedure of course and I have no reason to believe that they are unlocking accounts without verifying that everything is okay. I just happen not to know who the process is, and perhaps we would not know it because of the potential of social engineering. Best regards, —MarcoAurelio (talk) 13:32, 4 March 2019 (UTC)

Another question this raises, though not one for lengthy discussion here, is whether we need a couple more active bureaucrats. Newyorkbrad (talk) 13:26, 4 March 2019 (UTC)

@Newyorkbrad: There is a little bit of discussion of that subject at WP:BN#Inactive bureaucrat removal. However, I don't think there has ever been a time in the project's history when bureaucrats were sufficiently numerous and active that we were able to provide the same 24/7 emergency response that the Stewards do... WJBscribe (talk) 13:37, 4 March 2019 (UTC)

Perhaps given the untimely demise of our mailing list, we need some kind of batcrat signal that can be activated that can reach bureaucrats on their mobile devices on an opt-in basis. Discussion for a different venue tho. –xeno^talk 14:00, 4 March 2019 (UTC)

@Newyorkbrad: agree with @WJBscribe: I don't think we're every going to need a crat sitting in an irc channel 24 hours a day, and global locks are the best way to deal with compromised credentials. As far as availability I know I was online when all this was going on, in fact as soon as it was requested at BN I tried to process but got a rights change conflict with MarcoAurelio. — xaosflux ^Talk 14:22, 4 March 2019 (UTC)

• @Xeno: I did not say a globally locked account could view deleted revisions. I said a locally blocked account could. The account could have been unlocked at any time. To my knowledge, the Foundation isn't questioning the future security of the account when they restore access and unlock. They're merely verifying the current operator is the original account holder. That's insufficient to ensure another compromise doesn't rapidly happen, which is why I consider the situation an emergency until either ArbCom is satisfied with the ongoing security of the account or the permissions have been removed. On an unrelated note, WP:LEVEL1 explicitly allows the stewards to be contacted to remove tools in the case of a compromised account, and the community does not have jurisdiction over such procedures (WP:CONEXCEPT). It's unclear to me where everyone is getting the "if it's not an emergency, it must go to the local bureaucrats". It's perhaps a best practice, but by no means required if the bureaucrats continue to be difficult to get a hold of quickly. ~ Rob₁₃^Talk 15:44, 4 March 2019 (UTC)

  As far as I can tell, no one attempted to get ahold of us though on wiki or by email. (I misread the bit about lock/block.) –xeno^talk 15:57, 4 March 2019 (UTC)

  We get it from the WP:LEVEL1 policy:
  "...an arbitrator will (a) directly request removal from a bureaucrat, or steward if necessary,"
  The placement of the commas is significant as the words "if necessary" apply only to the words "or steward". In this case, a Steward implementing a global lock meant that (subject to your concern about the circumstances in which it might be unlocked) it wasn't necessary for a Steward to desysop. As to bureaucrats being difficult to get hold of quickly, please note Xaosflux's comment below. He was around, read the WP:BN post and edit conflicted with MarcoAurelio. However, as I said above, it's a very minor issue compared to the suggestion that compromised accounts are too readily unlocked. WJBscribe (talk) 16:29, 4 March 2019 (UTC)

For my part, I saw the request on WP:BN about an hour after it was posted. I no longer follow any IRC channels as the energy seems to have moved elsewhere. I too believe that some sort of effective method for contacting 'crats for urgent situations may be called for. I do believe it is important for enwp to be self-sufficient regarding these matters to the extent feasible. UninvitedCompany 16:49, 4 March 2019 (UTC)

• I think it's reasonable to ask the WMF to keep accounts locked until advanced permissions have been dealt with by local projects. I think it's reasonable, in a situation where the account is already locked and there is no emergency, to post the request to BN and wait a brief time for bureaucrats to respond so that local logs can be properly maintained for future reference. –xeno^talk 18:29, 5 March 2019 (UTC)

  I think the priority in any compromise situation should be ensuring that the account is secured and returned to the original owner. Focusing on whether the desysop log entry is on enwiki or meta is the height of useless wikibureaucracy and offers no practical benefit. The current structure of the workflow itself is ridiculous: compromised account detected --> stewards lock --> ArbCom needlessly motions to desysop --> bureaucrats desysop --> T&S investigates and returns access --> bureaucrats resysop. Unnecessary steps in italics. There is absolutely no need for local users to be involved here at all beyond what appears to be some desire to be busy and feel important. Ajraddatz (talk) 18:48, 5 March 2019 (UTC)

  Quite the contrary, it’s about accurate and easy to follow logs. If the local logs would show the actual sequence of events even if an action was processed on another project, I wouldn’t care one jot who processes it. Is there a Phab ticket to integrate the logs? –xeno^talk 19:02, 5 March 2019 (UTC)

  Access removal and restoration on this project are also governed by the security requirement of the administrator policy, simply "regaining" control of a credential does not mean you are now meeting these expectations. Other projects may not require this, but our community has decided it is important. — xaosflux ^Talk 19:10, 5 March 2019 (UTC)

  That section of policy is clearly outdated. In a world where the WMF can effectively return access to users after their account has been compromised, I see no need to partially implement that policy for the sake of bureaucracy. Re: integrating the logs, I agree it is annoying, and I think there is a Phab ticket for it somewhere. I also think that the general consensus is that it isn't enough of an issue to fix at the moment. FWIW, I do agree that there is no rush to desysop after the user is locked. I'm just concerned that there are so many extra steps and processes with really no value added to the main goal of securing and returning access to the account. -- Ajraddatz (talk) 01:52, 6 March 2019 (UTC)

  phab:T6055 --AntiCompositeNumber (talk) 02:20, 6 March 2019 (UTC)

  Thanks. This feature request (ca. 2005) is older than my account. How do we get some dev time on it? –xeno^talk 11:48, 6 March 2019 (UTC)

  The community wishlist survey on meta is the most reliable method of getting dev time, but that happens once a year late in the year. Thryduulf (talk) 14:28, 6 March 2019 (UTC)

  It also requires broad community support. --AntiCompositeNumber (talk) 14:34, 6 March 2019 (UTC)

  Indeed, it is not quick and not guaranteed but it is still the most reliable method of getting dev time. I've commented on the phab task asking for someone to look at it again to see if it's a quick win as much has likely changed since that seems to have last been done. My exprience of phabricator is that the comment will receive a reply a some point (it could be today, it could be in three years time) that will either agree or disagree with my suggestion or miss the point entirely. Thryduulf (talk) 14:57, 6 March 2019 (UTC)

  Is there some way to provide a pre-filled link to the user’s meta rights log when you are viewing special:Userrights or the rights change log? –xeno^talk 16:40, 6 March 2019 (UTC)

  @Xeno: it should be fairly easy - just replace en.wikipedia with meta.wikimedia, and append @enwiki to the username. I can code up a user script to add an easy link if you want --DannyS712 (talk) 16:53, 6 March 2019 (UTC)

  It should be easy enough to duplicate the rights logs, and that would be better than a link to the Meta log. I'll follow up on this. In the mean time a link to the Meta log would be good. -- Ajraddatz (talk) 17:31, 6 March 2019 (UTC)

  @Ajraddatz, Xeno, and Amorymeltzer: until I can code a better version, User:DannyS712 test/meta.js adds a link when looking at a page/users log to see that page's log on meta - click "View meta log" in your "more" menu (on vector), or wherever p-cactions is in your skin. At [12], there is now a link to [13]. --DannyS712 (talk) 22:04, 6 March 2019 (UTC)

  Well, as it turns out, there is a link at Special:UserRights to the global rights log, although only recently (it was added in January by AGK) and only for sysops. I've added it to the display for non-sysops. Also, FWIW, the rights log has a link at the top to the generic meta log with instructions on how to search a name. ~ Amory (u • t • c) 17:49, 6 March 2019 (UTC)

  Thank you for pointing that out, I hadn't noticed the addition. I know there is a general link but is there a way to construct a similar link on a page like https://en.wikipedia.org/wiki/Special:Log?type=rights&user=&page=Xeno ? Of course, would still be preferred to have the meta log displayed below the local one, so thank to all who are helping move that along. –xeno^talk 17:57, 6 March 2019 (UTC)

  [14] shows user rights in all projects plus global--Ymblanter (talk) 18:02, 6 March 2019 (UTC)

  I may be wrong, but I don't think MediaWiki:Rightslogtext exposes any variables for the target page in question, in which case it'd have to be done with javascript. ~ Amory (u • t • c) 19:02, 6 March 2019 (UTC)

Original announcement

Original announcement

• Advising Arbs and their clerks of a DRV discussion on lists of banned users. See. Wikipedia:Deletion_review/Log/2019_March_19#User:Rockstone35/list_of_banned_users. --SmokeyJoe (talk) 00:51, 20 March 2019 (UTC)

• • I also wrote some thoughts here, if anyone is interested. Not sure if the village pump or DRV was a more appropriate place for the discussion. Rockstonetalk to me! 22:44, 21 March 2019 (UTC)

Original announcement

• Sysop access removed per the WP:BN request. — xaosflux ^Talk 17:08, 24 March 2019 (UTC)
• Interesting; unlike many of the other compromised accounts, Nec had been pretty active💵Money💵emoji💵^💸 17:12, 24 March 2019 (UTC)

Last similar case I remember was Orangemike.

I recently changed my password and I encourage everyone else reading this to do the same if they believe their password insecure. — pythoncoder  (talk | contribs) 17:14, 24 March 2019 (UTC)

Yes Necrothesp has been an admin for years but seems to use most of their tools for page moves. Crouch, Swale (talk) 17:47, 24 March 2019 (UTC)

And your point is? There are lots of deletions in his log, many of which relate to page moves. Just because someone doesn't spend their time blocking accounts doesn't mean they aren't carrying out administrator tasks. Pythoncoder is right, though. I urge all administrators, regardless of whether or not they *think* their password is secure, to change it now if they have not done so in the last three months. Risker (talk) 18:31, 24 March 2019 (UTC)

I have had a bit of interaction with them, I to am surprised this has happened and hope they get the admin right back. I don't see why admins need to be making "admin actions" to keep the tool though. Crouch, Swale (talk) 18:57, 24 March 2019 (UTC)

@Crouch, Swale: they don’t; only one edit (or logged action) per year is required for them to be considered active. Those who have been deadminned for inactivity and haven’t used the admin tools for five years will normally have to submit a new RfA to be reinstated, however.—Odysseus1479 20:36, 24 March 2019 (UTC)

Yes that's correct, I don't really have a problem with admins being inactive but understandably some do, I think our inactive admin policy is fine, on the other hand Commons has (IMO) a too strict one that an inactive admin is "one who has made fewer than 5 admin actions on Commons in the past 6 months" and those who loose it have to go through a new RFA which I think is unnecessary. Crouch, Swale (talk) 13:33, 25 March 2019 (UTC)

Necrothesp here. What the hell is going on? I'm utterly mystified as to why I have been blocked. Explanation please. -- 86.177.23.111 (talk) 22:26, 24 March 2019 (UTC)

Your account vandalized the Main Page. You can contact trustandsafety wikimedia.org for more information on steps forward. --AntiCompositeNumber (talk) 22:29, 24 March 2019 (UTC)

Well, I certainly didn't! -- 86.177.23.111 (talk) 22:31, 24 March 2019 (UTC)

Yes, that's the entire point. Your account was compromised, and has been locked until the WMF can verify that you are the only person with control over the account again. --AntiCompositeNumber (talk) 22:33, 24 March 2019 (UTC)

So, what am I supposed to do about it? You're not very specific as to how I can deal with this. Somebody is screwing around here, and it certainly isn't me. The link you just gave me is no link at all. -- 86.177.23.111 (talk) 22:37, 24 March 2019 (UTC)

@Necrothesp: yes, I don't know why anticomposite# feels the need to involve themselves: probably arbs or crats would be more profitable. Still, it's true that you should contact the WMF first. Email immediately. Good luck 😊 ——SerialNumber54129 22:46, 24 March 2019 (UTC)

One of the more definitive guides to this situation is Wikipedia:Compromised accounts. -- zzuuzz ^(talk) 22:50, 24 March 2019 (UTC)

Serial Number 54129, compromised accounts, being inherently global, are in the realm of stewards and T&S. Vermont (talk) 23:05, 24 March 2019 (UTC)

@Vermont: ikr? ——SerialNumber54129 10:52, 25 March 2019 (UTC)

• Necrothesp, please see User_talk:Necrothesp#Next_Steps for the next steps for you. — xaosflux ^Talk 23:38, 24 March 2019 (UTC)
  • Thanks. -- 86.177.23.111 (talk) 23:46, 24 March 2019 (UTC)
• Sigh. Security incident number 5. None of the non-technical admins seem to give a damn about account security. At this point, I am adamantly opposed to regranting sysop without an RfA first for any admin that gets compromised. While I get 2FA is not for everyone, it’s not difficult to use a unique password for Wikipedia, and to avoid phishing sites.—CYBERPOWER (Chat) 00:33, 25 March 2019 (UTC)
  • While I share your frustration to a degree, I would like to point out that not all compromises can be avoided by following the simple procedures you describe. I believe we should give individuals whose accounts are compromised the benefit of the doubt unless we know the facts of the situation. UninvitedCompany 03:16, 25 March 2019 (UTC)

    UninvitedCompany, if they are using a unique password, it’s very unlikely that the account will get hacked here. The fact that it did, given we have had no JS hack this time is an indication that this user’s password was shared with another site that got breached. I’m willing to give the benefit of the doubt, and will hear him out, but I’m just going off of how this looks. —CYBERPOWER (Around) 11:40, 25 March 2019 (UTC)

  • So, despite my account being compromised through no fault of my own, I'm expected to reapply for adminship even after using it responsibly for many years? If I may say so, this is an appalling way to treat people who devote their time to Wikipedia. I would also point out that I have never in my life knowingly been compromised by phishing! As UninvitedCompany says, it should not be assumed that this is any of my doing. -- 137.205.202.18 (talk) 10:38, 25 March 2019 (UTC)

    It’s not about your trust in using the tools. It’s about the trust in keeping your account secure. While I don’t know the details about your compromise, you are the fifth administrator to become compromised in the last year. That alone is already a red flag as it tells me that the admins here didn’t take a hint to secure their accounts out of an abundance of caution. i Could say more, but like I said, I’m waiting to hear your side first. —CYBERPOWER (Around) 11:48, 25 March 2019 (UTC)

    Cyberpower678, 3 compromises ago, I would have argued with you about this. It's getting far too commonplace, and we've had 2FA available for a very long time now. While it isn't a magic bullet, it is better than nothing. It's not a 'techie' thing either, it's pretty damn simple to use. This isn't 'bureaucracy' - this is about being more careful with privileged credentials. When something like this happens due to weak or reused passwords, and not using 2FA, it is not 'through no fault of my own'. It is a direct result of neglecting account security. Perhaps if the next account to be compromised has to re-do RFA, admins would finally take basic password hygene more seriously. SQL^{Query me!} 12:04, 25 March 2019 (UTC)

    SQL, thank you. I use 2FA everywhere I can. Annoying as it sometimes is, I know that if they someone get past one layer, the second layer is almost impossible to get through. —CYBERPOWER (Around) 12:08, 25 March 2019 (UTC)

    Cyberpower678 Exactly. If the second factor is phished, it must be exploited in real time, since the second factor will expire in a matter of minutes – it can't just be harvested to be exploited at the attacker's leisure or at a future time of the attacker's choosing when he could cause the most damage. Mojoworker (talk) 15:57, 25 March 2019 (UTC)

    Mojoworker, Well it's technically doable. You pass it a 2FA code and it would pass that through to Wikipedia and receive a login cookie. Simply save the cookie, and then it can be used at a later time. The phishing site would then just pass that same cookie back to the client and redirect them back to the real site. It's not technically impossible. This is why people need to be really careful about what's in that address bar, and if it has a padlock next to it, before revealing private info. This of course is not implying that Necrothesp did this, just a general comment. —CYBERPOWER (Chat) 16:23, 25 March 2019 (UTC)

    Cyberpower678 True, in that scenario the attacker could harvest cookies instead of passwords, and the cookie could be used until the next time the victim logs in again through the real site and gets a new cookie. So yeah, the "keep me logged in for up to 365 days" login option is probably excessively long. Mojoworker (talk) 17:03, 25 March 2019 (UTC)

    Mojoworker, The keep me logged in option is not the problem. When a cookie gets stolen like that, it could be used promptly to change the password and email. Now it doesn't matter if it's short or long. That's why if you suspect being compromised, always go to your settings and change your email first, password next, and then immediately click logout. Otherwise, you might permanently lose control of your account.—CYBERPOWER (Chat) 17:08, 25 March 2019 (UTC)

    Cyberpower678 I agree, but in that scenario, it's obviously been compromised. I'm talking about the keep me logged in option in the context of an attacker harvesting sleeper accounts (be they passwords or cookies), and then in the future exploiting them at a time of the attacker's choosing when they could cause the most damage. Mojoworker (talk) 18:22, 25 March 2019 (UTC)

  Cyberpower678, requiring compromised admins to go through RfA again is permitting the compromisers a victory, however temporary. Vermont (talk) 10:53, 25 March 2019 (UTC)

  Vermont, I actually never thought about it that way. It's just with the ridiculous amount of security incidents in the last year, I'm shocked that some didn't take it seriously enough to change their password to something unique and not used anywhere. At this point, I'm shocked to see this is still happening, as it seemingly looks like this admin's password was leaked from a different site, tested here, and they got in. Since the admin didn't even know it happened, it suggests even further that they have login notifications disabled. Annoying as they can be when you're constantly bombarded with failed login attempt and password reset attempts, they are definitely useful to see as you know that they either broke through, or they keep failing, or that someone is simply trying out a list of leaked passwords. —CYBERPOWER (Around) 11:59, 25 March 2019 (UTC)

  "Since the admin didn't even know it happened, it suggests even further that they have login notifications disabled." I appear to have received the login notification yesterday afternoon, apparently shortly before the vandalism. However, I was not online until yesterday evening, by which time all this had already happened and I had already been blocked. Unless you expect me to be available 24 hours a day (sorry, I do have a life outside Wikipedia and I do not monitor my email every second of every day), this is a bit of a weird claim. -- 137.205.202.18 (talk) 12:14, 25 March 2019 (UTC)

  I retract that part of my assessment then. Sorry. —CYBERPOWER (Around) 12:20, 25 March 2019 (UTC)

  • I rarely agree with the subject of the compromise over anything but I don't see any reason as to why an RFA shall be sought to give him his bits. To the best of my guess, T&S and ArbCom indeed verifies that good measures are in place to prevent a re-occurrence of the incidence. That's enough. ∯WBG^converse 11:34, 25 March 2019 (UTC)

    Winged Blades of Godric, In my view, while he still retains trust that he won't misuse the tools, he has lost my trust in keeping his account secure. As the saying goes, fool me once, shame on you, fool me twice, shame on me. Fool me 5 times, well, no more words for that. We are in a time where security is becoming a serious issue online. With the recent issues of compromised accounts, that should've been a wakeup call to the other admins to secure their accounts. I may be being a dick over this, but I'm very pro-security, especially for admin accounts. —CYBERPOWER (Around) 12:09, 25 March 2019 (UTC)

    "fool me once, shame on you". Quite! I am one person, not five! -- 137.205.202.18 (talk) 12:15, 25 March 2019 (UTC)

    The expression applies to all admins as a whole. It's meant to read as compromise us once, shame on you. Compromise us twice, shame on us. —CYBERPOWER (Around) 12:22, 25 March 2019 (UTC)

    However, you appear to be claiming that because five admins have been compromised recently that makes me more culpable. Why does it? That's not a fair statement. If it had happened to me twice then I might agree with you, but not if it happened to five individuals once. -- 137.205.202.18 (talk) 12:26, 25 March 2019 (UTC)

    That's not what I'm claiming. What I'm claiming is it makes all of us more culpable. If you haven't noticed yet, hacks tend to target administrators for obvious reasons. More applicable to even more privileged users. Every privileged user should have taken the seriousness of a compromised user to heart and taken steps to increase their account security. Wikipedia has been getting targeted more and more by hackers. Does it suck to get hacked? Yes it does. I've been there. Hell, I've had my credit card numbers stolen, thanks to a data breach. But that only made me be more careful. I follow security issues constantly, and if something did happen that can be prevented, I will take those measures to prevent them. So what I'm saying, it's going to be more and more agitating to see more of these emergency desysops because a hacker found their way in. It's not like I enjoy seeing you or other admins doing good work getting desysopped. —CYBERPOWER (Around) 12:40, 25 March 2019 (UTC)

    "I follow security issues constantly". Yes, I think that's entirely the point and why you can't see my point of view. I don't. I may be able to recognise a phishing email and have the sense not to enter sensitive information on dodgy websites, but computer security is not my speciality or even one of my interests. And I don't think you'll find it's in the forefront of the minds of most editors on Wikipedia, admins or otherwise. Because that's not why we're here. It's the encyclopaedia part of Wikipedia that attracts us, not the website part. -- 137.205.202.18 (talk) 12:52, 25 March 2019 (UTC)

    But that creates negligence. Am I correct in assuming that your password is less than 10 characters, or on the password blacklist? —CYBERPOWER (Around) 12:58, 25 March 2019 (UTC)

    "Ignorance is no excuse", "negligence", did Wikipedia suddenly become a law-enforcement agency while I wasn't looking? I seem to recall it being an encylopaedia last time I looked. And also one that deliberately tried to avoid too much bureaucracy. Nine characters. I very much doubt it's on any blacklist. You seem to be confusing lack of detailed knowledge and constant monitoring of computer security with stupidity. -- 137.205.202.18 (talk) 13:10, 25 March 2019 (UTC)

    Technically, that is not compliant of the password policy imposed by the WMF for privileged users. Also I'm not calling you stupid, and you aren't. I tend to be very direct, so if I'm not calling you stupid, I'm not thinking it of you. —CYBERPOWER (Chat) 13:14, 25 March 2019 (UTC)

  • How would a new RFA even be relevant, let alone a good idea? You don't get asked questions like "Do you use your password on any other site? (If not, prove it.)" or "What is your email provider, so we can audit its security practices?" or "What steps do you take to prevent your cats or malicious teenagers from stepping on your keyboard while you're out of the room?" at RFA; you get stuff like "Do you plan to perform histmerges? (IfNotIWillOpposeYou)" and "Aren't schoolblocks bad? (IfNotIWillOpposeYou)". There's maybe a case to be made that a compromised account should never be allowed advanced permissions again, though I don't think it's been made persuasively; but I can't see how it makes sense to say a compromised account shouldn't get permissions back unless they can pass another RFA popularity contest. —Cryptic 17:29, 25 March 2019 (UTC)
• I have to say, it's not great that the compromised admin doesn't seem to even be aware of what a compromised account is. I think I'll just post these links each time something like this happens:

• WP:STRONGPASS, local policy
• meta:Password policy global policy
• WP:SECURITY general info on account security
• WP:2FA about Wikipedia's two factor authentication system

Every admin should be up to speed with what is on these pages and compliant wth the ones that are policies. Beeblebrox (talk) 00:40, 25 March 2019 (UTC)

Please don't be patronising. Of course I'm aware what it is. But you have to understand that most of us have no experience of this sort of thing. We just devote our time to editing and maintaining the encyclopaedia, not getting involved in the bureaucracy. We are not necessarily techies or computer experts and there's no reason why we should be. You surely realise that it was a bit of a shock when I opened up Wikipedia last night (actually just to use it for a bit of research) and realised that I'd been chucked off and couldn't sign back in to my account and I reacted accordingly! Not something I've ever experienced before. -- 137.205.202.18 (talk) 10:38, 25 March 2019 (UTC)

I don't mean to sound like an ass, but ignorance is not an excuse. It's not hard to change your password, and no techie knowledge is required to do so. Use a strong never used password, and boom, your 80% securer than before. Add 2FA, and you're not likely going to be compromised. That just leaves the JS exploit vector which has been mitigated by introducing interface administrators. —CYBERPOWER (Around) 12:13, 25 March 2019 (UTC)

I think you need to look at it from the point of view of an ordinary admin who uses their admin tools to do what most admins use them for (i.e. to keep Wikipedia safe from run of the mill vandals and soapboxers and to move and delete articles that couldn't otherwise be moved or deleted), not from the point of view of those who want to get more involved in the technical side of things. Because you really don't appear to be. I am here because I enjoy editing Wikipedia. I have been doing that productively for many years. Frankly, I am beginning to wonder why I have bothered. -- 137.205.202.18 (talk) 12:26, 25 March 2019 (UTC)

I'm not trying to drive you away from Wikipedia, but more like trying to get you to see that this was in part your fault due to negligence despite previous incidences, unless you have indeed changed your password to something unique and secure recently and haven't told me yet. All you needed to do at the very least was use a new password that was at least 10 characters long. That doesn't require technical involvement, nor does it distract you from continuing to do the things you enjoy. Let me be clear, there's absolutely no doubt that you are a valued contributor to Wikipedia. BUT, BUT, BUT, security is a strong factor today on the internet. You need to practice it, or this very incident happens. The same also goes for all you other admins thinking, "Oh this won't happen to me, no need to change my password." —CYBERPOWER (Around) 12:46, 25 March 2019 (UTC)

By saying I should have to reapply for admin status because somebody else hacked my account, driving me away is exactly what you do appear to be trying to do. Who would honestly want to stay after being treated like that following nearly 15 years as an editor and over 13 years as an admin? That's what I'm trying to get you to see. Try to look on it from a human perspective as opposed to a technical one! -- 137.205.202.18 (talk) 13:05, 25 March 2019 (UTC)

I think I need to go get some breakfast and walk away here. BBL —CYBERPOWER (Chat) 13:12, 25 March 2019 (UTC)

C678, I appreciate your concerns, and agree with much of them, but I think that the point has been well driven home by now. Thanks for stepping away. —DoRD (talk)​ 13:17, 25 March 2019 (UTC)

Yea. I think I owe you an apology. I've been a bit on edge lately, and get easily frustrated. So yea, you should not have to go through another RfA. Hope you get access to your account again soon. I take it back, but please use a new, strong, and unique password for Wikipedia going forward, and consider activating 2FA. —CYBERPOWER (Chat) 13:24, 25 March 2019 (UTC)

Ah, (edit conflict) with my comment below. Boing! said Zebedee (talk) 13:27, 25 March 2019 (UTC)

@Cyberpower678: Thanks. As you can imagine, I'm a little on edge too! I will certainly take steps to improve security. -- 137.205.202.18 (talk) 13:30, 25 March 2019 (UTC)

So Necrothesp hasn't done anything to warrant their sysop rights being taken away. Their account was compromised, yes quite clearly. It was caught and blocked very fast as it should be. Lets just follow the process for getting them back into their account and move on. I'd encourage adding a stronger and longer password and potentially 2 factor authentication, but see no reason to put them through an RFA again. Canterbury Tail talk 12:20, 25 March 2019 (UTC)

• Folks, there is no requirement for Necrothesp to run a new RfA, and there has been nothing close to a policy change to implement anything of the sort. Can I suggest that this is not the place for banging that particular drum, and that if anyone wants to change admin policy to require a new RfA after an admin account compromise then they should go and start an RfC to see if there's community support for it? Boing! said Zebedee (talk) 13:24, 25 March 2019 (UTC)
  • The short answer is we probably need to rewrite WP:ADMIN#Security. The last line there states Unauthorized use is considered 'controversial circumstance', and access will not be automatically restored. Now, that was quite clearly written in the context of sharing a password or access to an account (see addition to policy and tweaking of language) and the only other line that could reasonably be thought to address a malicious compromise is [i]n certain circumstances, the revocation of privileges may be permanent. The sort of compromises and desysops we're talking about are generally in the purview of ArbCom; the bureaucrats aren't making these decisions, they're being directed to restore permissions by ArbCom. The one recent non-ArbCom desysop was not of a compromised account and regardless, ArbCom found that an emergency sysop was uncalled for. ~ Amory (u • t • c) 13:54, 25 March 2019 (UTC)
• I think account security has now been made clear enough to Necrothesp and as pointed out although this has happened to other admins before, it hasn't happened to Necrothesp before. Can I suggest that once we're clear that they are back in proper control of their account etc that they be given their admin tools back. Crouch, Swale (talk) 13:33, 25 March 2019 (UTC)
• Umm, I don't know if I'm allowed to talk here, but there's an idea to let every/all user to enable 2FA from Meta, please see related page m:Meta:Requests for comment/Enable 2FA on meta for all users. Thank you. (I allow anybody to remove my comment here if it's deemed as inappropriate.)--AldNon^Ucallin?☎ 14:08, 25 March 2019 (UTC)

  This isn't really relevant. An admin was compromised. Admins can enable 2FA already. Natureium (talk) 14:33, 25 March 2019 (UTC)

  So... Should I remove my comment?--AldNon^Ucallin?☎ 14:36, 25 March 2019 (UTC)

  Aldnonymous, your comment is fine and you are absolutely welcome to participate here. Worm^TT(talk) 15:49, 25 March 2019 (UTC)

  It's actually already available for all users who know how to request the Stewards to add them to OATH-testers. I for instance have 2FA enabled, and I am not an admin. Seemed prudent as I have some unusual rights such as account-creator, rollbacker and pagemover. I left some instructions at WT:Simple 2FA#Why is 2FA limited to Bureaucrats, Admins, etc? 2-1/2 years ago. Not sure why we don't just make this easy to attain. Bri.public (talk) 16:26, 25 March 2019 (UTC)

  @Bri.public: the WMF departments have kept it low (and currently only require it for a few groups, including interface-admin here) because it is a major pain to support and account recovery is cumbersome at best when things go wrong. — xaosflux ^Talk 17:25, 25 March 2019 (UTC)

• Requiring a new RfA is absurd. Necrothesp didn't do anything wrong; he was victimized by a hacker. Now, the deeper question is whether admins should be required to be more proactive about securing their accounts. My personal opinion is that yes, they should. Our current policy for admin account security is laughably lax, but the fix for that is to upgrade the policy, not to make an example of somebody who was in compliance with policy and got hacked. -- RoySmith (talk) 16:14, 25 March 2019 (UTC)
• Are checkusers and oversighters required to enable 2FA? If not, they need to be. (Also, I saw this other record of a similar emergency desysop, but that one was done by ArbCom. Regardless of who was doing the desysopping, it does seem that the community considers self-unblocking a clear red line for admins.) — pythoncoder  (talk | contribs) 16:28, 25 March 2019 (UTC)

  pythoncoder, CU and OS are not required to enable 2FA at present. Also, the unblock-self ability has been removed from administrators in the past few months. Worm^TT(talk) 16:34, 25 March 2019 (UTC)

  Thanks. I believe I covered the removal of unblockself in the Signpost. — pythoncoder  (talk | contribs) 16:36, 25 March 2019 (UTC)

  You did, in the December 1 Discussion report. - Bri.public (talk) 17:43, 25 March 2019 (UTC)

• I have recently rewritten some of the content in Wikipedia:Simple 2FA. If you have any suggestions for improving the guide, please feel free to share them or make the changes yourself. — Newslinger talk 05:38, 26 March 2019 (UTC)

My account has been restored by WMF Trust & Safety and unblocked. I have set a much more complex password. I now need someone to restore my admin privileges if anyone is able to do that. Thank you. -- Necrothesp (talk) 11:14, 26 March 2019 (UTC)

Glad that you're making progress on getting things fixed. Happy to restore them once we get the go ahead - ArbCom need to approve this with a new motion (see Wikipedia:Arbitration_Committee/Noticeboard/Archive_12#Level_1_desysop_of_Killiondude for a recent example). You can email them at arbcom-en@wikimedia.org. They may require additional verification that the right person is now in control of your account. WJBscribe (talk) 12:36, 26 March 2019 (UTC)

Contacted them. Thanks. -- Necrothesp (talk) 12:56, 26 March 2019 (UTC)

Hi Everyone. I just wanted to let people know that the Security Team at WMF did an initial investigation of this account compromise. The attacker was able to access this account on their second guess, and also tried to unsuccessfully log in to a different admin account. While it is impossible to be 100% sure about what happened, we currently believe that this was the result of using the same password on multiple websites. We strongly recommend that people do not use the same password for more than one website. The vast majority of Administrator account compromises appear to have happened due to reusing passwords. If you have ever used your Wikimedia password on a different website please immediately change it. Some people find using a password manager helps them to manage all the different passwords they have for different websites. If you are concerned about remembering all your different passwords, I would strongly recommend looking into using a password manager. 2FA would also have prevented this attack, and we strongly encourage all Administrators to enable it. Last of all, this has already been mentioned, but Wikipedia:User account security has some great general account security advice. Thanks, BWolff (WMF) (talk) 17:45, 26 March 2019 (UTC)

• This has become quite a looong thread, but I think Cyberpower678, waaay up top, has a point about increasing security. What kind of damage could someone potentially do if they got control of an admin account with the Intertace Admin permission, or other tools like checkuser, etc? While admins only have to make one edit per eon to keep their bits, perhaps a requirement for mandatory increased account security, maintained at mandatory 3 month intervals would reduce the number of compromises we're seeing? I'm sure there will be some booing and hissing at the very thought, but is it really too much to ask? jmho - wolf 20:32, 26 March 2019 (UTC)

  For what it's worth, interface-admins are required by the WMF to use 2FA, and it has been a standard question when applying at BN. IA, CU, and OS are all expected to use the permission at least semi-regularly lest the user group be removed: that is five actions/participations every three months for CU and OS (per ArbCom), and one action every six months for IA (IA is also removed if two months without any activity have elapsed). ~ Amory (u • t • c) 21:04, 26 March 2019 (UTC)

  Just as a note, 100% of interface-admins have 2FA enabled (Since its a requirement, but we do check this from time to time). Roughly two thirds of both checkuser's and oversighters have enabled 2FA. Roughly 23% of normal admins have enabled 2FA. BWolff (WMF) (talk) 23:24, 26 March 2019 (UTC)

• Full support for stronger removal of low or inactive advanced permissions, there are still admins making one edit in two years to keep their advanced permissions without benefit to the project at all - see User:HighInBC as a perfect example. [15] - I have notified the user of my comment - Govindaharihari (talk) 21:00, 26 March 2019 (UTC)
  • Why would you try to name and shame one particular admin, when they don't fit the criteria (one edit in two years) you're claiming? Why lie about something that's so easy to check? --Floquenbeam (talk) 23:45, 26 March 2019 (UTC)
    • Stranger still as they’ve already brought it up with the user - User_talk:HighInBC#your_advanced_rights ... –xeno^talk 23:55, 26 March 2019 (UTC)
      • ...and received a kitten for doing so :) ——SerialNumber54129 06:47, 27 March 2019 (UTC)

Original announcement

• Assuming this is the correct venue in which to do so, I support the proposed amendment. Thryduulf (talk) 23:22, 8 April 2019 (UTC)

  Thryduulf, there will be a formal ratification process, which will be announced here shortly. Nevertheless, comments and reactions are certainly welcome. Bradv🍁 23:29, 8 April 2019 (UTC)

  I’ll be posting the formal process very shortly. ~ Rob₁₃^Talk 00:41, 9 April 2019 (UTC)

• The motion proposing this amendment was passed shortly after I raised concerns about the potential for wikilawyering created by a requirement to seek input from an inactive Arbitrator "through all known mediums of communication." BU Rob13 dismissed my concerns as unreasonable, pointing to the reasonable person standard. I note that it is doubtful drafters of a statute would be silly enough to include a requirement to utilise "all known mediums of communication", more sensibly referring to something like "all reasonable communications channels." Rob also suggests that no Aritrator would take a view such as I suggest. However, consider a simple scenario:
  • ArbCom (12 members) thinks Arbitrator X should be removed.
  • If this amendment is enacted, X is disregarded and a 75% 2/3rds majority of the remaining 11 Arbitrators are needed – so 9 8 supports.
  • Arbitrator Y is inactive and attempts to make contact are unsuccessful. Under this amendment, a 75% 2/3rds majority of the remaining 10 is needed, so 8 7 supports.
  • The removal passes with 8 7 supports and 2 3 opposes.
  • Shortly after, Y returns and objects, stating that s/he would have opposed the motion.
  • Y also notes that contact by method XYZ was not attempted and would have worked, and can show that at least one member of ArbCom knew of this means of communication. Perhaps the one(s) who knew were not the amongst the Arbitrators trying to contact Y. Perhaps the method had slipped their mind.
  • In any case, what happens next? X has already been removed but the reason for not including Y in the calculations is arguably invalid as "all known means of communication" were not tried. The removal motion against X would have failed if Y were included in the calculations of the necessity for 9 8 supports, whether Y is treated as not voting or as an oppose. Should X be reinstated?

I don't suggest that such a scenario is highly likely, but it is made possible by including language that allows no flexibility. If one Arbitrator happens to know where Y works, should an attempt to communicate through that channel be attempted – because the proposed wording seems to me to mandate it? If Y had given a home phone number to a fellow Arbitrator for one-off use as Y's mobile phone was faulty, should that be used to contact Y (assuming the colleague still has or can locate the number)? Rob may see this as unreasonable, but would all future Arbitrators if such a situation arose? What is the down side or harm to a more flexible wording that recognises a duty to try all reasonable channels rather than all known channels? EdChem (talk) 01:01, 9 April 2019 (UTC)

You made that suggestion nearly 24 hours after the motion had passed, during the waiting time before it was enacted. The motion had been up for a month at that point. The downside is needing to go back to the drawing board and restart voting for a minor change in wording that practically does not change anything. In the scenarios you envision, if no arbitrator remembered the means of communication, then they were not known to the Committee, and do not need to be used. We could just as easily wikilawyer over what constitutes a "reasonable communication channel" and construct scenarios where such wording goes awry. In reality, arbitrators are generally reasonable people, and if there is disagreement, a majority will determine what the appropriate interpretation of the wording is. ~ Rob₁₃^Talk 02:13, 9 April 2019 (UTC)

@EdChem: In my time on the committee, arbitrators generally noted multiple ways they could be reached on the arbwiki (typically at least two email addresses and at least one phone number, in some cases more), in addition I was in regular contact with at least two other arbs on social media, and mutual friends would also have provided additional means of contact, heck 30 days allows for snail mail should the need arise. Obviously people differ in how much information they share about themselves, but the chances of an arb who wants to be contactable by other members of the committee not being reached within 30 days is very unlikley. Thryduulf (talk) 09:53, 9 April 2019 (UTC)

Thryduulf, I agree that making contact shouldn't be that difficult, but also note that your comment further highlights that the wording is flawed. In the scenario I describe, unless every social media and via-mutual-friends approach is tried, then discounting the inactive Arbitrator is not authorised. I get that my observation isn't popular, but I'm not the one who proposed an "all known mediums of communication" test. EdChem (talk) 12:54, 9 April 2019 (UTC)

This is beside your point, but the amendment says two-thirds, not three-fourths, the same as current policy. ~ Amory (u • t • c) 11:06, 9 April 2019 (UTC)

You are correct that the policy refers to a 2/3rds majority, not a 3/4 majority, and I have updated above accordingly, but the basic point remains. EdChem (talk) 12:49, 9 April 2019 (UTC)

The ratification process has begun at Wikipedia:Arbitration/Policy/Proposed amendment (April 2019). ~ Rob₁₃^Talk 02:14, 9 April 2019 (UTC)

On behalf of the clerks, I have submitted a request for bot approval to automate some of the clerks' procedures relating to this noticeboard. Interested parties are welcome to review the code/specifications and comment on the request. – bradv🍁 20:06, 9 April 2019 (UTC)

Original announcement

  Bureaucrat note: Following the request at WP:BN and affirmation of meeting the conditions, access was restored per Special:PermaLink/891824354#Restoration_of_sysop_privileges_to_Necrothesp. — xaosflux ^Talk 11:39, 10 April 2019 (UTC)