Wikipedia talk:Arbitration/Requests

Minor link fix on WP:A/I/PIA

The second motion link at Wikipedia:Arbitration/Index/Palestine-Israel articles#General Prohibition is to a non-existent section header, I imagine from a mistaken copy-paste. I believe the correct link (taken from here) should be Special:PermanentLink/756684880#Motion:_Palestine-Israel_articles_3_.28v0.3.29. ~ Amory (u • t • c) 11:13, 5 April 2019 (UTC)

 Done –Bradv🍁 13:31, 5 April 2019 (UTC)

Restoration of sysop privileges to Necrothesp (April 2019)

Original discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Version 1 (Necrothesp)

On March 14, 2019, the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) were temporarily removed as a suspected compromised account under the Level 1 desysopping procedures.

Following discussion concerning account security, and pursuant to the procedures for return of revoked permissions, the Arbitration Committee resolves the following:

The administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) are restored, provided he enables two-factor authentication on his account.

Enacted – bradv🍁 02:50, 10 April 2019 (UTC)

For this motion there are 11 active arbitrators. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.

Majority reference

Abstentions	Support votes needed for majority
0–1	6
2–3	5
4–5	4

Support

1. As proposer. Assuming he makes the request to the Stewards and we receive confirmation of the 2FA being activated before the bit is flipped back on. ♠PMC♠ (talk) 21:22, 7 April 2019 (UTC)
2. Second choice. Katie^talk 21:45, 7 April 2019 (UTC)
3. I can support this while pondering the wording of procedures moving forward. And perhaps it would be more appropriate to have a separate motion on procedures rather than tangle up the voting of a resysop with the voting of procedures because if some Arbs are not happy with the wording of the procedures motion, that could hold up Necrothesp's resysopping further. Provided Necrothesp enables 2FA, he can have the tools back while we jiggle with the procedures motion. SilkTork (talk) 22:42, 7 April 2019 (UTC)
4. Sympathetic to the view espoused by Joe, but I think enabling 2FA mitigates the risk well enough for me. AGK ■ 14:08, 8 April 2019 (UTC)
5. It gets lost sometimes in the rhetoric around account security, but admin accounts do not actually have access to the nuclear codes. We do not now have evidence that Necrothesp's account is any less secure than any other active admin's, and indeed just-breached accounts are probably the safest :) Even though everyone who plausibly can use 2FA really should, I'm very hesitant about this as a general practice - "if you get compromised, you'll be required to enable 2FA after" - because of the possibility that it will end up excluding people whose circumstances don't fit with MediaWiki's somewhat clunky implementation. But for this case I think it's reasonable. (In general, we'll get more bang for the security buck yelling from the rooftops at every opportunity that Thou Shalt Not Reuse Passwords, not even once, not even if you used password123Reddit and password123Wikipedia and now think it's unique, not even if the recycled password is "correct horse battery staple", just no. Are you reading this post and unsure if you might have used your Wikipedia password on dodgy-downl0adz.com? Go change it, right now before you forget, I'll give you a cookie after.) Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)
6. Necrothesp has enabled 2FA and therefore has, in my opinion based upon the available information regarding the situation, adequately secured their account from being compromised again and should have the tools returned to them. Mkdw ^talk 21:36, 8 April 2019 (UTC)

Oppose

1. In favor of version 2, which also addresses how we should handle these situations going forward. ~ Rob₁₃^Talk 21:41, 7 April 2019 (UTC)

   I will switch to support if 3 passes. ~ Rob₁₃^Talk 15:12, 8 April 2019 (UTC)

2. In favor of version 2. RickinBaltimore (talk) 22:54, 7 April 2019 (UTC)
3. I am not convinced that Necrothesp adequately secures his account. By community policy, this is admin misconduct. In this instance, his negligence allowed a focused attacker to seriously vandalise the main page and a template used on almost every other Wikipedia page. Enabling 2FA is not going to solve the underlying lack of attention to basic security (it would also be impossible for us to monitor in the long term), so unfortunately I must come to the conclusion that Necrothesp can no longer be trusted with the tools. – Joe (talk) 05:27, 8 April 2019 (UTC)

Abstain/Recuse

Arbitrator comments/discussion

• @BU Rob13: How would it be Necrothesp's fault if motion 2 or 3 did not pass? It would not, so more importantly, why should Necrothesp's fate be tied to these two motions if you have reasonable confidence that their account will be secure (with 2FA enabled)? We are discussing and voting on increasing our security standards below, but I think it is unethical to hold someone hostage for effectively a political and policy position. They should be assessed fairly against our current enacted policies and protections, even if the ultimate decision is to deny their request to return their tools. Mkdw ^talk 16:03, 8 April 2019 (UTC)
  • I absolutely agree. I want to reiterate that I think it is incredibly underhanded to suggest this kind of package motion where the handling of issues related to one person are combined with, and therefore made hostage to, a broader policy discussion. I sincerely hope that I don't see this kind of thing becoming a common practice. ♠PMC♠ (talk) 16:26, 8 April 2019 (UTC)
  • +1 to PMC. This is a shabby way to treat a volunteer who made a mistake. We have plenty of other places to argue about internal wikipolitics. Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)
    • Our current policy on administrators states that administrators must secure their account. Necrothesp fell short of that standard in a way that puts me squarely on the fence when it comes to restoring permissions. The problem is that we haven't enforced our current policy for quite some time, which may have created an expectation we would not enforce it going forward. While certain administrators have lagged behind in their security standards and their understanding of relevant policies, so too has the Arbitration Committee when it came to enforcing those standards and policies. I believe opposing this motion is justified by our current policy, and the motions proposed below merely state that we will be enforcing existing community policy going forward. If, as a Committee, we decide that it's worthwhile to clarify that we will begin enforcing the current policy going forward, I am willing to support this resysop due to the expectations our shoddy enforcement caused. If we decide such a clarification is unnecessary, then there is no reason not to enforce the current policy now, which leads me to oppose resysopping. ~ Rob₁₃^Talk 17:52, 8 April 2019 (UTC)
      • You are opposing Necrothesp to make a point. Your vote is completely contingent on whether the committee will vote in alignment with your own agenda to amend the policy. Such strategic voting with ulterior motives should not be a practice on the Arbitration Committee. Your view that the committee is not appropriately enforcing the policy is a valid argument, but conditionally voting with the express purpose of trying to influence votes is immoral. Oppose if in your fair assessment you believe Necrothesp does not meet the policy. Support if you do. But specifically voting because your policy amendment did not pass is an irresponsible tactic. We reach these decisions as a committee majority and ultimately to the frustration of some when the vote does not go their way. If you think conditional voting is the way to address or influence the process, that is in my opinion an error in judgement and a much more problematic issue than the one it is trying to solve. Mkdw ^talk 00:31, 9 April 2019 (UTC)
        • I both object to and take offense to quite a bit of what you said, but frankly, I don't have the energy or drive to respond to an arbitrator calling me immoral in response to an attempt to compromise. I will simply oppose. ~ Rob₁₃^Talk 03:25, 9 April 2019 (UTC)
• @Opabinia regalis: It's also sometimes lost in the WP:NOBIGDEAL rhetoric that Wikipedia admins are, amongst other things, entrusted with sysop privileges on the world's fifth most visited website. That includes some very risky buttons. Can you imagine the front pages of YouTube or Amazon being replaced with "hacked by <some kid with tor>", even for a couple of minutes? That we are a volunteer project shouldn't stop us aspiring to the same level of professionalism. It's not the nuclear codes, but all we ask of admins is to adhere the most basic of security practices. Things that, for example, have been technically enforced in every workplace I've been at, despite me rarely being trusted with much more than the coffee machine. The evidence that Necrothesp's account is a continuing vulnerability is the fact that it has already been compromised once, and in his public and private responses to this incident. – Joe (talk) 18:10, 8 April 2019 (UTC)
  • I agree with Joe, but there's also just generally a myth that compromised admin accounts don't cause real world harm. For instance, imagine a compromised admin account edits the main page to include a violent or extremely sexual picture, which is not an uncommon type of vandalism. How many traumatized children whose parents rightfully expected a clean main page are acceptable to us? I'm not all too bothered by "hacked by <some kid with tor>". I'm very bothered with putting hundreds of children around the world into therapy. And don't even get me started on the possibility for compromised CU accounts. ~ Rob₁₃^Talk 20:16, 8 April 2019 (UTC)
    • I'm not saying it's optimal for that kind of thing to happen, but suggesting that a single instance of accidentally viewing an inappropriate image would put "hundreds of children around the world into therapy" is a bit of an overstatement. ♠PMC♠ (talk) 22:23, 8 April 2019 (UTC)
      • It depends what image. Someone who had been beheaded or something similarly gory? If viewed by a young enough child, that could certainly cause non-trivial issues for the parents to deal with, at the very least. ~ Rob₁₃^Talk 22:25, 8 April 2019 (UTC)
  • Well, yes, I can imagine perfectly respectable websites (and debatably respectable ones, and not-respectable ones) getting hacked, sometimes in hilarious ways. (While looking for examples I checked our own list of security hacking incidents, which I'm tickled to discover begins with a telegraph demo in 1903 :) We don't need to resort to hyperbolic "but won't someone think of the children?" what-iffery to not want crap on our front (or any other) page, and to expect people to take reasonable precautions to avoid it, but IMO a lot of hyperbole and drama around account security is actually a perverse incentive - it makes the whole thing sound Big and Scary and like exactly the kind of thing people mean to pay attention to when they have time, sometime next week, after work, after this TV show is over, maybe in the morning, etc. It's anxiety-inducing! If you get it wrong, you might send hundreds of children into therapy! Better to just not worry about it. (This is exactly the approach I take to my taxes every year, and every April 14 I regret it, but as of, say, April 9? Feels great, man.) In fact the best thing anyone can do for their own security is use a strong, unique password. You only have to take one single action, one time, to be absolutely sure there's no risk of having forgotten that you reused the same password when you signed up for that Warcraft forum that one time in 2011. Opabinia regalis (talk) 05:50, 9 April 2019 (UTC)

Version 2 (Necrothesp)

On March 14, 2019, the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) were temporarily removed as a suspected compromised account under the Level 1 desysopping procedures. The Arbitration Committee has verified that Necrothesp is back in control of their account via multiple methods. The administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) are restored, provided he enables two-factor authentication on his account for as long as he retains the sysop flag.

Since November 2018, six accounts have been desysopped under the Level I desysopping procedures as compromised administrator accounts. The Arbitration Committee would like to remind administrators that they are required to "have strong passwords and follow appropriate personal security practices." The current policy on security of administrator accounts provides that "a compromised admin account will be blocked and its privileges removed on grounds of site security" and "in certain circumstances, the revocation of privileges may be permanent."

The Arbitration Committee resolves that the return of administrator privileges to a compromised account is not automatic, in line with this policy. The Arbitration Committee will review all available information to determine whether the administrator followed "appropriate personal security practices." Factors the Arbitration Committee may use to make this determination include, but are not limited to, whether the administrator used a strong, unique password on both their Wikipedia account and associated email account, whether the administrator enabled two-factor authentication, and how the account was compromised. If the Committee determines the administrator failed to secure their account adequately, the administrator will not be resysopped automatically. Unless otherwise stated, they may regain their administrative permissions through a successful request for adminship.

For this motion there are 11 active arbitrators. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.

Majority reference

Abstentions	Support votes needed for majority
0–1	6
2–3	5
4–5	4

Support

1. We need to start actually enforcing the community policy on the security of administrator accounts. The existing policy states admins must at least try to secure their accounts. Where we determine that they declined to do so and it resulted in damage to the encyclopedia, we should not be resysopping automatically. This alternate motion simply makes clear that we will be following existing community policy surrounding account security going forward. ~ Rob₁₃^Talk 21:41, 7 April 2019 (UTC)

   Second choice to Motion 3. ~ Rob₁₃^Talk 15:12, 8 April 2019 (UTC)

2. First choice. It is not exactly fair to Necrothesp to change the rules midstream, but I am heartily tired of dealing with these compromised admin accounts. Now everyone is on notice that resysop is no longer automatic in these situations. Katie^talk 21:45, 7 April 2019 (UTC)
3. RickinBaltimore (talk) 22:54, 7 April 2019 (UTC)

Oppose

1. Oppose on principle; restoring Necrothesp's privileges should not be contingent on altering our existing procedures. They're two separate discussions. ♠PMC♠ (talk) 21:44, 7 April 2019 (UTC)
2. I support the warning about enforcement from now on, but oppose resysopping Necrothesp, per above. If this doesn't pass, we should vote on a standalone motion with just the second two paragraphs. – Joe (talk) 05:30, 8 April 2019 (UTC)
3. Unhelpfully, this motion conflates two different issues (our procedures for the future – and what to do with Necrothesp). AGK ■ 13:52, 8 April 2019 (UTC)
4. On principle. Mkdw ^talk 16:04, 8 April 2019 (UTC)
5. Now we have separated the resysopping from the procedure, this motion is no longer appropriate. SilkTork (talk) 17:07, 8 April 2019 (UTC)
6. Per PMC and Mkdw. Opabinia regalis (talk) 17:16, 8 April 2019 (UTC)

Abstain/Recuse

Arbitrator comments/discussion

• Has it been confirmed by us that Necrothesp is back in control of their account? The question was raised on the email list, and it was thought that the Foundation did the confirmation. I don't wish to change the wording as I don't actually know who did confirm it. SilkTork (talk) 22:33, 7 April 2019 (UTC)

• Per the Global log, T&S verified this and unblocked him. ♠PMC♠ (talk) 22:56, 7 April 2019 (UTC)
  • We've also verified it via the WMF. A WMF staff member assured me that the person who is currently in control of the account is definitively the original account holder. This matches the language of past motions on resysopping previously-compromised admin accounts. ~ Rob₁₃^Talk 23:14, 7 April 2019 (UTC)

Motion 3: Return of permissions

Since November 2018, six accounts have been desysopped under the Level I desysopping procedures as compromised administrator accounts. The Arbitration Committee reminds administrators that they are required to "have strong passwords and follow appropriate personal security practices." The current policy on security of administrator accounts provides that "a compromised admin account will be blocked and its privileges removed on grounds of site security" and "in certain circumstances, the revocation of privileges may be permanent."

The Arbitration Committee resolves that the return of administrator privileges to a compromised account is not automatic. The committee's procedure at Wikipedia:Arbitration Committee/Procedures § Removal of permissions, subsection Return of permissions, is replaced by the following:

Removal is protective, intended to prevent harm to the encyclopedia while investigations take place, and the advanced permissions will normally be reinstated once if a satisfactory explanation is provided or the issues are satisfactorily resolved. If the editor in question requests it, or if the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances.

In cases where an administrator account was compromised, the committee will review all available information to determine whether the administrator followed "appropriate personal security practices" before restoring permissions. Factors used to make this determination include: whether the administrator used a strong password on both their Wikipedia account and associated email account; whether the administrator had reused passwords across Wikipedia or the associated email account and other systems; whether the administrator had enabled two-factor authentication; and how the account was compromised.

If the Committee determines the administrator failed to secure their account adequately, the administrator will not be resysopped automatically. Unless otherwise provided by the committee, the administrator may regain their administrative permissions through a successful request for adminship.

Enacted – bradv🍁 14:50, 10 April 2019 (UTC)

For this motion there are 10 active arbitrators, not counting 1 recused. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.

Majority reference

Abstentions	Support votes needed for majority
0	6
1–2	5
3–4	4

Support

1. Proposed; splitting this from Motion 2 per our earlier discussions. In the wording for a new procedure, I have separated the requirement for a 'strong password' and for a 'unique password' to drive home the point: reusing passwords across systems is unsafe. AGK ■ 14:21, 8 April 2019 (UTC)
2. Support as 2nd choice. RickinBaltimore (talk) 14:53, 8 April 2019 (UTC)
3. Fully happy with this. First choice, since it puts it into our procedures directly. ~ Rob₁₃^Talk 15:11, 8 April 2019 (UTC)
4. Explicitly adding it to our procedures is a good idea. – Joe (talk) 18:13, 8 April 2019 (UTC)
5. Katie^talk 02:33, 9 April 2019 (UTC)
6. Well, the path that got to this wasn't very good - let's not try this particular style of attempted compromise anymore. But I think the substance is reasonable. I agree with PMC that there's some fuzziness here, but normally I'd expect that to be a good thing that allows us to be clear with the community about expectations while also allowing room for case-by-case evaluations. It does also allow room for implausible speculation and motivated reasoning, but I think it's like a lot of things arbcom-related - everyone gets it wrong sometimes, but we don't all get it wrong the same way all at once very often. Opabinia regalis (talk) 07:15, 9 April 2019 (UTC)
7. I also support the suggestion for a mass-message to be sent out to administrators to inform them about this change to WP:RETURN once it has been implemented. The issue of compromised admin accounts should be taken more seriously by the committee and the community-at-large. I think these changes also leave the door open to future amendments and improvements to address a wider number of issues should they arise. Mkdw ^talk 16:00, 9 April 2019 (UTC)

Oppose

Abstain/Recuse

1. I'm going to abstain on this, although I support it in principle. I have to point out that although we can confirm some information about an editor's Wikipedia password and their use of 2FA, we have no way of actually confirming whether someone had a unique, strong password for their Wikipedia-associated email address, if they reused their password on other sites, and how the compromise occurred. At best all we have is the editor's word and (particularly with the last point) our best guess. I'm not sure it's fair for us to enshrine those points in policy as reasons not to return someone's permissions when we have no way of confirming the information. ♠PMC♠ (talk) 17:29, 8 April 2019 (UTC)

Arbitrator comments/discussion

• I'm in favour of making clear moving forward that compromised accounts will not automatically have the admin tools restored. Where I am unsure is if this is the procedure we wish to adopt, as it amounts to us asking (as we have done in this case): "Did you have a strong and unique password?" and the admin saying (as they have done in this case) "Yes". But in this case, despite assurances that the password was strong and unique, the admin account was still compromised, which is why we have taken a long time to even get as far as this on-Wiki discussion, why we are insisting on 2FA, and why Joe is opposing a resysopping. I'm not sure a simple assertion that "Yes of course my password was safe" is quite enough, because if someone's admin account became compromised there was a flaw somewhere in that user's security which they didn't know about, and are possibly still not aware of. I think the procedure should be that if an admin's account was compromised and they didn't have 2FA, then they need to enable 2FA to get the tools back. SilkTork (talk) 17:34, 8 April 2019 (UTC)
  • I have to strongly disagree with the premise that all we can do is ask the admin. Here, the WMF made a public statement in which they noted that the password was likely reused due to specific, credible information. We can ask the WMF for similar information in any future cases of a compromise and base our decision on that information as well as what the admin tells us. If an account is compromised on the first try and there is no indication of any type of attack perpetrated through Wikipedia itself (e.g. with site JS on smaller wikis), it's fairly clear it was from a reused password, phishing, or a keylogger. ~ Rob₁₃^Talk 17:56, 8 April 2019 (UTC)

Discussion and comments (Necrothesp)

I don't wish to beat up on this particualr admin (since that's already been done to the point where I'm sure the message has been received) but I would urge the committee to go with version 2, and to consider it a sort of final warning that admins are expected to secure their accounts and ignorance of the last 5-6 years (at least) of evolving policy on this matter is no excuse as we expect admins to be up to speed on important policies. And reports about this hae been in the monthly admin newsletter how many times now? I've lost count. Kinda a big part of the job, and if you can't be bothered to keep up you should be big enough to hand in the tools. Beeblebrox (talk) 01:18, 8 April 2019 (UTC)

Should this pass, I hope that a MassMessage will be sent to all admins, active or not (and signed "On behalf of the Arbitration Committee" so they don't think it's just a newsletter that can be ignored). --Rschen7754 05:20, 8 April 2019 (UTC)

@Rschen7754: We can certainly do that. ~ Rob₁₃^Talk 05:42, 8 April 2019 (UTC)

@BU Rob13 and Rschen7754: would you want this for all users that are currently admins, or also those that are not currently admins but may be eligible for re-sysoping? --DannyS712 (talk) 06:00, 8 April 2019 (UTC)

Likewise, although I'm sympathetic to both the optics and voting implications of splitting version 2 into two separate motions. ~ Amory (u • t • c) 10:16, 8 April 2019 (UTC)

• Don't the current policy wordings leave discretion with the bureaucrats and not mention ArbCom? EdChem (talk) 13:48, 8 April 2019 (UTC)

• We are dealing in this motion with scenarios where there is a removal due to a security breach. The policy wording you mention was added to deal with security concerns that arise in passing after an administrator requests restoration of rights removed due to inactivity. In the latter scenario, the bureaucrats are the first assessors of the security issues. In the former scenario, ArbCom deals with the security issues and votes to reinstate where it knows the issues are resolved. It would not make sense for the bureaucrats to duplicate ArbCom's work in cases of compromised accounts. This illustrates an issue with some language at WP:ADMIN: we keep adding sentences to deal with edge cases that then mislead readers, through the illusion of comprehensiveness, when a different edge case arises. AGK ■ 14:05, 8 April 2019 (UTC)

• AGK, I am aware that ArbCom can and does desysop for security reasons, it is the reason that I was surprised by the wording. WP:SECUREADMIN states that "[d]iscretion on resysopping temporarily desysopped administrators is left to bureaucrats," which appears to me to empower bureaucrats to duplicate ArbCom work and even resysop after a Level 1 desysop unilaterally provided the 'crat is convinced security issues are addressed so long as a leel 1 desysop can be placed into the "temporary" camp. Wikipedia:User account security#Privileged editors states that Administrators, bureaucrats, checkusers, stewards and oversighters discovered to have weak passwords, or to have had their accounts compromised by a malicious person, may have their accounts blocked and their privileges removed on grounds of site security. In certain circumstances, the revocation of privileges may be permanent. Discretion on resysopping temporarily desysopped administrators is left to the bureaucrats, provided they can determine that the administrator is back in control of the previously compromised account. This mentions nothing about ArbCom. It asserts desysopping or other rights revocations may be permanent under "certain circumstances," but gives no clue as to what those might be, nor does it define who makes the decision. For sysop permissions, the discretion could be argued to be held only by the 'crats.
• I agree with you that duplication is unhelpful, and that in practice ArbCom has the decision-making role... but I am surprised to see nothing in policy that supports that this is the case. I know that ArbCom gets to design its own procedures but cannot make policy. Arguably, above attempts to codify the desysopping being permanent falls into the former case rather than the latter, but that argument becomes much weaker when the policy basis for security breaches leading to permanent action is vague, does not mention ArbCom, and (I suspect) may not have been subject to community endorsement as policy. It may come from WMF actions / directions, but then that should be explicitly stated. Before codifying procedures, the basis for ArbCom authority should be clearly found in policy that is WMF mandated and / or community endorsed. I get that there is something about this particular case and the mishandling of security that has ArbCom annoyed. Perhaps it is a particularly egregious case, or just the latest in a series of cases that should never have arisen. Privacy concerns mean that can't be disclosed in detail, but those motivations don't justify acting as if policy support for ArbCom's authority in this area is clear when the policy documentation does not bear that out. The language on removals becoming permanent goes back at least a decade, so perhaps merely codifying that the decision-maker is ArbCom is needed, along with clarifying when bureaucrats can exercise the discretion that they have under the policy? EdChem (talk) 14:52, 8 April 2019 (UTC)

• I think the functional part here though is that since the removal was authorized under WP:LEVEL1 the return is only authorized under WP:RETURN. That is, as ArbCom has explicitly removed the permission, only ArbCom may explicitly return it. If the user group is not returned by ArbCom, WP:RfA still exists. WP:SECUREADMIN seems to specifically refer to things such as password requirements; if WMF ever did one of the promised audits, they could presumably pass that on to bureaucrats for action. ~ Amory (u • t • c) 15:08, 8 April 2019 (UTC)
• Our authority to act here is solid. There are several ancillary policies and procedures we could cite (see above), but ultimately it comes down to the fact that WP:ARBPOL gives ArbCom the responsibility for removing the admin permissions. It necessarily follows that we can decide if/when to give back bits we remove, and impose conditions (analogous to topic bans imposed by individual admins as unblock conditions). It would be helpful to amend WP:SECUREADMIN to note that this eventuality exists. – Joe (talk) 18:29, 8 April 2019 (UTC)

• Please keep in mind that there is no mechanism available to stewards or bureaucrats to validate if a user has enabled 2FA, nor do they have a mechanism that can be used to determine if 2FA is deactivated at a future time. (WMF staff and certain developers can access this user-level data only). There is some consideration for building this functionality (see phab:T209749) however the last notes from the foundation suggest it is unlikely to be made available to project volunteers. To this end, I don't think ArbCom should be creating a user restriction ("account X requires 2FA") that has no mechanism to validate or audit, thus no means to enforce. — xaosflux ^Talk 14:30, 8 April 2019 (UTC)
  • @Xaosflux: This specific concern was discussed quite a bit internally. We can get this data from the WMF, and have in the past. ~ Rob₁₃^Talk 15:14, 8 April 2019 (UTC)
    • @BU Rob13: thanks for the note. From my reading of the first proposals above, once enacted this motion completes correct? That is, ArbCom is not creating a continuing requirement that this specific user must maintain 2FA as an ongoing condition of maintaining their administrator access correct? — xaosflux ^Talk 15:54, 8 April 2019 (UTC)
    • For the second proposal, it seems to be missing a few things: (1) Under what authority is ArbCom creating a new account restriction, (2) What are the mechanics for enforcement? — xaosflux ^Talk 15:56, 8 April 2019 (UTC)
      • I am not the best person to address the first question as a broad question, because I raised the same concern myself at one point and am not fully satisfied with the answer. Having said that, Necrothesp has noted privately to the Committee that he is willing to enable 2FA going forward. I would say our authority in this case is consent of the editor. In terms of enforcement, theoretically, the Arbitration Committee can request a list of editors with 2FA enabled from the Foundation. We've been provided with such information as it relates to the functionary team in the past. As a practical matter, I am more than happy to AGF that Necrothesp wouldn't blatantly lie to us about enabling 2FA and keeping it enabled. ~ Rob₁₃^Talk 18:02, 8 April 2019 (UTC)
      • We already have a password strength policy that is supposed to be binding on all admins, it has just never been enforced even one single time. And now there is also a global policy. We asked the WMF for password auditing in 2015 but as far as I kno wthat's never been done either, but I seem to recall seeing somewhere recently that that is close to being a reality as well. Beeblebrox (talk) 17:34, 8 April 2019 (UTC)
        • Discussed at phab:T121186, the "regular audits" and "password strength bar" have, obviously, not been implemented. ~ Amory (u • t • c) 17:50, 8 April 2019 (UTC)
• In Version 3 by AGK et al. the unchanged text from the current policy at WP:RETURN appears to proscribe a case if ArbCom doesn't return the perms, is that a fair assessment? Would it be worth indicating that a case is not required in all cases (such as this), perhaps simply by changing shall be opened to may be opened? ~ Amory (u • t • c) 15:26, 8 April 2019 (UTC)
  • Given the typically private nature of discussions regarding an individual account's security, I would argue we're already opening "normal arbitration proceedings" when an account is compromised by seeking evidence regarding the account's security privately. The normal proceedings in such a situation would be a private case, not a public one. I would consider the new language on our procedures for compromised accounts as descriptive of "normal arbitration proceedings" in that situation. ~ Rob₁₃^Talk 18:06, 8 April 2019 (UTC)
• Please note that Necrothesp has enabled 2FA on his account. See here. Thank you for taking that step. ~ Rob₁₃^Talk 18:57, 8 April 2019 (UTC)
  • I've been informed that log is noting he got oauth-tester, which allows him to enable 2FA. Either way, thanks for taking a step toward 2FA. ~ Rob₁₃^Talk 19:01, 8 April 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Statement by 92.8.219.133

(Posting by banned user removed.) Fut.Perf. ☼ 17:20, 11 April 2019 (UTC)

Moved to Wikipedia:Arbitration/Requests/Case

--DannyS712 (talk) 17:17, 11 April 2019 (UTC)

Please don't move it there, this IP is banned Vote (X) for Change (talk · contribs), as so often. Fut.Perf. ☼ 17:20, 11 April 2019 (UTC)

@Future Perfect at Sunrise: reverted --DannyS712 (talk) 17:22, 11 April 2019 (UTC)

CONSTANT HARASSMENT BY Future Perfect at Sunrise

Initiated by Stevepeterson (talk) at 16:46, 26 February 2019 (UTC)

Involved parties

• Stevepeterson (talk · contribs · deleted contribs · logs · filter log · block user · block log), filing party
• Future Perfect at Sunrise (talk · contribs · deleted contribs · logs · filter log · block user · block log)

Confirmation that all parties are aware of the request

• [diff of notification Future Perfect at Sunrise]

Confirmation that other steps in dispute resolution have been tried

https://en.wikipedia.org/w/index.php?title=Administrators%27_noticeboard/Incidents#Repeated_Personal_Attacks_with_disgracing_insults_by_Future_Perfect_at_Sunrise

• Link 2

Statement by Stevepeterson

In a discussion in Talk:North_Macedonia I expressed my opinion that wikipedia should adhere to the recently signed Prespa agreement between North Macedonia and Greece in favour of peace in wikipedia. Specifically I shared my opinion that wikipedia could adopt term "North Macedonia's" as an adjective to the State's name: North Macedonia. This (along with "of North Macedonia") is the adjective recommended by "the Ministry of Foreign Affairs of North Macedonia". Admin User User:Future_Perfect_at_Sunrise has expressed that this would lead to poor English grammar and he is an advocate of the term Macedonian as the adjective of North Macedonia. As the discussion with other users went on he started to personally attack me using disgracing words and insults such as:

you really ought to leave this discussion to others who are competent speakers of English and don't have tin ears.

• https://en.wikipedia.org/w/index.php?title=Talk:North_Macedonia&diff=884714936&oldid=884700282

And: you really need to shut up and learn some English and some proper grammatical terminology before you expose your incompetence further here. It's getting quite embarrassing to watch.

• https://en.wikipedia.org/w/index.php?title=Talk:North_Macedonia&diff=884848956&oldid=884848841

Later, he offended all participants in the discussion by trying to collapse the whole conversation claiming "Embarrassing display of linguistic incompetence."

https://en.wikipedia.org/w/index.php?title=Talk:North_Macedonia&diff=884847688&oldid=884847206

I tried to explain that I feel insulted and disgraced so he should stop this behaviour by posting on his talk page:

• https://en.wikipedia.org/w/index.php?title=User_talk:Future_Perfect_at_Sunrise&diff=884730558&oldid=884559635

I would like to inform you that I consider your "you really ought to leave this discussion to others who are competent speakers of English and don't have tin ears." a Derogatory comment and personal attack to me. .

His response had no regret or apology: You don't need to inform me of that. What you do need to do, however, is to learn how to use talk pages. https://en.wikipedia.org/w/index.php?title=User_talk:Future_Perfect_at_Sunrise&diff=884735657&oldid=884730558

I brought to to ANI but I received so many personal insults there by Administrators biased towards USER:Future Perfect at Sunrise. There not only did he make the reported comments, he doubled down by linking to an article discussing people of low ability [who] have illusory superiority and mistakenly assess their cognitive ability as greater than it is. The cognitive bias of illusory superiority comes from the inability of low-ability people to recognize this basic lack of ability.. I have not been rude neither at the ANI nor at the initial discussion page so there should be no action to be taken against me. USER:Future Perfect at Sunrise on the other hand, has selected a telling link (against himself). He says There's never a nice way of telling an incompetent person that they are incompetent which is extremely inappropriate. FP@S has hidden a discussion on my talk page and I believe that his action (WP:INVOLVED is a misuse of the revision deletion tool. The insults I received made lose control of the ANI and instead of a resolution of the conflict with USER:Future Perfect at Sunrise, I am now proposed for Site Ban.

Statement by Floquenbeam

Dude...

Statement by Khajidha

While Future Perfect's wording was extreme, the fact remains that you demonstrate a lack of proficiency in the use of the English language. Especially considering that the argument is about proper English usage. You have been told numerous times, by numerous people, that the phrasing you wish to use is not proper English. You continue to argue based on your mistaken definitions (possessive nouns are NOT adjectives) and seem to refuse to learn from the grammar lessons that everyone is trying to give you. You even engaged in emotional blackmail (see this revision: https://en.wikipedia.org/w/index.php?title=User_talk:Stevepeterson&oldid=885173108), insinuating that you were contemplating suicide based on your treatment here and that others in similar situations in the future may also contemplate such actions. The proposed ban is MORE than earned. --Khajidha (talk) 17:10, 26 February 2019 (UTC)

Statement by Legacypac

The filer is about to be CBAN'd at ANi so nothing needs to be done on this request except close it for they will not be able to participate. Legacypac (talk) 17:44, 26 February 2019 (UTC)

Statement by 92.19.174.217

There is a procedural error here by the clerk. While it is true that he acted correctly at 19:22, 26 February, removing a case which the Committee had declined, that decline was without prejudice to a further filing should the alternative dispute resolution mechanism fail. See judgments:

An Arbitration case should be the last resort if other dispute resolution attempts have failed. ...

-GorillaWarfare 18:40, 24 February 2019

It looks like on occasion it would be justified to shove a sock into FutPerf's mouth ...

- AGK 07:12, 25 February 2019

The second opinion shows that a second case would very likely have been accepted. The second filing was appropriate because by 16:46 on 26 February it was apparent that there would be no action against FP@S (see Legacypac's statement). His reasoning is flawed - the recent case brought by Twitbookspacetube against Winhunter continued after the filer was banned, and Winhunter went on to be de-sysopped. The only way the second case can be disposed of is by the Arbitrators giving their opinions in the usual manner - the clerk's removal of it at 19:25, 26 February, with an entry in the log that Arbitrators had declined it that day was out of process. Most, if not all Arbitrators, would have been unaware of the case because it was removed 1 1/2 hours after filing.

Turning to Khajidha's statement, an inquest yesterday was discussing the deaths of four teenage soldiers at Deepcut training barracks between 1995 and 2002 from gunshot wounds amid allegations of bullying and abuse. The allegations against FP@S have been confirmed by Committee judgments spanning ten years. In the present climate, if social media platforms are not seen to be taking effective action against this it is likely that governments will do it for them.

My comments at the ANI were removed by that interfering busybody Fortuna Imperatrix Tuesday, who claimed to have taken a break from editing when he was actually socking aggressively as an IP on pages he had previously posted comment on. If he starts playing up here I recommend an immediate block. What I said there was this:

*Oppose The Foundation has never banned an editor for making sockpuppet allegations. SPI reports are turned down every day but the filers don't get indefinitely blocked. Anyways, Steve didn't make a sockpuppetry allegation, he just drew attention to those who did. So let's turn attention to the real issue here - FP@AS has accused an editor of alleging that he (FPAS) is "a self-declared sex worker" Special:Permalink/885051895#Future Perfect at Sunrise removed the following proposed statement of facts:. The Foundation has banned editors who have made comparable allegations and failed to provide supporting evidence despite having had years to do so. I have no particular interest in FP@S's sex life, other than to note that while other editors discuss their family life FP@S doesn't appear to have one - in which case it is legitimate to ask why not? Pinging @:Stevepeterson as I expect Serial Number 54129 or someone of his ilk to be along shortly to remove this !vote. Fun fact:Beyond My Ken is regularly proposed at ANI for siteban for edit warring, incivility, sockpuppetry etc. Special:Permalink/866661947#Going forward. 11:47, 26 February 2019.

92.19.246.23 (talk) 14:48, 27 February 2019 (UTC)

I have a confession to make - last night I dreamt of FP@S. It's never happened before and I hope it never happens again. He has now been given a formal notice not to meddle with Arbitration pages, so when he gets blocked he can't say he wasn't warned.

From the London Daily Telegraph of 23 February [1]:

I am a cynical old hack who has been taught to question everything. I had first heard about the Bridge Retreat last summer, after I burst into tears on a magazine editor when she asked me how I was. "I'm...fine," I wept, but of course I wasn’t. I was having another one of my depressions, one so furious that on several occasions I contemplated suicide over getting up.

This isn't me making a joke - as a mental health campaigner, I am not the kind of person to make jokes about suicide. It was awful.

This case needs to be processed expeditiously. If it isn't, and something bad happens, the Foundation will want to know why it wasn't. 217.34.36.106 (talk) 10:01, 4 March 2019 (UTC)

Quoting AGK in the Signpost case, it is actually irrelevant that the filer has been banned. As AGK says,

We accept cases whenever our community mission would be best served by involuntarily imposing a binding decision.

We have here a case where an administrator was de-sysopped ten years ago for incivility and bullying. He has continued to be uncivil and he has continued to bully. No other administrator has enjoyed continued access to the tools after being de-sysopped for cause. It's time to iron out this anomaly. Bradv's action in hiding the case from the Committee is another example of his bad judgment - he previously caused a public relations disaster by deleting our article on Nobel Prizewinner Donna Strickland because he didn't consider the source (her faculty) to be "independent". The Committee should examine very carefully any application for promotion to full Clerk.

One of FP@S's complaints against Stevepeterson, which eventually resulted in him being banned, was an allegation (18:44, 25 February 2019) of his

writing in deliberately obfuscated Greek in order to make it more difficult for outsiders to understand.

In January 2016 an editor made the following observation at DeltaQuad's unprotected talk page:

In the sandbox two links from the "harasser"'s post are cited. What makes the respondent think The Rambling Man would have clicked on those links before replying? I have clicked on them. The first is claimed to be "a rant from another sock". It's actually a link to words written (yes, typed and saved) by the respondent which are so disgusting they would never be allowed in a family encyclopaedia.

I hurried over to FP@S's sandbox to see what FP@S had been saying. Here are the words I found:

• f*** off, idiot (14:45, 28 March 2009) [no asterisks in original]
• fu**ing sick of you ... stupid idiotic lot ... fu**ing sick (19:33, 14 April 2009) [no asterisks in original]
• What the f**k(22:57, 19 April 2009) [no asterisks in original]
• the community can go f... itself (08:06, 3 September 2008)

At 13:02, 19 April 2009 FP@S was wishing everyone a Happy Easter. That's Macedonian (or even "North Macedonian") Easter. The comment gives the lie to his claim to be a Roman Catholic - Roman Catholics in Germany had celebrated Easter long before. 2 days, 2 hours and 50 minutes later he told an editor αι σιχτίρ μαλακισμένε. I am reliably informed that the phrase means "F**k off, w*nk*r", but on its own the word μαλακισμένε is innocuous. @Stevepeterson:'s alleged "obfuscated Greek" is vicarage tea-party pleasantries by comparison. This was 6 days, 7 hours and 32 minutes after FP@S had told a Bulgarian academic that Bulgaria was "a banana republic". All remedies, up to and including siteban, must now be on the table. 80.5.252.147 (talk) 15:34, 9 March 2019 (UTC)

Favonian has been busy at Hebrew calendar and its associated talk page. Last time I looked the article was locked for two years and on the talk page a response to a personal attack was removed and the editor blocked. Less than half a day earlier, at 21:26, 15 April, FP@S removed another comment, blocking the editor 31.127.81.232. This was two minutes after a sockpuppet investigation had been opened. FP@S didn't report in. The case was closed no action at 22:03, as was to be expected since there was zero evidence. FP@S is sabotaging the SPI process by taking administrative action and not logging what he has done. This is not an isolated instance - it happens all the time. He has been reported to the Committee hundreds of times in the past thirteen years but they decline to take action. The Committee is on record as stating that FP@S's WP:INVOLVED actions are not involved actions because when he makes them he believes in his mind that they are not involved actions. If a convicted murderer goes to his gaoler, says his sentence has expired and demands to be released does the gaoler let him out? This case was filed fifty days ago and it is intolerable that the Committee has not yet taken any steps to deal with it. I'm not blaming them because it was removed by a trainee clerk within ninety minutes and they may not even know about it.

Statement by {Non-party}

Other editors are free to make relevant comments on this request as necessary. Comments here should address why or why not the Committee should accept the case request or provide additional information.

CONSTANT HARASSMENT BY Future Perfect at Sunrise: Clerk notes

This area is used for notes by the clerks (including clerk recusals).

CONSTANT HARASSMENT BY Future Perfect at Sunrise: Arbitrators' opinion on hearing this matter <0/0/0>

Vote key: (Accept/decline/recuse)